EMAS 移动 DevOps 解决方案 —— Mobile DevOps

简介： DevOps这一优秀的软件交付理念在服务端已经有不少相关的实践，那么是否也能够应用到移动端进行交付呢？基于移动端和服务端场景的差别，移动DevOps跟服务端DevOps又有哪些不一样和挑战？本文分享阿里云云原生应用研发平台EMAS在建设云原生Mobile DevOps过程当中的思考、遇到的挑战以及解法，解密其设计架构和技术细节。

阿里云 云原生应用研发平台EMAS 彭钊（州牧）

1、Mobile DevOps 介绍

1. 什么是移动 DevOps

---

1）你们所熟知的DevOps

在2020年这个时间节点上，DevOps已经再也不是什么新鲜概念，相信你们或多或少都有些本身的理解，但当要咱们去准确描述什么是DevOps时，好像又很难讲的清楚。实际上DevOps至今业界也没有可让你们一致承认的定义，之因此很难被准肯定义，是由于DevOps实际上是一种理念甚至是一组理念的集合，很难被具象化。“DevOps”这个词自己从字面能够理解为软件从Dev（Development，开发）到Ops（Operations，运营）的全生命周期，但DevOps的准肯定义究竟是什么？在众多的DevOps定义中，我的认为Azure DevOps的定义[1]较为精确和具体：

DevOps 是开发 (Dev) 和运营 (Ops) 的复合词，它将人、流程和技术结合起来，不断地为客户提供价值。
DevOps 对团队意味着什么？DevOps 使之前孤立的角色（开发、IT 运营、质量工程和安全）能够协调和协做，以生产更好、更可靠的产品。

经过采用 DevOps 文化、作法和工具，团队可以更好地响应客户需求，加强对所构建应用程序的信心，更快地实现业务目标。

这个定义里有几个关键信息总结一下：
① 人、流程、技术的结合
② DevOps使让之前孤立的角色能够协调和协做
③ DevOps是一种理念，既要树立文化，也要有自动化工具的支持
④ 目的是更快的生产更好、更可靠的产品

2）从DevOps到移动DevOps

对于DevOps你们平时讨论比较多的实际上是服务端DevOps，既然DevOps是一种优秀的软件交付理念，为何不把DevOps也应用到移动端交付呢？这也就是咱们今天要介绍的移动DevOps。
由于移动端和服务端场景的差别，移动DevOps跟服务端DevOps会有很大的不一样。主要体如今如下几个方面：

移动端应用自动化构建更为复杂

• 构建环境碎片化

Android、iOS两个平台须要基于不一样的操做系统和构建工具链搭建构建环境，即使是同一平台构建工具链也存在版本碎片化现象，好比Android构建依赖的Android SDK、Gradle须要多个版本同时支持，iOS构建依赖的Xcode、Ruby版本须要多个版本同时支持

• 移动端构建涉及到证书托管等数据安全问题

• iOS构建依赖的Mac设备为机房非标设备

Mac设备不属于标准服务器没法部署在标准机房，一般须要自建Mac机房，对于可运维性和稳定性也是一个挑战。

自动化构建是DevOps中必不可少的能力，这就要求移动DevOps经过技术手段很好的解决上述客户端自动化构建、一键出包的问题。

移动端碎片化严重，应用交付兼容性是巨大的挑战

不一样于服务端部署环境的一致性，移动端应用运行环境碎片化很是严重，兼容性测试覆盖难度远大于服务端。移动端碎片化现象以Android系统尤其严重，主要体如今如下几个方面：

• 手机机型碎片化

Android市场有众多的手机厂商和茫茫多的机型，不一样厂商都会对系统作底层“优化”，理论上任何覆盖不到的机型测试均可能会面临兼容性问题，下图是2020.10月份最新的百度统计流量研究院[2]的Android Top机型分布，Top 10的机型市场占用率都不足15%，可见机型碎片化之严重

• 操做系统版本碎片化

操做系统的差别对应用运行的影响更为直接，系统大版本升级致使应用不兼容的状况家常便饭，每次操做系统大版本发布都是对应用兼容性的一次考验；在考虑兼容新系统的同时，还不能放弃老系统的用户。
下图是2020.10月份最新的百度流量研究院的Android版本分布数据，能够看到已经发布一年多的Android 10.0，市场占用率还不足50%，2年之前的操做系统依然占主流

因为端设备的碎片化问题，就须要移动DevOps具有移动测试能力，自动化完成大量的真机兼容性测试。

移动端应用发布更新周期长

