簡(jiǎn)介：DevOps這一優(yōu)秀的軟件交付理念在服務(wù)端已經(jīng)有很多相關(guān)的實(shí)踐，那么是否也可以應(yīng)用到移動(dòng)端進(jìn)行交付呢？基于移動(dòng)端和服務(wù)端場(chǎng)景的差異，移動(dòng)DevOps跟服務(wù)端DevOps又有哪些不同和挑戰(zhàn)？本文分享阿里云云原生應(yīng)用研發(fā)平臺(tái)EMAS在建設(shè)云原生Mobile DevOps過(guò)程中的思考、遇到的挑戰(zhàn)以及解法，解密其設(shè)計(jì)架構(gòu)和技術(shù)細(xì)節(jié)。

一 Mobile DevOps 介紹

1 什么是移動(dòng) DevOps

大家所熟知的DevOps

在2020年這個(gè)時(shí)間節(jié)點(diǎn)上，DevOps已經(jīng)不再是什么新鮮概念，相信大家或多或少都有些自己的理解，但當(dāng)要我們?nèi)?zhǔn)確描述什么是DevOps時(shí)，好像又很難講清楚。實(shí)際上DevOps至今業(yè)界也沒(méi)有可以讓大家一致認(rèn)可的定義，之所以很難被準(zhǔn)確定義，是因?yàn)镈evOps其實(shí)是一種理念甚至是一組理念的集合，很難被具象化。“DevOps”這個(gè)詞本身從字面可以理解為軟件從Dev（Development，開發(fā)）到Ops（Operations，運(yùn)營(yíng)）的全生命周期，但DevOps的準(zhǔn)確定義到底是什么？在眾多的DevOps定義中，個(gè)人認(rèn)為Azure DevOps的定義[1]較為精確和具體：

DevOps 是開發(fā) (Dev) 和運(yùn)營(yíng) (Ops) 的復(fù)合詞，它將人、流程和技術(shù)結(jié)合起來(lái)，不斷地為客戶提供價(jià)值。
DevOps 對(duì)團(tuán)隊(duì)意味著什么？DevOps 使以前孤立的角色（開發(fā)、IT 運(yùn)營(yíng)、質(zhì)量工程和安全）可以協(xié)調(diào)和協(xié)作，以生產(chǎn)更好、更可靠的產(chǎn)品。
通過(guò)采用 DevOps 文化、做法和工具，團(tuán)隊(duì)能夠更好地響應(yīng)客戶需求，增強(qiáng)對(duì)所構(gòu)建應(yīng)用程序的信心，更快地實(shí)現(xiàn)業(yè)務(wù)目標(biāo)。

這個(gè)定義里有幾個(gè)關(guān)鍵信息總結(jié)一下：

• 人、流程、技術(shù)的結(jié)合
• DevOps使讓以前孤立的角色可以協(xié)調(diào)和協(xié)作
• DevOps是一種理念，既要樹立文化，也要有自動(dòng)化工具的支持
• 目的是更快的生產(chǎn)更好、更可靠的產(chǎn)品

從DevOps到移動(dòng)DevOps

對(duì)于DevOps大家平時(shí)討論比較多的其實(shí)是服務(wù)端DevOps，既然DevOps是一種優(yōu)秀的軟件交付理念，為什么不把DevOps也應(yīng)用到移動(dòng)端交付呢？這也就是我們今天要介紹的移動(dòng)DevOps。

因?yàn)橐苿?dòng)端和服務(wù)端場(chǎng)景的差異，移動(dòng)DevOps跟服務(wù)端DevOps會(huì)有很大的不同。主要體現(xiàn)在以下幾個(gè)方面：

1）移動(dòng)端應(yīng)用自動(dòng)化構(gòu)建更為復(fù)雜

首先，移動(dòng)端構(gòu)建環(huán)境存在碎片化問(wèn)題。Android、iOS兩個(gè)平臺(tái)需要基于不同的操作系統(tǒng)和構(gòu)建工具鏈搭建構(gòu)建環(huán)境，即便是同一平臺(tái)構(gòu)建工具鏈也存在版本碎片化現(xiàn)象，比如Android構(gòu)建依賴的Android SDK、Gradle需要多個(gè)版本同時(shí)支持，iOS構(gòu)建依賴的Xcode、Ruby版本需要多個(gè)版本同時(shí)支持。

其次，iOS構(gòu)建依賴的Mac設(shè)備為機(jī)房非標(biāo)設(shè)備，因此無(wú)法部署在標(biāo)準(zhǔn)機(jī)房，通常需要自建Mac機(jī)房，對(duì)于可運(yùn)維性和穩(wěn)定性也是一個(gè)挑戰(zhàn)。

