EMAS 移動 DevOps 解決方案 —— Mobile DevOps

簡介： DevOps這一優秀的軟件交付理念在服務端已經有不少相關的實踐，那麼是否也能夠應用到移動端進行交付呢？基於移動端和服務端場景的差別，移動DevOps跟服務端DevOps又有哪些不一樣和挑戰？本文分享阿里云云原生應用研發平臺EMAS在建設雲原生Mobile DevOps過程當中的思考、遇到的挑戰以及解法，解密其設計架構和技術細節。

阿里雲 雲原生應用研發平臺EMAS 彭釗（州牧）

1、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應用生命週期及各階段能力要求以下：

1. 什麼是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開始正式對外免費公測，目前已服務以及衆多中小微客戶，以及阿里集團內部專屬釘釘、政務釘釘、唱鴨等客戶。

2、雲原生的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「煙囪式」的一個個獨立開源系統，研發協同效率上也有明顯優點。

1. 公共雲 Mobile DevOps面臨的挑戰

---

相比專有云內網部署、內部員工使用的場景，公共雲形態下的Mobile DevOps會面臨更多的技術挑戰，主要體如今一下幾個方面：

1）安全性

• 租戶隔離
公共雲面臨的第一個問題就是租戶隔離，不一樣客戶既要同時使用共享資源，又不能互相看到對方的數據。對於構建這種場景，除了不一樣客戶的構建任務可能會互相影響，構建環境還涉及到用戶的代碼、證書等私密信息，必需要有完善的方案保證用戶構建環境的隔離
• 代碼、證書、祕鑰等私密數據安全
有構建就必然涉及用戶代碼、證書、祕鑰，這些數據都是極其隱私的數據，公共雲存儲、傳輸、使用任何環節出問題均可能會致使用戶重大損失。
• 外部攻擊
公共雲因爲暴露在公網任何人均可以使用，還面臨惡意黑客攻擊的風險，尤爲構建場景涉及大量的自定義執行命令，必需要有完善的機制防止黑客執行惡意自定義命令在構建環境內留下後門。

2）高可用性

• 必須支持彈性擴縮容
公共雲業務規模增加時，須要業務要能快速擴縮容適應業務增加，不然就會致使服務異常。這就要求雲產品在技術實現上符合分佈式的架構，尤爲是構建集羣要支持無狀態快速擴容。
• 構建環境的穩定性
構建環境要穩定，避免因攻擊或異常使用致使的構建環境被破壞的狀況，好比環境變量、構建工具鏈等。
• 高標準的SLA，實時在線，永不宕機
高標準SLA既是對客戶的承諾，也是對阿里雲品牌的敬畏。

3）可擴展性

• 應用架構多樣化致使的構建流程差別大
專有云客戶數量有限，並且有完善的KA客戶技術支持服務，因此應用的差別有限且有專人支持接入。但公共雲環境下客戶衆多，應用架構多樣性對系統的通用性、擴展性提出了更高的要求。
• 研發流程多樣化
公共雲不一樣客戶研發團隊規模、研發文化、研發流程都有差別，也對Mobile DevOps研發流程擴展性提出了更高的要求。

1. 咱們的解法

---

針對以上公共雲Mobile DevOps面臨的挑戰，咱們從如下兩個方面經過技術手段去解決：

1）基於流水線的通用構建架構

流水線架構將構建作到通用化，基於流水線自定義編排構建流程，基於任務插件擴展流水線業務能力，很好的解決了上述的可擴展性問題。此架構具備如下特點：
• 通用構建架構，支持全平臺構建能力
• 基於YAML自定義編排構建流程
• 流水線可視化編排
• 流水線支持任務插件無限擴展

2）基於容器化/虛擬化構建集羣

使用容器化（Linux）/虛擬化（Mac Os）方案能夠完全解決各類因資源共享帶來的安全性和穩定性問題，每一個構建任務起全新的容器/虛擬機運行，構建任務完成後容器/虛擬機當即被銷燬，不只能夠有效隔離任務間運行環境，構建環境也「經常使用常新」，能夠有效避免構建環境被破壞的問題；另外搭建穩定的無狀態 容器化/虛擬化 構建集羣，能夠保證構建服務的高可用性。
下面第3、四章節，咱們會對這兩個點分別展開詳述，解密其設計架構和技術細節。

3、基於流水線的通用構建架構

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。

1. 流水線的核心概念

---

• 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. 流水線的技術架構

---

流水線由如下幾個核心系統組成：

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虛擬化集羣方向的實踐。

4、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。

1. 雲架構的虛擬化集羣

---

要在雲上提供公共的構建服務，僅有虛擬化方案仍是不夠的，還要有一套符合雲架構的虛擬化集羣方案，來知足Mobile DevOps對構建集羣的訴求：
① Mac硬件資源池化 - 集羣中的各個Mac資源應該是無狀態的，全部Mac硬件資源共同組成一個資源池，能夠被集羣統一分配和調度。
② 彈性擴縮容 - 公共雲業務規模存在必定的彈性，這就要求虛擬化集羣也能夠適應業務場景，能夠快速彈性擴縮容，跟上業務的增加速度。
③ 高可用 - 在個別Mac硬件設備損壞的狀況下，集羣能夠快速自動響應將任務分配到新的虛機上，提升任務執行成功率。
從單虛機到虛擬機集羣，除了上述的Mac硬件資源池化，還要解決硬件資源集羣化後新引入的分佈式存儲和分佈式網絡問題，從虛擬化單機到虛擬化集羣以下圖所示：

5、將來展望

將來展望

目前公共雲Mobile DevOps還在公測階段，還有不少方向須要努力：
• 增長構建錯誤智能分析、提示的能力。公共雲用戶衆多的狀況下，構建錯誤答疑是巨大的人力成本，後續須要基於關鍵字匹配，大數據分析，甚至是AI自動錯誤歸類等技術手段直接提示構建錯誤緣由，減小人工答疑成本
• 跟EMAS其餘產品增強更多的聯動，讓Mobile DevOps串聯完整的應用研發生命週期
• 跟社區保持更好的親和性。支持Github Actions、Azure Pipeline等其餘平臺流水線遷移到Mobile DevOps；任務插件直接支持Github Actions 5000+開源插件，享受開源社區紅利
• 增強被集成能力，讓Mobile DevOps移動研發平臺能夠更好的集成到客戶現有的研發流程中
• 深度優化應用編譯構建效率，減小應用構建時長。終極目標是要雲上的應用構建時長大幅短於本地構建，讓開發者直觀感覺到雲上構建的優點

原文連接本文爲阿里雲原創內容，未經容許不得轉載。