应用新版本可能发布2周更新比例都不会超过50%，不像服务端能够在很短的时间内完成全部服务器的软件发布。发布周期长意味着犯错成本更高，一个有Bug的版本发出去，可能须要很长的时间才能经过更新升级消化完。

这就须要移动DevOps一方面具有完善的灰度发布机制，避免将有问题的应用一次性发布到用户侧；另外一方面一旦有Bug的版本已经发出，须要移动DevOps具有热修复能力，能够经过增量补丁包的发布方式更轻量、快速的修复Bug。

移动应用运行在海量移动端设备

不像服务端服务运行在特定的集群内，能够统一管控和运维，移动应用的运行环境在用户的手机上，并且对于手淘这类超级App来说是亿级海量设备。

这就须要移动监控类产品经过大数据技术来实现移动端运维监控，甚至须要远程日志功能来拉取指定设备上的错误日志来定位排查错误。

基于以上几点，并参考DevOps对软件交付生命周期的定义，总结移动DevOps应用生命周期及各阶段能力要求以下：

1. 什么是Mobile DevOps

---

1）Mobile DevOps 是EMAS移动DevOps理念的具象化实现

首先介绍一下EMAS（Enterprise Mobile Application Studio），EMAS是来自阿里云的国内领先云原生应用研发平台（移动App、H5应用、小程序、Web应用等），基于普遍的云原生技术（Backend as a Service、Serverless、DevOps、低代码等），致力于为企业、开发者提供一站式的应用研发管理服务，涵盖开发、测试、运维、运营等应用全生命周期。更多关于EMAS的介绍详见阿里云官网EMAS详情页。
Mobile DevOps是EMAS移动DevOps理念的具象化产品输出，是EMAS的中轴型产品，它联动EMAS全部产品共同实现上述移动DevOps理念。Mobile DevOps将EMAS本来孤立在应用各个生命周期的产品像上图同样实现了联动和完整闭环，实现了EMAS从移动中间件平台向移动研发平台的升级。Mobile DevOps结合如下EMAS产品共同造成EMAS的移动DevOps：
研发域：Mobile DevOps
测试域：移动测试
发布域：Mobile DevOps
运维域：移动监控，移动热修复
运营域：移动推送，移动用户反馈

2）Mobile DevOps的历史

Mobile DevOps是集团内部移动研发平台的商业化输出版本，最先于2017年由阿里云和手淘团队一块儿研发出输出初版专有云输出版本，2020年04月上线第一个公共云版本。
下面这张图是Mobile DevOps的发展史，能够说Mobile DevOps的发展史其实就是阿里集团移动研发技术发展史，是阿里巴巴近十年移动技术、工程研发理念沉淀。

3）Mobile DevOps的现状

专有云已初具规模
Mobile DevOps专有云主要面向大客户，尤为是正在作数字化转型的大客户，这部分客户对安全有很高的要求，基本只能接受专有云部署的模式，同时也愿意为提高研发效能投入成本。
2018年Mobile DevOps以专有云场景正式落地输出，目前已经为多个行业数十家大客户创造价值，赋能企业研发流程数字化转型。
公共云免费公测中
相对于专有云，Mobile DevOps公共云更多的是面向中小微企业，这部分客户对研发效能提高有诉求，可是又对价格敏感，公共云是很好的承接形式；同时阿里集团内部有些对外输出的业务（例如专属钉钉）没法基于集团内部研发平台去作移动DevOps的，Mobile DevOps公共云也是很好的选择。
Mobile DevOps公共云自2020.07开始正式对外免费公测，目前已服务以及众多中小微客户，以及阿里集团内部专属钉钉、政务钉钉、唱鸭等客户。

2、云原生的Mobile DevOps

相对于专有云，公共云场景下建设云原生形态的Mobile DevOps面临更多的技术挑战，本章会跟你们分享咱们在建设云原生Mobile DevOps过程当中的思考、遇到的挑战以及咱们的解法。

1. 为何须要公共云的 Mobile DevOps

---

1）面向中小微客户提供普惠型Mobile DevOps服务

虽然专有云部署具备独享、内网安全隔离等优点，但专有云交付的高成本注定只有行业高端玩家才有能力接受。专有云Mobile DevOps成本投入评估以下：
• 一次性投入：百万级一性采购费用
• 持续投入：至少30 W/年服务器成本 + 20 W/年人力维护成本
基于上述成本计算，专有云第一年、第二年、第三年的的投入成本分别为：150W ，50W，50W 累计200W，这对于中小微客户是没法接受的。
阿里云做为新时代的基础设施，新时代的水电煤，有必要为更多大客户之外的中小微企业提供普惠型云服务。而公共云形态的Mobile DevOps刚好符合这样的理念，基于云原生弹性扩缩容、按量计费的优点，能够极大下降中小微客户使用Mobile DevOps的成本。同时公共云场景下针对中小微客户的特色提供更适合目标客户的DevOps研发流程。

