阿里云 云原生利用研发平台EMAS 彭钊（州牧）
简介： DevOps这一优良的软件交付理念在服务端曾经有很多相干的实际，那么是否也能够利用到挪动端进行交付呢？基于挪动端和服务端场景的差别，挪动DevOps跟服务端DevOps又有哪些不同和挑战？本文分享阿里云云原生利用研发平台EMAS在建设云原生Mobile DevOps过程中的思考、遇到的挑战以及解法，解密其设计架构和技术细节。
一、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挪动研发平台能够更好的集成到客户现有的研发流程中
• 深度优化利用编译构建效率，缩小利用构建时长。终极目标是要云上的利用构建时长大幅短于本地构建，让开发者直观感触到云上构建的劣势
如果你对挪动构建编译技术、挪动研发技术、或者云原生的方向感兴趣，并且你是一个喜爱技术挑战的人，欢送退出咱们，咱们的指标是“做国内当先的挪动DevOps品牌”。➡️ 点击这里，查看岗位信息。
援用文献：
[1]Azure DevOps：什么是DevOps？
[2]百度统计流量研究院
[3]微软公布Azure Pipelines，开源我的项目可无限度应用CI/CD
[4]所有开源我的项目收费应用，GitHub 内置 CI/CD终于来了！