自動(dòng)化構(gòu)建是DevOps中必不可少的能力，這就要求移動(dòng)DevOps通過(guò)技術(shù)手段很好的解決上述客戶端自動(dòng)化構(gòu)建、一鍵出包的問(wèn)題。

2）移動(dòng)端碎片化嚴(yán)重，應(yīng)用交付兼容性是巨大的挑戰(zhàn)

不同于服務(wù)端部署環(huán)境的一致性，移動(dòng)端應(yīng)用運(yùn)行環(huán)境碎片化非常嚴(yán)重，兼容性測(cè)試覆蓋難度遠(yuǎn)大于服務(wù)端。移動(dòng)端碎片化現(xiàn)象以Android系統(tǒng)尤為嚴(yán)重：

Android市場(chǎng)有眾多的手機(jī)廠商和茫茫多的機(jī)型，不同廠商都會(huì)對(duì)系統(tǒng)做底層“優(yōu)化”，理論上任何覆蓋不到的機(jī)型測(cè)試都可能會(huì)面臨兼容性問(wèn)題，下圖是2020.10月份最新的百度統(tǒng)計(jì)流量研究院[2]的Android Top機(jī)型分布，Top 10的機(jī)型市場(chǎng)占用率都不足15%，可見(jiàn)機(jī)型碎片化之嚴(yán)重。

操作系統(tǒng)的差異對(duì)應(yīng)用運(yùn)行的影響更為直接，系統(tǒng)大版本升級(jí)導(dǎo)致應(yīng)用不兼容的情況屢見(jiàn)不鮮，每次操作系統(tǒng)大版本發(fā)布都是對(duì)應(yīng)用兼容性的一次考驗(yàn)；在考慮兼容新系統(tǒng)的同時(shí)，還不能放棄老系統(tǒng)的用戶。

下圖是2020.10月份最新的百度流量研究院的Android版本分布數(shù)據(jù)，可以看到已經(jīng)發(fā)布一年多的Android 10.0，市場(chǎng)占用率還不足50%，2年以前的操作系統(tǒng)依然占主流。

由于端設(shè)備的碎片化問(wèn)題，就需要移動(dòng)DevOps具備移動(dòng)測(cè)試能力，自動(dòng)化完成大量的真機(jī)兼容性測(cè)試。

3）移動(dòng)端應(yīng)用發(fā)布更新周期長(zhǎng)

應(yīng)用新版本可能發(fā)布2周更新比例都不會(huì)超過(guò)50%，不像服務(wù)端可以在很短的時(shí)間內(nèi)完成所有服務(wù)器的軟件發(fā)布。發(fā)布周期長(zhǎng)意味著犯錯(cuò)成本更高，一個(gè)有Bug的版本發(fā)出去，可能需要很長(zhǎng)的時(shí)間才能通過(guò)更新升級(jí)消化完。

這就需要移動(dòng)DevOps一方面具備完善的灰度發(fā)布機(jī)制，避免將有問(wèn)題的應(yīng)用一次性發(fā)布到用戶側(cè)；另一方面一旦有Bug的版本已經(jīng)發(fā)出，需要移動(dòng)DevOps具備熱修復(fù)能力，可以通過(guò)增量補(bǔ)丁包的發(fā)布方式更輕量、快速的修復(fù)Bug。

4）移動(dòng)應(yīng)用運(yùn)行在海量移動(dòng)端設(shè)備

不像服務(wù)端服務(wù)運(yùn)行在特定的集群內(nèi)，可以統(tǒng)一管控和運(yùn)維，移動(dòng)應(yīng)用的運(yùn)行環(huán)境在用戶的手機(jī)上，而且對(duì)于手淘這類超級(jí)App來(lái)講是億級(jí)海量設(shè)備。

這就需要移動(dòng)監(jiān)控類產(chǎn)品通過(guò)大數(shù)據(jù)技術(shù)來(lái)實(shí)現(xiàn)移動(dòng)端運(yùn)維監(jiān)控，甚至需要遠(yuǎn)程日志功能來(lái)拉取指定設(shè)備上的錯(cuò)誤日志來(lái)定位排查錯(cuò)誤。

基于以上幾點(diǎn)，并參考DevOps對(duì)軟件交付生命周期的定義，總結(jié)移動(dòng)DevOps應(yīng)用生命周期及各階段能力要求如下：

2 什么是Mobile DevOps