2）联动EMAS产品线为开发者提供一站式移动研发平台

公共云Mobile DevOps的上线，能够有效联动EMAS现有移动测试、移动监控、移动热修复等产品，让EMAS覆盖应用全生命周期，完成EMAS从移动中间件到移动研发平台的升级，提高用户体验和粘性。
EMAS一站式移动研发平台较传统基于开源方案Jekins、Gitlab Runner等自建CI/CD平台，在成本、高可用性、技术支持力度等方面都有明显优点，并且能够一站式覆盖应用构建、测试、发布、运维、运营全生命周期管理，较传统自建CI/CD“烟囱式”的一个个独立开源系统，研发协同效率上也有明显优点。

1. 公共云 Mobile DevOps面临的挑战

---

相比专有云内网部署、内部员工使用的场景，公共云形态下的Mobile DevOps会面临更多的技术挑战，主要体如今一下几个方面：

1）安全性

• 租户隔离
公共云面临的第一个问题就是租户隔离，不一样客户既要同时使用共享资源，又不能互相看到对方的数据。对于构建这种场景，除了不一样客户的构建任务可能会互相影响，构建环境还涉及到用户的代码、证书等私密信息，必需要有完善的方案保证用户构建环境的隔离
• 代码、证书、秘钥等私密数据安全
有构建就必然涉及用户代码、证书、秘钥，这些数据都是极其隐私的数据，公共云存储、传输、使用任何环节出问题均可能会致使用户重大损失。
• 外部攻击
公共云因为暴露在公网任何人均可以使用，还面临恶意黑客攻击的风险，尤为构建场景涉及大量的自定义执行命令，必需要有完善的机制防止黑客执行恶意自定义命令在构建环境内留下后门。

2）高可用性

• 必须支持弹性扩缩容
公共云业务规模增加时，须要业务要能快速扩缩容适应业务增加，不然就会致使服务异常。这就要求云产品在技术实现上符合分布式的架构，尤为是构建集群要支持无状态快速扩容。
• 构建环境的稳定性
构建环境要稳定，避免因攻击或异常使用致使的构建环境被破坏的状况，好比环境变量、构建工具链等。
• 高标准的SLA，实时在线，永不宕机
高标准SLA既是对客户的承诺，也是对阿里云品牌的敬畏。

3）可扩展性

• 应用架构多样化致使的构建流程差别大
专有云客户数量有限，并且有完善的KA客户技术支持服务，因此应用的差别有限且有专人支持接入。但公共云环境下客户众多，应用架构多样性对系统的通用性、扩展性提出了更高的要求。
• 研发流程多样化
公共云不一样客户研发团队规模、研发文化、研发流程都有差别，也对Mobile DevOps研发流程扩展性提出了更高的要求。

1. 咱们的解法

---

针对以上公共云Mobile DevOps面临的挑战，咱们从如下两个方面经过技术手段去解决：

1）基于流水线的通用构建架构

流水线架构将构建作到通用化，基于流水线自定义编排构建流程，基于任务插件扩展流水线业务能力，很好的解决了上述的可扩展性问题。此架构具备如下特点：
• 通用构建架构，支持全平台构建能力
• 基于YAML自定义编排构建流程
• 流水线可视化编排
• 流水线支持任务插件无限扩展

2）基于容器化/虚拟化构建集群

使用容器化（Linux）/虚拟化（Mac Os）方案能够完全解决各类因资源共享带来的安全性和稳定性问题，每一个构建任务起全新的容器/虚拟机运行，构建任务完成后容器/虚拟机当即被销毁，不只能够有效隔离任务间运行环境，构建环境也“经常使用常新”，能够有效避免构建环境被破坏的问题；另外搭建稳定的无状态 容器化/虚拟化 构建集群，能够保证构建服务的高可用性。
下面第3、四章节，咱们会对这两个点分别展开详述，解密其设计架构和技术细节。

3、基于流水线的通用构建架构

1. 技术预研

---

