阿裡雲 雲原生應用研發平台EMAS 彭钊（州牧）
一、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%，可見機型碎片化之嚴重
• 作業系統版本碎片化
作業系統的差異對應用運作的影響更為直接，系統大版本更新導緻應用不相容的情況屢見不鮮，每次作業系統大版本釋出都是對應用相容性的一次考驗；在考慮相容新系統的同時，還不能放棄老系統的使用者。
下圖是2020.10月份最新的百度流量研究院的Android版本分布資料，可以看到已經釋出一年多的Android 10.0，市場占用率還不足50%，2年以前的作業系統依然占主流
由于端裝置的碎片化問題，就需要移動DevOps具備移動測試能力，自動化完成大量的真機相容性測試。
移動端應用釋出更新周期長
應用新版本可能釋出2周更新比例都不會超過50%，不像服務端可以在很短的時間内完成所有伺服器的軟體釋出。釋出周期長意味着犯錯成本更高，一個有Bug的版本發出去，可能需要很長的時間才能通過更新更新消化完。
這就需要移動DevOps一方面具備完善的灰階釋出機制，避免将有問題的應用一次性釋出到使用者側；另一方面一旦有Bug的版本已經發出，需要移動DevOps具備熱修複能力，可以通過增量更新檔包的釋出方式更輕量、快速的修複Bug。
移動應用運作在海量移動端裝置
不像服務端服務運作在特定的叢集内，可以統一管控和運維，移動應用的運作環境在使用者的手機上，而且對于手淘這類超級App來講是億級海量裝置。
這就需要移動監控類産品通過大資料技術來實作移動端運維監控，甚至需要遠端日志功能來拉取指定裝置上的錯誤日志來定位排查錯誤。
基于以上幾點，并參考DevOps對軟體傳遞生命周期的定義，總結移動DevOps應用生命周期及各階段能力要求如下：
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的發展史其實就是阿裡集團移動研發技術發展史，是阿裡巴巴近十年移動技術、工程研發理念沉澱。
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. 流水線的核心概念
• 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 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實作，兩個方案對比如下：
虛拟化方案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移動研發平台可以更好的內建到客戶現有的研發流程中
• 深度優化應用編譯建構效率，減少應用建構時長。終極目标是要雲上的應用建構時長大幅短于本地建構，讓開發者直覺感受到雲上建構的優勢
如果你對移動建構編譯技術、移動研發技術、或者雲原生的方向感興趣，并且你是一個喜歡技術挑戰的人，歡迎加入我們，我們的目标是“做國際領先的移動DevOps品牌”。➡️
點選這裡，檢視崗位資訊。
引用文獻：
[1]
Azure DevOps：什麼是DevOps？[2]
百度統計流量研究院[3]
微軟釋出Azure Pipelines，開源項目可無限制使用CI/CD[4]
所有開源項目免費使用，GitHub 内置 CI/CD終于來了！