Mobile DevOps 是EMAS移動(dòng)DevOps理念的具象化實(shí)現(xiàn)

首先介紹一下EMAS（Enterprise Mobile Application Studio），EMAS是來(lái)自阿里云的國(guó)內(nèi)領(lǐng)先云原生應(yīng)用研發(fā)平臺(tái)（移動(dòng)App、H5應(yīng)用、小程序、Web應(yīng)用等），基于廣泛的云原生技術(shù)（Backend as a Service、Serverless、DevOps、低代碼等），致力于為企業(yè)、開發(fā)者提供一站式的應(yīng)用研發(fā)管理服務(wù)，涵蓋開發(fā)、測(cè)試、運(yùn)維、運(yùn)營(yíng)等應(yīng)用全生命周期。更多關(guān)于EMAS的介紹詳見(jiàn)阿里云官網(wǎng)EMAS詳情頁(yè)。

Mobile DevOps是EMAS移動(dòng)DevOps理念的具象化產(chǎn)品輸出，是EMAS的中軸型產(chǎn)品，它聯(lián)動(dòng)EMAS所有產(chǎn)品共同實(shí)現(xiàn)上述移動(dòng)DevOps理念。Mobile DevOps將EMAS原本孤立在應(yīng)用各個(gè)生命周期的產(chǎn)品像上圖一樣實(shí)現(xiàn)了聯(lián)動(dòng)和完整閉環(huán)，實(shí)現(xiàn)了EMAS從移動(dòng)中間件平臺(tái)向移動(dòng)研發(fā)平臺(tái)的升級(jí)。Mobile DevOps結(jié)合以下EMAS產(chǎn)品共同形成EMAS的移動(dòng)DevOps：

• 研發(fā)域：Mobile DevOps
• 測(cè)試域：移動(dòng)測(cè)試
• 發(fā)布域：Mobile DevOps
• 運(yùn)維域：移動(dòng)監(jiān)控，移動(dòng)熱修復(fù)
• 運(yùn)營(yíng)域：移動(dòng)推送，移動(dòng)用戶反饋

Mobile DevOps的歷史

Mobile DevOps是集團(tuán)內(nèi)部移動(dòng)研發(fā)平臺(tái)的商業(yè)化輸出版本，最早于2017年由阿里云和手淘團(tuán)隊(duì)一起研發(fā)出輸出第一版專有云輸出版本，2020年04月上線第一個(gè)公共云版本。

下面這張圖是Mobile DevOps的發(fā)展史，可以說(shuō)Mobile DevOps的發(fā)展史其實(shí)就是阿里集團(tuán)移動(dòng)研發(fā)技術(shù)發(fā)展史，是阿里巴巴近十年移動(dòng)技術(shù)、工程研發(fā)理念沉淀。

Mobile DevOps的現(xiàn)狀

1）專有云已初具規(guī)模

Mobile DevOps專有云主要面向大客戶，尤其是正在做數(shù)字化轉(zhuǎn)型的大客戶，這部分客戶對(duì)安全有很高的要求，基本只能接受專有云部署的模式，同時(shí)也愿意為提升研發(fā)效能投入成本。

2018年Mobile DevOps以專有云場(chǎng)景正式落地輸出，目前已經(jīng)為多個(gè)行業(yè)數(shù)十家大客戶創(chuàng)造價(jià)值，賦能企業(yè)研發(fā)流程數(shù)字化轉(zhuǎn)型。

2）公共云免費(fèi)公測(cè)中

相對(duì)于專有云，Mobile DevOps公共云更多的是面向中小微企業(yè)，這部分客戶對(duì)研發(fā)效能提升有訴求，但是又對(duì)價(jià)格敏感，公共云是很好的承接形式；同時(shí)阿里集團(tuán)內(nèi)部有些對(duì)外輸出的業(yè)務(wù)（例如專屬釘釘）無(wú)法基于集團(tuán)內(nèi)部研發(fā)平臺(tái)去做移動(dòng)DevOps的，Mobile DevOps公共云也是很好的選擇。

Mobile DevOps公共云自2020.07開始正式對(duì)外免費(fèi)公測(cè)，目前已服務(wù)以及眾多中小微客戶，以及阿里集團(tuán)內(nèi)部專屬釘釘、政務(wù)釘釘、唱鴨等客戶。

二 云原生的Mobile DevOps