业界基于流水线设计的友商产品其实并很多，尤为是国外同类产品较多，好比 Azure DevOps Pipeline 和 Github Actions 两款优秀的流水线产品，这两款产品在功能丰富度、易用性、文档、用户规模几个方面综合考虑较其余产品具备很多优点。
Azure DevOps前身是Visual Studio Team Services（VSTS），是一款已经有十几年历史的软件研发协做平台了，其Azure Pipeline产品在2018年4月发布[3]；Github Actions产品在2019年8月发布[4]，是微软收购Github后发布的一个重量级产品。整体来讲二者都属于比较新的平台，Azure Pipeline也不过2年多的时间。
预研中发现一个有意思的现象，因为Github已是微软子公司，两个流水线产品不只设计概念上类似，技术预研中发现两者的Mac虚拟化方案也是彼此技术共享的，甚至Mac虚拟化集群机房也是共享的。差别上Github Actions相对Azure Pipeline更为精简优雅一些，另外Github Actions依旧延续Github开源的风格，其流水线插件都是开源的，虽然上线仅1年多，已经有5000+开源插件。从插件的角度这是一座金矿，若是这批插件都能直接在Mobile DevOps用起来，基本流水线的功能插件就跟开源社区对齐了。考虑到将来支持这批开源插件的可能性，最终Mobile DevOps设计架构上也更加拥抱开源社区的Github Actions。

1. 流水线的核心概念

---

• Trigger
触发器，主动触发一次流水线执行
• Pipeline
流水线，被触发运行的最小单位。一个流水线能够包含1个或多个Job
• Job
Job是被调度的最小单位，按Job被调度到的执行环境不一样可分为Agent（构建集群）和Agentless（服务端）两种Job；
多个Job之间有能够无依赖并行运行，也能够有依赖顺序执行。多个Job以前的关系能够用一张DAG图表示；
每一个Job能够包含1个或多个Step
• Step

Step 是被执行的最小单位。每一个Job由多个顺序执行的Step组成

• Task

Task是预约义规格和功能的任务插件，能够在Step中被声明引用执行，一个Step只包含一个Task

1. 流水线的技术架构

---

流水线由如下几个核心系统组成：

1) Pipeline流程引擎

负责流水线的触发、编排、状态流转执行，以及流水线元数据信息维护。
流水线触发器模块
触发器模块负责触发一条流水线的执行，支持手动、定时器、事件（git event，webhook回调等）三种触发方式。触发器是流水线执行的惟一入口，在这一层能够作调用方的校验和检查，同时支持传入不一样的触发参数控制流水线的执行和调度过程。
流水线编排模块
流水线编排定义了一套用于描述一条流水线的DSL语言，基于这套DSL语言能够准肯定义一条可被调度和执行的流水线。
流水线执行模块
流水线执行模块主要确保流水线中全部Job都被按正确的依赖关系被并行或顺序执行，并实时更新流水线流转实时状态。

2）Job调度引擎

Job是流水线中被调度的最小单位，Job调度引擎主要负责每个从流水线流程引擎产生的Job被调度到正确的构建集群机器上。

3）集成引擎

流水线中的任务插件有两大类，一类是Agent任务，好比Android、iOS构建，这类任务须要特定的构建环境，因此很天然的想到会被Job调度引擎调度到构建机上；还有一类任务是Agentless任务，好比审批、通知、外部系统调用等，这类任务只要在普通server端便可完成，无需占用宝贵的构建资源，就会被Job调度引擎调度到集成引擎上执行。大部分Agentless任务都跟外部服务集成有关。

4）Channel通道服务

Channel通道主要负责构建集群跟服务端的通讯链路和协议实现。主要实现以下功能：
• 构建集群请求统一鉴权
出于安全性的考虑，构建集群跟其余微服务处于不一样的VPC，经过网络彻底隔离确保构建集群没法直接访问到服务端内网。基于这个背景，上述“流水线技术架构图”中的构建集群访问服务端走的是公网HTTPS请求，这就要对构建机请求作鉴权，Channel通道就是鉴权服务端收口
• 构建集群请求统一收口
构建集群须要跟服务端实时保持心跳、状态上报、拉取任务、上报任务执行状态，Channel是这些请求的收口，负责将不一样业务的请求分配到不一样的微服务上。

5）构建集群

