云原生(Cloud Native)- 移动App研发新范式

什么是云原生(Cloud Native)App

云原生的话题近期异常火热,对于它的概念,大家也有不同的解读。从我个人的视角而言,云原生代表了一种应用构建的方法论:如何最大程度地利用云计算服务模型的优势低成本、快速地构建一款弹性的应用。本质上而言,云原生的研发模型旨在降低业务的技术风险,让开发者的形态更单纯、专注:

所有的运行环境透明化,按需扩展;

所有的研发流程流水化,高效交付;

所有的基础设施服务化,按量付费;

云原生应用

我们通常意义下的云原生应用意指传统的后端应用,Container、Microservice、DevOps构成了云原生研发架构的铁三角。对于移动App这类呈现重前端轻后端形态的产品而言,云原生有另一种诠释方式。移动App对比传统的后端应用研发有着较大的形态差异,应用本身构建在异构的OS平台之上,运行环境约束较多,依赖大量的后端服务支撑,应用本身的持续交付过程也包含了许多移动场景特有的元素,比如编译环境(iOS)、兼容测试、内测分发、渠道打包、灰度发布等等。从基础环境的支撑视角,云计算服务商面向移动App需要解决的几个核心问题包括:

跨平台;

移动App需要面对多个OS平台,在研发资源和迭代周期上都会带来巨大的挑战。一站式跨平台研发框架将有助于应用进入市场的节奏把控,屏蔽不同OS平台对App的影响。

松耦合;

移动App本身同样是一个非常庞大的体系工程,想象一下类似手机淘宝这样的航母级App所承载的服务内容,数十个团队并发协同一个版本的迭代是大型App的常态,所以一个松耦合结构的应用容器/脚手架是应用高速迭代的基础底座。

服务化组件;

基础组件的功能纯粹,通过云化的中间件和后端服务构建弹性的终端基础能力是性价比最高的一种软件构建方式。

快速迭代;

移动App特有的流程元素决定了开源的CI/CD服务不能完全满足移动App快速迭代的场景诉求。另一方面持续交付流程与云上的后端服务存在大量的交互,云化的持续交付/研发支撑平台将会是移动App生命周期管理的终极杀器。

按需扩展;

移动App的流量波动将更剧烈和频繁,按需扩展、弹性伸缩的基础服务支撑将有助于灵活的业务运营和成本的降低。

云原生App架构

我们把基于上述云计算模型构建的移动App称为云原生App。在大家比较熟悉的概念中,围绕移动App衍生的一个很典型的云计算架构即Serverless。

Serverless

Serverless是当前软件架构领域非常火热的话题。从字面上看,大家或许会比较困惑,没有服务器,如何来托管服务实体?事实上Serverless是从用户视角出发的一种应用架构范式,即基于云服务的计算模型实现对业务逻辑的抽象封装、管理,而无需关心底层资源的运维管理和扩展。我们所熟知的BaaS(Backend as a Service)以及FaaS(Function as a Service)即是Serverless架构模型的实体化服务形态。比如,当你想创建一个天气服务,方便自己的应用或第三方的应用能够很方便的获取即时的天气数据时,你就可以基于FaaS + API Gateway快速构建一个独立的天气微服务,并对外开放,这就是一种非常典型的Serverless服务场景。

Serverless架构模型的核心价值体现在三个方面:

成本

传统的研发支出模型需要预先购置一批服务器设备,并按照使用周期内的预估业务峰值来量化预算的大小,不确定性因素较多,服务器资源的空置也会带来非常巨大的成本浪费。而Serverless的架构模型则实现了按需扩展、按量付费的弹性模型,让企业成本更高效可控。由于Serverless服务粒度的进一步打细,基于高效的bin-packing算法甚至可以获得对比弹性伸缩的虚拟机集群更高的使用效率。

运维

开发者不必再关心底层计算资源的容量与日常运维问题,所有基础设施维护将会由云计算服务商负责解决并对开发者透明。

效率

细粒度的Serverless计算模型非常适用运算密集型的场景,能够低成本地实现瞬时高强度脉冲计算能力。而传统架构为这样的脉冲计算场景则需要付出高昂成本的准备工作,环境搭建、容量压测、计算存储扩容、应用上线部署等等,这些隐性的时间资源成本更佐证了Serverless的核心价值。

Serverless意图把服务运行时封装在服务本身的交付体系中,面向开发者屏蔽与业务无关的基础环境支撑细节,是你能想象到的对应用逻辑最高等级的抽象。

云原生App对比传统研发架构的收益

基于Serverless的介绍,我们应该已经能看到云原生架构范式带来的不同,接下来我们一起系统化地对比一下云原生App与传统研发模型的核心差异点。

阿里云对云原生App的支持

目前国内真正能够提供云原生App完整技术栈支持的供应商并不多,绝大多数都是以BaaS形态进行服务的垂直厂商。由于缺少App研发支撑解决方案以及和IaaS层的联动,这种类型的服务无法彻底利用移动App开发强内聚的场景特性,沦为单点的工具支撑,为开发者带来的效率提升也是相对有限和独立的。