相對(duì)于專有云，公共云場(chǎng)景下建設(shè)云原生形態(tài)的Mobile DevOps面臨更多的技術(shù)挑戰(zhàn)，本章會(huì)跟大家分享我們?cè)诮ㄔO(shè)云原生Mobile DevOps過(guò)程中的思考、遇到的挑戰(zhàn)以及我們的解法。

1 為什么需要公共云的 Mobile DevOps

面向中小微客戶提供普惠型Mobile DevOps服務(wù)

雖然專有云部署具有獨(dú)享、內(nèi)網(wǎng)安全隔離等優(yōu)勢(shì)，但專有云交付的高成本注定只有行業(yè)高端玩家才有能力接受。專有云Mobile DevOps成本投入評(píng)估如下：

• 一次性投入：百萬(wàn)級(jí)一次性采購(gòu)費(fèi)用
• 持續(xù)投入：至少30 W/年服務(wù)器成本 + 20 W/年人力維護(hù)成本

基于上述成本計(jì)算，專有云第一年、第二年、第三年的的投入成本分別為：150W ，50W，50W 累計(jì)200W，這對(duì)于中小微客戶是無(wú)法接受的。

阿里云作為新時(shí)代的基礎(chǔ)設(shè)施，新時(shí)代的水電煤，有必要為更多大客戶以外的中小微企業(yè)提供普惠型云服務(wù)。而公共云形態(tài)的Mobile DevOps恰好符合這樣的理念，基于云原生彈性擴(kuò)縮容、按量計(jì)費(fèi)的優(yōu)勢(shì)，可以極大降低中小微客戶使用Mobile DevOps的成本。同時(shí)公共云場(chǎng)景下針對(duì)中小微客戶的特點(diǎn)提供更適合目標(biāo)客戶的DevOps研發(fā)流程。

聯(lián)動(dòng)EMAS產(chǎn)品線為開發(fā)者提供一站式移動(dòng)研發(fā)平臺(tái)

公共云Mobile DevOps的上線，可以有效聯(lián)動(dòng)EMAS現(xiàn)有移動(dòng)測(cè)試、移動(dòng)監(jiān)控、移動(dòng)熱修復(fù)等產(chǎn)品，讓EMAS覆蓋應(yīng)用全生命周期，完成EMAS從移動(dòng)中間件到移動(dòng)研發(fā)平臺(tái)的升級(jí)，提升用戶體驗(yàn)和粘性。

EMAS一站式移動(dòng)研發(fā)平臺(tái)較傳統(tǒng)基于開源方案Jekins、Gitlab Runner等自建CI/CD平臺(tái)，在成本、高可用性、技術(shù)支持力度等方面都有明顯優(yōu)勢(shì)，而且可以一站式覆蓋應(yīng)用構(gòu)建、測(cè)試、發(fā)布、運(yùn)維、運(yùn)營(yíng)全生命周期管理，較傳統(tǒng)自建CI/CD“煙囪式”的一個(gè)個(gè)獨(dú)立開源系統(tǒng)，研發(fā)協(xié)同效率上也有明顯優(yōu)勢(shì)。

2 公共云 Mobile DevOps面臨的挑戰(zhàn)

相比專有云內(nèi)網(wǎng)部署、內(nèi)部員工使用的場(chǎng)景，公共云形態(tài)下的Mobile DevOps會(huì)面臨更多的技術(shù)挑戰(zhàn)，主要體現(xiàn)在以下幾個(gè)方面：

安全性

1）租戶隔離

公共云面臨的第一個(gè)問(wèn)題就是租戶隔離，不同客戶既要同時(shí)使用共享資源，又不能互相看到對(duì)方的數(shù)據(jù)。對(duì)于構(gòu)建這種場(chǎng)景，除了不同客戶的構(gòu)建任務(wù)可能會(huì)互相影響，構(gòu)建環(huán)境還涉及到用戶的代碼、證書等私密信息，必須要有完善的方案保證用戶構(gòu)建環(huán)境的隔離。

2）代碼、證書、秘鑰等私密數(shù)據(jù)安全

有構(gòu)建就必然涉及用戶代碼、證書、秘鑰，這些數(shù)據(jù)都是極其隱私的數(shù)據(jù)，公共云存儲(chǔ)、傳輸、使用任何環(huán)節(jié)出問(wèn)題都可能會(huì)導(dǎo)致用戶重大損失。

3）外部攻擊

公共云由于暴露在公網(wǎng)任何人都可以使用，還面臨惡意黑客攻擊的風(fēng)險(xiǎn)，尤其構(gòu)建場(chǎng)景涉及大量的自定義執(zhí)行命令，必須要有完善的機(jī)制防止黑客執(zhí)行惡意自定義命令在構(gòu)建環(huán)境內(nèi)留下后門。

