共计 8995 个字符，预计需要花费 23 分钟才能阅读完成。
简介： DevOps 这一优良的软件交付理念在服务端曾经有很多相干的实际，那么是否也能够利用到挪动端进行交付呢？基于挪动端和服务端场景的差别，挪动 DevOps 跟服务端 DevOps 又有哪些不同和挑战？本文分享阿里云云原生利用研发平台 EMAS 在建设云原生 Mobile DevOps 过程中的思考、遇到的挑战以及解法，解密其设计架构和技术细节。
阿里云 云原生利用研发平台 EMAS 彭钊（州牧）
一、Mobile DevOps 介绍
- 什么是挪动 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 利用生命周期及各阶段能力要求如下：
- 什么是 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 开始正式对外收费公测，目前已服务以及泛滥中小微客户，以及阿里团体外部专属钉钉、政务钉钉、唱鸭等客户。
二、云原生的 Mobile DevOps
绝对于专有云，公共云场景下建设云原生状态的 Mobile DevOps 面临更多的技术挑战，本章会跟大家分享咱们在建设云原生 Mobile DevOps 过程中的思考、遇到的挑战以及咱们的解法。
- 为什么须要公共云的 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“烟囱式”的一个个独立开源零碎，研发协同效率上也有显著劣势。
- 公共云 Mobile DevOps 面临的挑战
相比专有云内网部署、外部员工应用的场景，公共云状态下的 Mobile DevOps 会面临更多的技术挑战，次要体现在一下几个方面：
1）安全性
• 租户隔离
公共云面临的第一个问题就是租户隔离，不同客户既要同时应用共享资源，又不能相互看到对方的数据。对于构建这种场景，除了不同客户的构建工作可能会相互影响，构建环境还波及到用户的代码、证书等私密信息，必须要有欠缺的计划保障用户构建环境的隔离
• 代码、证书、秘钥等私密数据安全
有构建就必然波及用户代码、证书、秘钥，这些数据都是极其隐衷的数据，公共云存储、传输、应用任何环节出问题都可能会导致用户重大损失。
• 内部攻打
公共云因为裸露在公网任何人都能够应用，还面临歹意黑客攻击的危险，尤其构建场景波及大量的自定义执行命令，必须要有欠缺的机制避免黑客执行歹意自定义命令在构建环境内留下后门。
2）高可用性
• 必须反对弹性扩缩容
公共云业务规模增长时，须要业务要能疾速扩缩容适应业务增长，否则就会导致服务异样。这就要求云产品在技术实现上合乎分布式的架构，尤其是构建集群要反对无状态疾速扩容。
• 构建环境的稳定性
构建环境要稳固，防止因攻打或异样应用导致的构建环境被毁坏的状况，比方环境变量、构建工具链等。
• 高标准的 SLA，实时在线，永不宕机
高标准 SLA 既是对客户的承诺，也是对阿里云品牌的敬畏。
3）可扩展性
• 利用架构多样化导致的构建流程差别大
专有云客户数量无限，而且有欠缺的 KA 客户技术支持服务，所以利用的差别无限且有专人反对接入。但公共云环境下客户泛滥，利用架构多样性对系统的通用性、扩展性提出了更高的要求。
• 研发流程多样化
公共云不同客户研发团队规模、研发文化、研发流程都有差别，也对 Mobile DevOps 研发流程扩展性提出了更高的要求。
- 咱们的解法
针对以上公共云 Mobile DevOps 面临的挑战，咱们从以下两个方面通过技术手段去解决：
1）基于流水线的通用构建架构
流水线架构将构建做到通用化，基于流水线自定义编排构建流程，基于工作插件扩大流水线业务能力，很好的解决了上述的可扩展性问题。此架构具备以下特色：
• 通用构建架构，反对全平台构建能力
• 基于 YAML 自定义编排构建流程
• 流水线可视化编排
• 流水线反对工作插件有限扩大
2）基于容器化 / 虚拟化构建集群
应用容器化（Linux）/ 虚拟化（Mac Os）计划能够彻底解决各种因资源共享带来的安全性和稳定性问题，每个构建工作起全新的容器 / 虚拟机运行，构建工作实现后容器 / 虚拟机立刻被销毁，不仅能够无效隔离工作间运行环境，构建环境也“罕用常新”，能够无效防止构建环境被毁坏的问题；另外搭建稳固的无状态 容器化 / 虚拟化 构建集群，能够保障构建服务的高可用性。
上面第三、四章节，咱们会对这两个点别离开展详述，解密其设计架构和技术细节。
三、基于流水线的通用构建架构
- 技术预研
业界基于流水线设计的友商产品其实并不少，尤其是国外同类产品较多，比方 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。
- 流水线的外围概念
• 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) 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 的技术劣势。
- 虚拟化计划选型
受 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。
- 云架构的虚拟化集群
要在云上提供公共的构建服务，仅有虚拟化计划还是不够的，还要有一套合乎云架构的虚拟化集群计划，来满足 Mobile DevOps 对构建集群的诉求：
① Mac 硬件资源池化 – 集群中的各个 Mac 资源应该是无状态的，所有 Mac 硬件资源独特组成一个资源池，能够被集群统一分配和调度。
② 弹性扩缩容 – 公共云业务规模存在肯定的弹性，这就要求虚拟化集群也能够适应业务场景，能够疾速弹性扩缩容，跟上业务的增长速度。
③ 高可用 – 在个别 Mac 硬件设施损坏的状况下，集群能够疾速主动响应将任务分配到新的虚机上，进步工作执行成功率。
从单虚机到虚拟机集群，除了上述的 Mac 硬件资源池化，还要解决硬件资源集群化后新引入的分布式存储和分布式网络问题，从虚拟化单机到虚拟化集群如下图所示：
五、将来瞻望
将来瞻望
目前公共云 Mobile DevOps 还在公测阶段，还有很多方向须要致力：
• 减少构建谬误智能剖析、提醒的能力。公共云用户泛滥的状况下，构建谬误答疑是微小的人力老本，后续须要基于关键字匹配，大数据分析，甚至是 AI 主动谬误归类等技术手段间接提醒构建谬误起因，缩小人工答疑老本
• 跟 EMAS 其余产品增强更多的联动，让 Mobile DevOps 串联残缺的利用研发生命周期
• 跟社区放弃更好的亲和性。反对 Github Actions、Azure Pipeline 等其余平台流水线迁徙到 Mobile DevOps；工作插件间接反对 Github Actions 5000+ 开源插件，享受开源社区红利
• 增强被集成能力，让 Mobile DevOps 挪动研发平台能够更好的集成到客户现有的研发流程中
• 深度优化利用编译构建效率，缩小利用构建时长。终极目标是要云上的利用构建时长大幅短于本地构建，让开发者直观感触到云上构建的劣势
原文链接
本文为阿里云原创内容，未经容许不得转载。