阿里巴巴在移动互联网领域有近7年的研发经验积累,在移动技术不断深化的同时,移动开发范式也在快速演进,以支撑整个阿里巴巴体系内移动App的快速迭代和品质保障。下图展示了阿里巴巴Cloud Native App的架构范式。除了端+云的硬能力栈支撑外,阿里巴巴也开放了包括Android/iOS平台研发规约,移动研发DevOps规约在内的一系列软能力栈。软、硬能力栈背后蕴含的是对移动行业的深层认知与理解,绝非一朝之功。

阿里巴巴Cloud Native App Paradigm

在阿里云平台上,我们很高兴通过ApsaraMobile(移动云)为大家开放阿里巴巴Cloud Native App的完整能力栈。阿里云ApsaraMobile(移动云)是阿里巴巴移动技术的开放平台,沉淀了阿里巴巴多年移动互联网系统架构积累,近期也和阿里百川进行了深度整合,是阿里生态移动技术与理念对外输出的主窗口。ApsaraMobile目前向开发者开放的能力如下图所示,已基本覆盖完整了云原生App的核心中轴。

ApsaraMobile体系图

跨平台UI开发框架:WEEX-based MADP(Mobile App Development Platform)

WEEX是阿里巴巴开源的跨平台移动UI开发框架,并于16年底正式捐赠给Apache基金会进行孵化。WEEX

具备一次开发,三端(Android,iOS,H5)运行的能力,相对于H5来说,在使用相同的web化开发模式,保持较高的研发效率、较低的研发成本的同时,又具备接近Native的性能体验,非常适合需要快速迭代又对性能体验有一定要求的APP开发者。

移动App应用容器:Atlas

Atlas是阿里巴巴开源的Android端应用容器,提供解耦的组件化/插件化模块框架及动态化支持。帮助工程师解决在工程编码期、Apk运行期以及运维修复期面临的各种棘手问题。

在工程期,实现工程独立开发,调试的功能,工程模块独立。

在运行期,实现完整的组件生命周期的映射,类隔离等机制。

在运维期,提供快速增量的更新修复能力,快速升级。

目前,Atlas在阿里巴巴体系内部的应用十分广泛,手淘自身超过60+业务组件、20个协作团队,以及百万行级别代码都在Atlas上运行,其快速迭代能力让应用的发布周期从每月到每周再到随时发布,在过去半年里就发布了446次。另外Atlas本身非常轻量,只有90多个类,支持大小型App开发,从大型的手淘到相对小型的阿里健康等都在使用该框,其稳定性也接受了考验,兼容Android 4.x以上系统版本。整体手淘的Crash率一直维持在万分之五左右,因为容器导致的crash占比小于百分之一。

研发支撑平台:MobileHub

对于企业而言,单纯的购买虚机替代传统的物理机仅仅实现了基础资源的云化,这是云计算最初阶的使用模式。企业互联网+的真正标志应该是研发体系的互联网化,如何通过敏捷、DevOps、容器、分布式、Serverless等互联网形态的思维和架构来真正影响企业内部的产品体系结构和研发的日常运转形态,这才是云计算更高阶的价值传递。

MobileHub是阿里巴巴多年移动互联网行业沉淀、打磨的移动App研发支撑平台,支撑了阿里巴巴数个亿级App的完整生命周期全流程管理,从项目管理、持续集成、持续构建到自动化测试、版本管理、灰度发布、监控运维、用户运营等环节,整个工作流融入了阿里巴巴在移动互联网领域的深层认知与理解,是移动App研发体系中软能力栈的几个关键元素(机制、流程、方法论)的重要载体。

移动中间件与BaaS服务矩阵

移动中间件与BaaS服务负责了移动App基础设施能力的支撑,与App业务解耦,适合以云服务的形态帮助业务快速完成从0至1的基础建设。云化的移动中间件与BaaS服务本质上即是移动App Serverless架构的具象化实现。ApsaraMobile按照组件职能范畴把移动中间件划分为5个具体的职能域,如下图所示。

ApsaraMobile移动中间件服务矩阵

对于绝大多数企业而言,中间件的建设并非位于业务的核心发展路径上,缺少持续深耕的源生动力。而云服务则可以通过规模化的服务来平摊基础技术研发的成本,在人才聚敛、资源投入、产品稳定性与性能等方面都具备绝对的优势,是整个移动生态分工细化和生产效率提升的重要表现。阿里巴巴在移动网络、移动高可用、消息、移动数据等领域积累了大量的场景能力,可以有效地帮助企业规避重复的能力建设和繁重的维护、演进成本。

结语

移动超越PC成为第一大流量入口,业务移动化已经成为几乎所有企业的核心战略之一,如何抓住时间窗口,以最快速度把产品推向市场,往往成为决定产品最终命运的关键元素。云计算带来的研发模式变化是巨大的,对于快速成长期的团队和企业而言,云原生的研发范式将带来较低的试错创新成本,真正助力创业进入“快消时代”。在整个移动开发生态的自然进化选择中,云原生势必将成为一种主流形态。

作者:阿里云 ApsaraMobile 杨镔(泠茗)

原文链接

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,847评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,208评论 1 292
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,587评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,942评论 0 205
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,332评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,587评论 1 218
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,853评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,568评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,273评论 1 242
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,542评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,033评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,373评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,031评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,073评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,830评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,628评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,537评论 2 269

推荐阅读更多精彩内容