高可用性

1）必須支持彈性擴(kuò)縮容

公共云業(yè)務(wù)規(guī)模增長(zhǎng)時(shí)，需要業(yè)務(wù)能快速擴(kuò)容適應(yīng)業(yè)務(wù)增長(zhǎng)，否則就會(huì)導(dǎo)致服務(wù)異常。這就要求云產(chǎn)品在技術(shù)實(shí)現(xiàn)上符合分布式的架構(gòu)，尤其是構(gòu)建集群要支持無(wú)狀態(tài)快速擴(kuò)容。

2）構(gòu)建環(huán)境的穩(wěn)定性

構(gòu)建環(huán)境要穩(wěn)定，避免因攻擊或異常使用導(dǎo)致的構(gòu)建環(huán)境被破壞的情況，比如環(huán)境變量、構(gòu)建工具鏈等。

3）高標(biāo)準(zhǔn)的SLA，實(shí)時(shí)在線，永不宕機(jī)

高標(biāo)準(zhǔn)SLA既是對(duì)客戶的承諾，也是對(duì)阿里云品牌的敬畏。

可擴(kuò)展性

1）應(yīng)用架構(gòu)多樣化導(dǎo)致的構(gòu)建流程差異大

專有云客戶數(shù)量有限，而且有完善的KA客戶技術(shù)支持服務(wù)，所以應(yīng)用的差異有限且有專人支持接入。但公共云環(huán)境下客戶眾多，應(yīng)用架構(gòu)多樣性對(duì)系統(tǒng)的通用性、擴(kuò)展性提出了更高的要求。

2）研發(fā)流程多樣化

公共云不同客戶研發(fā)團(tuán)隊(duì)規(guī)模、研發(fā)文化、研發(fā)流程都有差異，也對(duì)Mobile DevOps研發(fā)流程擴(kuò)展性提出了更高的要求。

3 我們的解法

針對(duì)以上公共云Mobile DevOps面臨的挑戰(zhàn)，我們從以下兩個(gè)方面通過(guò)技術(shù)手段去解決：

基于流水線的通用構(gòu)建架構(gòu)

流水線架構(gòu)將構(gòu)建做到通用化，基于流水線自定義編排構(gòu)建流程，基于任務(wù)插件擴(kuò)展流水線業(yè)務(wù)能力，很好的解決了上述的可擴(kuò)展性問(wèn)題。此架構(gòu)具有以下特色：

• 通用構(gòu)建架構(gòu)，支持全平臺(tái)構(gòu)建能力
• 基于YAML自定義編排構(gòu)建流程
• 流水線可視化編排
• 流水線支持任務(wù)插件無(wú)限擴(kuò)展

基于容器化/虛擬化構(gòu)建集群

使用容器化（Linux）/虛擬化（Mac Os）方案可以徹底解決各種因資源共享帶來(lái)的安全性和穩(wěn)定性問(wèn)題，每個(gè)構(gòu)建任務(wù)由全新的容器/虛擬機(jī)運(yùn)行，構(gòu)建任務(wù)完成后容器/虛擬機(jī)立即被銷毀，不僅可以有效隔離任務(wù)間運(yùn)行環(huán)境，構(gòu)建環(huán)境也“常用常新”，可以有效避免構(gòu)建環(huán)境被破壞的問(wèn)題；另外搭建穩(wěn)定的無(wú)狀態(tài) 容器化/虛擬化 構(gòu)建集群，可以保證構(gòu)建服務(wù)的高可用性。

下面第三、四章節(jié)，我們會(huì)對(duì)這兩個(gè)點(diǎn)分別展開詳述，解密其設(shè)計(jì)架構(gòu)和技術(shù)細(xì)節(jié)。

三 基于流水線的通用構(gòu)建架構(gòu)

1 行業(yè)現(xiàn)狀

業(yè)界基于流水線設(shè)計(jì)的友商產(chǎn)品其實(shí)并不少，尤其是國(guó)外同類產(chǎn)品較多，比如 Azure DevOps Pipeline 和 Github Actions 兩款優(yōu)秀的流水線產(chǎn)品，這兩款產(chǎn)品在功能豐富度、易用性、文檔、用戶規(guī)模幾個(gè)方面綜合考慮較其他產(chǎn)品具有不少優(yōu)勢(shì)。

