seo 网站文案模板,cn 域名网站,开发网站网络公司怎么样,手机网站电话漂浮代码简介#xff1a; DevOps这一优秀的软件交付理念在服务端已经有很多相关的实践#xff0c;那么是否也可以应用到移动端进行交付呢#xff1f;基于移动端和服务端场景的差异#xff0c;移动DevOps跟服务端DevOps又有哪些不同和挑战#xff1f;本文分享阿里云云原生应用研发平…简介 DevOps这一优秀的软件交付理念在服务端已经有很多相关的实践那么是否也可以应用到移动端进行交付呢基于移动端和服务端场景的差异移动DevOps跟服务端DevOps又有哪些不同和挑战本文分享阿里云云原生应用研发平台EMAS在建设云原生Mobile DevOps过程中的思考、遇到的挑战以及解法解密其设计架构和技术细节。 阿里云 云原生应用研发平台EMAS 彭钊州牧
一、Mobile DevOps 介绍
1. 什么是移动 DevOps
1大家所熟知的DevOps
在2020年这个时间节点上DevOps已经不再是什么新鲜概念相信大家或多或少都有些自己的理解但当要我们去准确描述什么是DevOps时好像又很难讲的清楚。实际上DevOps至今业界也没有可以让大家一致认可的定义之所以很难被准确定义是因为DevOps其实是一种理念甚至是一组理念的集合很难被具象化。“DevOps”这个词本身从字面可以理解为软件从DevDevelopment开发到OpsOperations运营的全生命周期但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应用生命周期及各阶段能力要求如下
2. 什么是Mobile DevOps
1Mobile DevOps 是EMAS移动DevOps理念的具象化实现
首先介绍一下EMASEnterprise Mobile Application StudioEMAS是来自阿里云的国内领先云原生应用研发平台移动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 运维域移动监控移动热修复 运营域移动推送移动用户反馈
2Mobile DevOps的历史
Mobile DevOps是集团内部移动研发平台的商业化输出版本最早于2017年由阿里云和手淘团队一起研发出输出第一版专有云输出版本2020年04月上线第一个公共云版本。 下面这张图是Mobile DevOps的发展史可以说Mobile DevOps的发展史其实就是阿里集团移动研发技术发展史是阿里巴巴近十年移动技术、工程研发理念沉淀。
3Mobile 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 50W50W 累计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 ServicesVSTS是一款已经有十几年历史的软件研发协作平台了其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. 流水线的核心概念 • 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. 流水线的技术架构 流水线由以下几个核心系统组成
1) Pipeline流程引擎
负责流水线的触发、编排、状态流转执行以及流水线元数据信息维护。 流水线触发器模块 触发器模块负责触发一条流水线的执行支持手动、定时器、事件git eventwebhook回调等三种触发方式。触发器是流水线执行的唯一入口在这一层可以做调用方的校验和检查同时支持传入不同的触发参数控制流水线的执行和调度过程。 流水线编排模块 流水线编排定义了一套用于描述一条流水线的DSL语言基于这套DSL语言可以准确定义一条可被调度和执行的流水线。 流水线执行模块 流水线执行模块主要确保流水线中所有Job都被按正确的依赖关系被并行或顺序执行并实时更新流水线流转实时状态。
2Job调度引擎
Job是流水线中被调度的最小单位Job调度引擎主要负责每一个从流水线流程引擎产生的Job被调度到正确的构建集群机器上。
3集成引擎
流水线中的任务插件有两大类一类是Agent任务比如Android、iOS构建这类任务需要特定的构建环境所以很自然的想到会被Job调度引擎调度到构建机上还有一类任务是Agentless任务比如审批、通知、外部系统调用等这类任务只要在普通server端即可完成无需占用宝贵的构建资源就会被Job调度引擎调度到集成引擎上执行。大部分Agentless任务都跟外部服务集成有关。
4Channel通道服务
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实现两个方案对比如下
虚拟化方案1 • 无宿主OS直接基于Hypervisor虚拟化VM资源利用率高更适合云服务的虚拟化方案 • 对硬件兼容性有更高的要求 虚拟化方案2 • 在宿主机的OS上再基于Hypervisor虚拟化VM更适合桌面用户的虚拟化方案 • 由于有宿主机OS硬件兼容性更好 基于我们Mobile DevOps提供公共云服务的考虑选择方案1可以更有效的提高资源利用率硬件兼容性只要选择合适的硬件产品就能规避。 苹果生态安全合规问题 苹果生态封闭且有诸多安全合规限制Mac平台有如下法务合规限制 1.MacOS必须运行Apple硬件之上 2.在商业用途下一个Apple硬件只允许运行一个macOS实例 从上述4种虚拟化方案对比只有方案4是兼具苹果生态合规性和兼容性的而且方案4其实也是上节我们选择的虚拟化方案1。基于上述虚拟化类型和苹果生态安全合规性及兼容性考虑我们最终选定上述方案4。
2. 云架构的虚拟化集群
要在云上提供公共的构建服务仅有虚拟化方案还是不够的还要有一套符合云架构的虚拟化集群方案来满足Mobile DevOps对构建集群的诉求 ① Mac硬件资源池化 - 集群中的各个Mac资源应该是无状态的所有Mac硬件资源共同组成一个资源池可以被集群统一分配和调度。 ② 弹性扩缩容 - 公共云业务规模存在一定的弹性这就要求虚拟化集群也可以适应业务场景可以快速弹性扩缩容跟上业务的增长速度。 ③ 高可用 - 在个别Mac硬件设备损坏的情况下集群可以快速自动响应将任务分配到新的虚机上提高任务执行成功率。 从单虚机到虚拟机集群除了上述的Mac硬件资源池化还要解决硬件资源集群化后新引入的分布式存储和分布式网络问题从虚拟化单机到虚拟化集群如下图所示
五、未来展望
未来展望
目前公共云Mobile DevOps还在公测阶段还有很多方向需要努力 • 增加构建错误智能分析、提示的能力。公共云用户众多的情况下构建错误答疑是巨大的人力成本后续需要基于关键字匹配大数据分析甚至是AI自动错误归类等技术手段直接提示构建错误原因减少人工答疑成本 • 跟EMAS其他产品加强更多的联动让Mobile DevOps串联完整的应用研发生命周期 • 跟社区保持更好的亲和性。支持Github Actions、Azure Pipeline等其他平台流水线迁移到Mobile DevOps任务插件直接支持Github Actions 5000开源插件享受开源社区红利 • 加强被集成能力让Mobile DevOps移动研发平台可以更好的集成到客户现有的研发流程中 • 深度优化应用编译构建效率减少应用构建时长。终极目标是要云上的应用构建时长大幅短于本地构建让开发者直观感受到云上构建的优势 原文链接 本文为阿里云原创内容未经允许不得转载。