构建集群主要负责拉取并执行Agent类构建任务，构建集群中运行的服务负责启动跟任务类型匹配的隔离构建环境：
• Linux平台下启动Docker容器
Android构建基于Linux平台，Linux平台下Docker容器化方案是环境隔离的不二之选，基于ACK serverless（阿里云公共云K8S类产品）启动serverless Docker容器，执行完自动销毁回收。基于云原生的ACK serverless实现了构建集群的弹性最大化，不构建几乎不占用任何计算资源，极大的控制了构建成本。
• Mac OS平台下启动虚拟机
因为苹果生态限制，iOS、Mac App构建只能在Mac OS系统下进行，而当前Mac OS没有成熟的相似Docker类容器方案可使用，最终咱们基于虚拟化方案来实现环境隔离。咱们自建了基于云架构的Mac虚拟化集群，将Mac物理资源完全池化，能够快速完成集群弹性扩缩容，彻底符合云原生的理念。每次构建都从虚拟化集群中动态建立一台虚机，构建完当即销毁。
值得一提的是，Mac虚拟化集群是咱们的技术优点，下面第五章咱们将详细Mobile DevOps在Mac虚拟化集群方向的实践。

4、Mac虚拟化构建集群

目前Mobile DevOps的Mac虚拟化集群构建方案在国内处于绝对的领先地位，咱们“也许”是国内第一家基于Mac虚拟机化技术实现iOS构建的DevOps平台，国内支持iOS构建的厂商几乎没有，其本质缘由实际上是Mac虚拟化技术限制：传统的Mac物理裸机构建只能在内部环境使用，根本不具有公共云开放服务的条件。Mac虚拟化构建集群方案是Mobile DevOps的技术优点。

1. 虚拟化方案选型

---

受Mac OS平台自己的内核限制，目前Mac OS平台容器化方案极其不成熟，Mac OS平台的环境隔离基本只剩下虚拟化这一条路能够走。
虚拟化类型的选择
两种类型的虚拟化方案以下图所示，两种方案都基于Hypervisor实现，两个方案对好比下：

虚拟化方案1：
• 无宿主OS直接基于Hypervisor虚拟化VM，资源利用率高，更适合云服务的虚拟化方案
• 对硬件兼容性有更高的要求
虚拟化方案2：
• 在宿主机的OS上再基于Hypervisor虚拟化VM，更适合桌面用户的虚拟化方案
• 因为有宿主机OS，硬件兼容性更好
基于咱们Mobile DevOps提供公共云服务的考虑，选择方案1能够更有效的提升资源利用率，硬件兼容性只要选择合适的硬件产品就能规避。
苹果生态安全合规问题
苹果生态封闭且有诸多安全合规限制，Mac平台有以下法务合规限制：

1.MacOS必须运行Apple硬件之上
2.在商业用途下，一个Apple硬件只容许运行一个macOS实例

从上述4种虚拟化方案对比，只有方案4是兼具苹果生态合规性和兼容性的，并且方案4其实也是上节咱们选择的虚拟化方案1。基于上述虚拟化类型和苹果生态安全合规性及兼容性考虑，咱们最终选定上述方案4。

1. 云架构的虚拟化集群

---

要在云上提供公共的构建服务，仅有虚拟化方案仍是不够的，还要有一套符合云架构的虚拟化集群方案，来知足Mobile DevOps对构建集群的诉求：
① Mac硬件资源池化 - 集群中的各个Mac资源应该是无状态的，全部Mac硬件资源共同组成一个资源池，能够被集群统一分配和调度。
② 弹性扩缩容 - 公共云业务规模存在必定的弹性，这就要求虚拟化集群也能够适应业务场景，能够快速弹性扩缩容，跟上业务的增加速度。
③ 高可用 - 在个别Mac硬件设备损坏的状况下，集群能够快速自动响应将任务分配到新的虚机上，提升任务执行成功率。
从单虚机到虚拟机集群，除了上述的Mac硬件资源池化，还要解决硬件资源集群化后新引入的分布式存储和分布式网络问题，从虚拟化单机到虚拟化集群以下图所示：

5、将来展望

将来展望

目前公共云Mobile DevOps还在公测阶段，还有不少方向须要努力：
• 增长构建错误智能分析、提示的能力。公共云用户众多的状况下，构建错误答疑是巨大的人力成本，后续须要基于关键字匹配，大数据分析，甚至是AI自动错误归类等技术手段直接提示构建错误缘由，减小人工答疑成本
• 跟EMAS其余产品增强更多的联动，让Mobile DevOps串联完整的应用研发生命周期
• 跟社区保持更好的亲和性。支持Github Actions、Azure Pipeline等其余平台流水线迁移到Mobile DevOps；任务插件直接支持Github Actions 5000+开源插件，享受开源社区红利
• 增强被集成能力，让Mobile DevOps移动研发平台能够更好的集成到客户现有的研发流程中
• 深度优化应用编译构建效率，减小应用构建时长。终极目标是要云上的应用构建时长大幅短于本地构建，让开发者直观感觉到云上构建的优点

原文连接本文为阿里云原创内容，未经容许不得转载。