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

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

一、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%，可见机型碎片化之严重

image.png

• 操作系统版本碎片化

操作系统的差异对应用运行的影响更为直接，系统大版本升级导致应用不兼容的情况屡见不鲜，每次操作系统大版本发布都是对应用兼容性的一次考验；在考虑兼容新系统的同时，还不能放弃老系统的用户。

下图是 2020.10 月份最新的百度流量研究院的 Android 版本分布数据，可以看到已经发布一年多的 Android 10.0，市场占用率还不足 50%，2 年以前的操作系统依然占主流

image.png

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

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

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

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

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

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

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

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

image.png

2. 什么是 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 的发展史其实就是阿里集团移动研发技术发展史，是阿里巴巴近十年移动技术、工程研发理念沉淀。

image.png

3）Mobile DevOps 的现状

专有云已初具规模

Mobile DevOps 专有云主要面向大客户，尤其是正在做数字化转型的大客户，这部分客户对安全有很高的要求，基本只能接受专有云部署的模式，同时也愿意为提升研发效能投入成本。

2018 年 Mobile DevOps 以专有云场景正式落地输出，目前已经为多个行业数十家大客户创造价值，赋能企业研发流程数字化转型。

公共云免费公测中

相对于专有云，Mobile DevOps 公共云更多的是面向中小微企业，这部分客户对研发效能提升有诉求，但是又对价格敏感，公共云是很好的承接形式；同时阿里集团内部有些对外输出的业务（例如专属钉钉）无法基于集团内部研发平台去做移动 DevOps 的，Mobile DevOps 公共云也是很好的选择。

Mobile DevOps 公共云自 2020.07 开始正式对外免费公测，目前已服务以及众多中小微客户，以及阿里集团内部专属钉钉、政务钉钉、唱鸭等客户。

二、云原生的 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“烟囱式”的一个个独立开源系统，研发协同效率上也有明显优势。

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

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

1）安全性

• 租户隔离

公共云面临的第一个问题就是租户隔离，不同客户既要同时使用共享资源，又不能互相看到对方的数据。对于构建这种场景，除了不同客户的构建任务可能会互相影响，构建环境还涉及到用户的代码、证书等私密信息，必须要有完善的方案保证用户构建环境的隔离

• 代码、证书、秘钥等私密数据安全

有构建就必然涉及用户代码、证书、秘钥，这些数据都是极其隐私的数据，公共云存储、传输、使用任何环节出问题都可能会导致用户重大损失。

• 外部攻击

公共云由于暴露在公网任何人都可以使用，还面临恶意黑客攻击的风险，尤其构建场景涉及大量的自定义执行命令，必须要有完善的机制防止黑客执行恶意自定义命令在构建环境内留下后门。

2）高可用性

• 必须支持弹性扩缩容

公共云业务规模增长时，需要业务要能快速扩缩容适应业务增长，否则就会导致服务异常。这就要求云产品在技术实现上符合分布式的架构，尤其是构建集群要支持无状态快速扩容。

• 构建环境的稳定性

构建环境要稳定，避免因攻击或异常使用导致的构建环境被破坏的情况，比如环境变量、构建工具链等。

• 高标准的 SLA，实时在线，永不宕机

高标准 SLA 既是对客户的承诺，也是对阿里云品牌的敬畏。

3）可扩展性

• 应用架构多样化导致的构建流程差异大

专有云客户数量有限，而且有完善的 KA 客户技术支持服务，所以应用的差异有限且有专人支持接入。但公共云环境下客户众多，应用架构多样性对系统的通用性、扩展性提出了更高的要求。

• 研发流程多样化

公共云不同客户研发团队规模、研发文化、研发流程都有差异，也对 Mobile DevOps 研发流程扩展性提出了更高的要求。

3. 我们的解法

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

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

流水线架构将构建做到通用化，基于流水线自定义编排构建流程，基于任务插件扩展流水线业务能力，很好的解决了上述的可扩展性问题。此架构具有以下特色：

• 通用构建架构，支持全平台构建能力

• 基于 YAML 自定义编排构建流程

• 流水线可视化编排

• 流水线支持任务插件无限扩展

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