Azure DevOps前身是Visual Studio Team Services（VSTS），是一款已經(jīng)有十幾年歷史的軟件研發(fā)協(xié)作平臺(tái)了，其Azure Pipeline產(chǎn)品在2018年4月發(fā)布[3]；Github Actions產(chǎn)品在2019年8月發(fā)布[4]，是微軟收購(gòu)Github后發(fā)布的一個(gè)重量級(jí)產(chǎn)品。總體來(lái)說(shuō)兩者都屬于比較新的平臺(tái)，Azure Pipeline也不過(guò)2年多的時(shí)間。

2 流水線的核心概念

Trigger

觸發(fā)器，主動(dòng)觸發(fā)一次流水線執(zhí)行。

Pipeline

流水線，被觸發(fā)運(yùn)行的最小單位。一個(gè)流水線可以包含1個(gè)或多個(gè)Job。

Job

Job是被調(diào)度的最小單位，按Job被調(diào)度到的執(zhí)行環(huán)境不同可分為Agent（構(gòu)建集群）和Agentless（服務(wù)端）兩種Job。

多個(gè)Job之間有可以無(wú)依賴并行運(yùn)行，也可以有依賴順序執(zhí)行。多個(gè)Job之前的關(guān)系可以用一張DAG圖表示。

每個(gè)Job可以包含1個(gè)或多個(gè)Step。

Step

Step 是被執(zhí)行的最小單位。每個(gè)Job由多個(gè)順序執(zhí)行的Step組成。

Task

Task是預(yù)定義規(guī)格和功能的任務(wù)插件，可以在Step中被聲明引用執(zhí)行，一個(gè)Step只包含一個(gè)Task。

3 流水線的技術(shù)架構(gòu)

流水線由以下幾個(gè)核心系統(tǒng)組成：

Pipeline流程引擎

負(fù)責(zé)流水線的觸發(fā)、編排、狀態(tài)流轉(zhuǎn)執(zhí)行，以及流水線元數(shù)據(jù)信息維護(hù)。

1）流水線觸發(fā)器模塊

觸發(fā)器模塊負(fù)責(zé)觸發(fā)一條流水線的執(zhí)行，支持手動(dòng)、定時(shí)器、事件（git event，webhook回調(diào)等）三種觸發(fā)方式。觸發(fā)器是流水線執(zhí)行的唯一入口，在這一層可以做調(diào)用方的校驗(yàn)和檢查，同時(shí)支持傳入不同的觸發(fā)參數(shù)控制流水線的執(zhí)行和調(diào)度過(guò)程。

2）流水線編排模塊

流水線編排定義了一套用于描述一條流水線的DSL語(yǔ)言，基于這套DSL語(yǔ)言可以準(zhǔn)確定義一條可被調(diào)度和執(zhí)行的流水線。

3）流水線執(zhí)行模塊

流水線執(zhí)行模塊主要確保流水線中所有Job都被按正確的依賴關(guān)系被并行或順序執(zhí)行，并實(shí)時(shí)更新流水線流轉(zhuǎn)實(shí)時(shí)狀態(tài)。

Job調(diào)度引擎

Job是流水線中被調(diào)度的最小單位，Job調(diào)度引擎主要負(fù)責(zé)每一個(gè)從流水線流程引擎產(chǎn)生的Job被調(diào)度到正確的構(gòu)建集群機(jī)器上。

集成引擎

流水線中的任務(wù)插件有兩大類，一類是Agent任務(wù)，比如Android、iOS構(gòu)建，這類任務(wù)需要特定的構(gòu)建環(huán)境，所以很自然的想到會(huì)被Job調(diào)度引擎調(diào)度到構(gòu)建機(jī)上；還有一類任務(wù)是Agentless任務(wù)，比如審批、通知、外部系統(tǒng)調(diào)用等，這類任務(wù)只要在普通server端即可完成，無(wú)需占用寶貴的構(gòu)建資源，就會(huì)被Job調(diào)度引擎調(diào)度到集成引擎上執(zhí)行。大部分Agentless任務(wù)都跟外部服務(wù)集成有關(guān)。

Channel通道服務(wù)

Channel通道主要負(fù)責(zé)構(gòu)建集群跟服務(wù)端的通信鏈路和協(xié)議實(shí)現(xiàn)。主要實(shí)現(xiàn)如下功能：

1）構(gòu)建集群請(qǐng)求統(tǒng)一鑒權(quán)

出于安全性的考慮，構(gòu)建集群跟其他微服務(wù)處于不同的VPC，通過(guò)網(wǎng)絡(luò)完全隔離確保構(gòu)建集群無(wú)法直接訪問(wèn)到服務(wù)端內(nèi)網(wǎng)。基于這個(gè)背景，上述“流水線技術(shù)架構(gòu)圖”中的構(gòu)建集群訪問(wèn)服務(wù)端走的是公網(wǎng)HTTPS請(qǐng)求，這就要對(duì)構(gòu)建機(jī)請(qǐng)求做鑒權(quán)，Channel通道就是鑒權(quán)服務(wù)端收口。

2）構(gòu)建集群請(qǐng)求統(tǒng)一收口

構(gòu)建集群需要跟服務(wù)端實(shí)時(shí)保持心跳、狀態(tài)上報(bào)、拉取任務(wù)、上報(bào)任務(wù)執(zhí)行狀態(tài)，Channel是這些請(qǐng)求的收口，負(fù)責(zé)將不同業(yè)務(wù)的請(qǐng)求分配到不同的微服務(wù)上。

構(gòu)建集群

構(gòu)建集群主要負(fù)責(zé)拉取并執(zhí)行Agent類構(gòu)建任務(wù)，構(gòu)建集群中運(yùn)行的服務(wù)負(fù)責(zé)啟動(dòng)跟任務(wù)類型匹配的隔離構(gòu)建環(huán)境：

1）Linux平臺(tái)下啟動(dòng)Docker容器

Android構(gòu)建基于Linux平臺(tái)，Linux平臺(tái)下Docker容器化方案是環(huán)境隔離的不二之選，基于ACK serverless（阿里云公共云K8S類產(chǎn)品）啟動(dòng)serverless Docker容器，執(zhí)行完自動(dòng)銷毀回收。基于云原生的ACK serverless實(shí)現(xiàn)了構(gòu)建集群的彈性最大化，不構(gòu)建幾乎不占用任何計(jì)算資源，極大的控制了構(gòu)建成本。

2）Mac OS平臺(tái)下啟動(dòng)虛擬機(jī)

由于蘋果生態(tài)限制，iOS、Mac App構(gòu)建只能在Mac OS系統(tǒng)下進(jìn)行，而當(dāng)前Mac OS沒(méi)有成熟的類似Docker類容器方案可以使用，最終我們基于虛擬化方案來(lái)實(shí)現(xiàn)環(huán)境隔離。我們自建了基于云架構(gòu)的Mac虛擬化集群，將Mac物理資源徹底池化，可以快速完成集群彈性擴(kuò)縮容，完全符合云原生的理念。每次構(gòu)建都從虛擬化集群中動(dòng)態(tài)創(chuàng)建一臺(tái)虛機(jī)，構(gòu)建完立即銷毀。

值得一提的是，Mac虛擬化集群是我們的技術(shù)優(yōu)勢(shì)，下面第五章我們將詳細(xì)Mobile DevOps在Mac虛擬化集群方向的實(shí)踐。

四 Mac虛擬化構(gòu)建集群

目前Mobile DevOps的Mac虛擬化集群構(gòu)建方案在國(guó)內(nèi)處于絕對(duì)的領(lǐng)先地位，我們“也許”是國(guó)內(nèi)第一家基于Mac虛擬機(jī)化技術(shù)實(shí)現(xiàn)iOS構(gòu)建的DevOps平臺(tái)，國(guó)內(nèi)支持iOS構(gòu)建的廠商幾乎沒(méi)有，其本質(zhì)原因其實(shí)是Mac虛擬化技術(shù)限制：傳統(tǒng)的Mac物理裸機(jī)構(gòu)建只能在內(nèi)部環(huán)境使用，根本不具備公共云開放服務(wù)的條件。Mac虛擬化構(gòu)建集群方案是Mobile DevOps的技術(shù)優(yōu)勢(shì)。

1 虛擬化方案選型

受Mac OS平臺(tái)本身的內(nèi)核限制，目前Mac OS平臺(tái)容器化方案極其不成熟，Mac OS平臺(tái)的環(huán)境隔離基本只有虛擬化這一條路可以走。

虛擬化類型的選擇

兩種類型的虛擬化方案如下圖所示，二者都基于Hypervisor實(shí)現(xiàn)，兩種：

• 虛擬化方案一

  • 無(wú)宿主OS直接基于Hypervisor虛擬化VM，資源利用率高，更適合云服務(wù)的虛擬化方案。
  • 對(duì)硬件兼容性有更高的要求。

• 虛擬化方案二

  • 在宿主機(jī)的OS上再基于Hypervisor虛擬化VM，更適合桌面用戶的虛擬化方案。
  • 由于有宿主機(jī)OS，硬件兼容性更好。