使用容器化（Linux）/虚拟化（Mac Os）方案可以彻底解决各种因资源共享带来的安全性和稳定性问题，每个构建任务起全新的容器/虚拟机运行，构建任务完成后容器/虚拟机立即被销毁，不仅可以有效隔离任务间运行环境，构建环境也“常用常新”，可以有效避免构建环境被破坏的问题；另外搭建稳定的无状态 容器化/虚拟化 构建集群，可以保证构建服务的高可用性。

下面第三、四章节，我们会对这两个点分别展开详述，解密其设计架构和技术细节。

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

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。

2. 流水线的核心概念

image.png

• 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

3. 流水线的技术架构

image.png

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

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 虚拟化集群方向的实践。

四、Mac 虚拟化构建集群

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

1. 虚拟化方案选型

受 Mac OS 平台本身的内核限制，目前 Mac OS 平台容器化方案极其不成熟，Mac OS 平台的环境隔离基本只剩下虚拟化这一条路可以走。

虚拟化类型的选择

两种类型的虚拟化方案如下图所示，两种方案都基于 Hypervisor 实现，两个方案对比如下：

image.png

虚拟化方案 1：

• 无宿主 OS 直接基于 Hypervisor 虚拟化 VM，资源利用率高，更适合云服务的虚拟化方案

• 对硬件兼容性有更高的要求

虚拟化方案 2：

• 在宿主机的 OS 上再基于 Hypervisor 虚拟化 VM，更适合桌面用户的虚拟化方案

• 由于有宿主机 OS，硬件兼容性更好

基于我们 Mobile DevOps 提供公共云服务的考虑，选择方案 1 可以更有效的提高资源利用率，硬件兼容性只要选择合适的硬件产品就能规避。

苹果生态安全合规问题

苹果生态封闭且有诸多安全合规限制，Mac 平台有如下法务合规限制：

1.MacOS 必须运行 Apple 硬件之上

2.在商业用途下，一个 Apple 硬件只允许运行一个 macOS 实例

image.png

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

2. 云架构的虚拟化集群

要在云上提供公共的构建服务，仅有虚拟化方案还是不够的，还要有一套符合云架构的虚拟化集群方案，来满足 Mobile DevOps 对构建集群的诉求：

① Mac 硬件资源池化 - 集群中的各个 Mac 资源应该是无状态的，所有 Mac 硬件资源共同组成一个资源池，可以被集群统一分配和调度。

② 弹性扩缩容 - 公共云业务规模存在一定的弹性，这就要求虚拟化集群也可以适应业务场景，可以快速弹性扩缩容，跟上业务的增长速度。

③ 高可用 - 在个别 Mac 硬件设备损坏的情况下，集群可以快速自动响应将任务分配到新的虚机上，提高任务执行成功率。

从单虚机到虚拟机集群，除了上述的 Mac 硬件资源池化，还要解决硬件资源集群化后新引入的分布式存储和分布式网络问题，从虚拟化单机到虚拟化集群如下图所示：

image.png

五、未来展望

未来展望

目前公共云 Mobile DevOps 还在公测阶段，还有很多方向需要努力：

• 增加构建错误智能分析、提示的能力。公共云用户众多的情况下，构建错误答疑是巨大的人力成本，后续需要基于关键字匹配，大数据分析，甚至是 AI 自动错误归类等技术手段直接提示构建错误原因，减少人工答疑成本

• 跟 EMAS 其他产品加强更多的联动，让 Mobile DevOps 串联完整的应用研发生命周期

• 跟社区保持更好的亲和性。支持 Github Actions、Azure Pipeline 等其他平台流水线迁移到 Mobile DevOps；任务插件直接支持 Github Actions 5000+开源插件，享受开源社区红利

• 加强被集成能力，让 Mobile DevOps 移动研发平台可以更好的集成到客户现有的研发流程中

• 深度优化应用编译构建效率，减少应用构建时长。终极目标是要云上的应用构建时长大幅短于本地构建，让开发者直观感受到云上构建的优势

如果你对移动构建编译技术、移动研发技术、或者云原生的方向感兴趣，并且你是一个喜欢技术挑战的人，欢迎加入我们，我们的目标是“做国际领先的移动 DevOps 品牌”。➡️ 点击这里，查看岗位信息。

引用文献：

[1]Azure DevOps：什么是DevOps？

[2]百度统计流量研究院

[3]微软发布Azure Pipelines，开源项目可无限制使用CI/CD

[4]所有开源项目免费使用，GitHub 内置 CI/CD终于来了！