Mobile DevOps作為一款云產(chǎn)品對(duì)公提供服務(wù)，選擇方案1可以更有效提高資源利用率，至于硬件兼容性只要選擇生產(chǎn)方案選擇合適的硬件產(chǎn)品就能規(guī)避。

2 云架構(gòu)的虛擬化集群

要在云上提供公共的構(gòu)建服務(wù)，僅有虛擬化方案還是不夠的，還要有一套符合云架構(gòu)的虛擬化集群方案，來(lái)滿足Mobile DevOps對(duì)構(gòu)建集群的訴求：

• Mac硬件資源池化：集群中的各個(gè)Mac資源應(yīng)該是無(wú)狀態(tài)的，所有Mac硬件資源共同組成一個(gè)資源池，可以被集群統(tǒng)一分配和調(diào)度。
• 彈性擴(kuò)縮容：公共云業(yè)務(wù)規(guī)模存在一定的彈性，這就要求虛擬化集群也可以適應(yīng)業(yè)務(wù)場(chǎng)景，可以快速?gòu)椥詳U(kuò)縮容，跟上業(yè)務(wù)的增長(zhǎng)速度。
• 高可用：在個(gè)別Mac硬件設(shè)備損壞的情況下，集群可以快速自動(dòng)響應(yīng)將任務(wù)分配到新的虛機(jī)上，提高任務(wù)執(zhí)行成功率。

從單虛機(jī)到虛擬機(jī)集群，除了上述的Mac硬件資源池化，還要解決硬件資源集群化后新引入的分布式存儲(chǔ)和分布式網(wǎng)絡(luò)問(wèn)題，從虛擬化單機(jī)到虛擬化集群如下圖所示：

五 未來(lái)展望

目前公共云Mobile DevOps還在公測(cè)階段，還有很多方向需要努力：

• 增加構(gòu)建錯(cuò)誤智能分析、提示的能力。公共云用戶眾多的情況下，構(gòu)建錯(cuò)誤答疑是巨大的人力成本，后續(xù)需要基于關(guān)鍵字匹配，大數(shù)據(jù)分析，甚至是AI自動(dòng)錯(cuò)誤歸類等技術(shù)手段直接提示構(gòu)建錯(cuò)誤原因，減少人工答疑成本。
• 跟EMAS其他產(chǎn)品加強(qiáng)更多的聯(lián)動(dòng)，讓Mobile DevOps串聯(lián)完整的應(yīng)用研發(fā)生命周期。
• 跟社區(qū)保持更好的親和性。支持Github Actions、Azure Pipeline等其他平臺(tái)流水線遷移到Mobile DevOps；任務(wù)插件直接支持Github Actions 5000+開源插件，享受開源社區(qū)紅利。
• 加強(qiáng)被集成能力，讓Mobile DevOps移動(dòng)研發(fā)平臺(tái)可以更好的集成到客戶現(xiàn)有的研發(fā)流程中。
• 深度優(yōu)化應(yīng)用編譯構(gòu)建效率，減少應(yīng)用構(gòu)建時(shí)長(zhǎng)。終極目標(biāo)是要云上的應(yīng)用構(gòu)建時(shí)長(zhǎng)大幅短于本地構(gòu)建，讓開發(fā)者直觀感受到云上構(gòu)建的優(yōu)勢(shì)。

如果你對(duì)移動(dòng)構(gòu)建編譯技術(shù)、移動(dòng)研發(fā)技術(shù)、或者云原生的方向感興趣，并且你是一個(gè)喜歡技術(shù)挑戰(zhàn)的人，歡迎加入我們，我們的目標(biāo)是“做國(guó)際領(lǐng)先的移動(dòng)DevOps品牌”，職位直推郵箱 peng.zhao@alibaba-inc.com 。

引用文獻(xiàn)

[1]Azure DevOps：什么是DevOps？
https://azure.microsoft.com/zh-cn/overview/what-is-devops/
[2]百度統(tǒng)計(jì)流量研究院
https://tongji.baidu.com/research/app
[3]微軟發(fā)布Azure Pipelines，開源項(xiàng)目可無(wú)限制使用CI/CD
https://www.infoq.cn/article/2018/09/microsoft-azure-pipelines
[4]所有開源項(xiàng)目免費(fèi)使用，GitHub 內(nèi)置 CI/CD終于來(lái)了！
https://www.infoq.cn/article/D0mTaPbgpBHF3r-Cuvf3

原文鏈接：https://developer.aliyun.com/article/778856?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的如何建设移动 DevOps？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。