EMAS移動DevOps解決方案Mobile DevOps該怎么理解

這篇文章給大家介紹EMAS移動DevOps解決方案Mobile DevOps該怎么理解，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

一、Mobile DevOps 介紹

1. 什么是移動 DevOps

1）大家所熟知的DevOps

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

DevOps 是開發(fā) (Dev) 和運營 (Ops) 的復合詞，它將人、流程和技術(shù)結(jié)合起來，不斷地為客戶提供價值。  
DevOps 對團隊意味著什么？DevOps 使以前孤立的角色（開發(fā)、IT 運營、質(zhì)量工程和安全）可以協(xié)調(diào)和協(xié)作，以生產(chǎn)更好、更可靠的產(chǎn)品。

通過采用 DevOps 文化、做法和工具，團隊能夠更好地響應客戶需求，增強對所構(gòu)建應用程序的信心，更快地實現(xiàn)業(yè)務目標。

這個定義里有幾個關(guān)鍵信息總結(jié)一下：
① 人、流程、技術(shù)的結(jié)合
② DevOps使讓以前孤立的角色可以協(xié)調(diào)和協(xié)作
③ DevOps是一種理念，既要樹立文化，也要有自動化工具的支持
④ 目的是更快的生產(chǎn)更好、更可靠的產(chǎn)品

2）從DevOps到移動DevOps

對于DevOps大家平時討論比較多的其實是服務端DevOps，既然DevOps是一種優(yōu)秀的軟件交付理念，為什么不把DevOps也應用到移動端交付呢？這也就是我們今天要介紹的移動DevOps。
因為移動端和服務端場景的差異，移動DevOps跟服務端DevOps會有很大的不同。主要體現(xiàn)在以下幾個方面：

移動端應用自動化構(gòu)建更為復雜

? 構(gòu)建環(huán)境碎片化

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

? 移動端構(gòu)建涉及到證書托管等數(shù)據(jù)安全問題

? iOS構(gòu)建依賴的Mac設(shè)備為機房非標設(shè)備

Mac設(shè)備不屬于標準服務器無法部署在標準機房，通常需要自建Mac機房，對于可運維性和穩(wěn)定性也是一個挑戰(zhàn)。

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

移動端碎片化嚴重，應用交付兼容性是巨大的挑戰(zhàn)

不同于服務端部署環(huán)境的一致性，移動端應用運行環(huán)境碎片化非常嚴重，兼容性測試覆蓋難度遠大于服務端。移動端碎片化現(xiàn)象以Android系統(tǒng)尤為嚴重，主要體現(xiàn)在以下幾個方面：

? 手機機型碎片化

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

? 操作系統(tǒng)版本碎片化

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

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

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

移動端應用發(fā)布更新周期長

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

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

移動應用運行在海量移動端設(shè)備

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

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

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

2. 什么是Mobile DevOps

1）Mobile DevOps 是EMAS移動DevOps理念的具象化實現(xiàn)

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

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

研發(fā)域：Mobile DevOps
測試域：移動測試
發(fā)布域：Mobile DevOps
運維域：移動監(jiān)控，移動熱修復
運營域：移動推送，移動用戶反饋

2）Mobile DevOps的歷史

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

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

3）Mobile DevOps的現(xiàn)狀

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

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

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

公共云免費公測中

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

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

二、云原生的Mobile DevOps

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

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

1）面向中小微客戶提供普惠型Mobile DevOps服務

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

• 一次性投入：百萬級一性采購費用

• 持續(xù)投入：至少30 W/年服務器成本 + 20 W/年人力維護成本

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

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

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

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

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

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

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

1）安全性

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

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

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

2）高可用性

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

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

• 高標準的SLA，實時在線，永不宕機
  高標準SLA既是對客戶的承諾，也是對阿里云品牌的敬畏。

3）可擴展性

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

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

3. 我們的解法

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

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

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

• 通用構(gòu)建架構(gòu)，支持全平臺構(gòu)建能力

• 基于YAML自定義編排構(gòu)建流程

• 流水線可視化編排

• 流水線支持任務插件無限擴展

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

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

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

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

1. 技術(shù)預研

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

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

預研中發(fā)現(xiàn)一個有意思的現(xiàn)象，由于Github已經(jīng)是微軟子公司，兩個流水線產(chǎn)品不僅設(shè)計概念上相似，技術(shù)預研中發(fā)現(xiàn)二者的Mac虛擬化方案也是彼此技術(shù)共享的，甚至Mac虛擬化集群機房也是共享的。差異上Github Actions相對Azure Pipeline更為精簡優(yōu)雅一些，另外Github Actions依舊延續(xù)Github開源的風格，其流水線插件都是開源的，雖然上線僅1年多，已經(jīng)有5000+開源插件。從插件的角度這是一座金礦，如果這批插件都能直接在Mobile DevOps用起來，基本流水線的功能插件就跟開源社區(qū)對齊了?？紤]到未來支持這批開源插件的可能性，最終Mobile DevOps設(shè)計架構(gòu)上也更加擁抱開源社區(qū)的Github Actions。

2. 流水線的核心概念

• Trigger
  觸發(fā)器，主動觸發(fā)一次流水線執(zhí)行

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

• Job
  Job是被調(diào)度的最小單位，按Job被調(diào)度到的執(zhí)行環(huán)境不同可分為Agent（構(gòu)建集群）和Agentless（服務端）兩種Job；
  多個Job之間有可以無依賴并行運行，也可以有依賴順序執(zhí)行。多個Job之前的關(guān)系可以用一張DAG圖表示；
  每個Job可以包含1個或多個Step

• Step

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

• Task

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

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

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

1) Pipeline流程引擎

負責流水線的觸發(fā)、編排、狀態(tài)流轉(zhuǎn)執(zhí)行，以及流水線元數(shù)據(jù)信息維護。
流水線觸發(fā)器模塊
觸發(fā)器模塊負責觸發(fā)一條流水線的執(zhí)行，支持手動、定時器、事件（git event，webhook回調(diào)等）三種觸發(fā)方式。觸發(fā)器是流水線執(zhí)行的唯一入口，在這一層可以做調(diào)用方的校驗和檢查，同時支持傳入不同的觸發(fā)參數(shù)控制流水線的執(zhí)行和調(diào)度過程。
流水線編排模塊
流水線編排定義了一套用于描述一條流水線的DSL語言，基于這套DSL語言可以準確定義一條可被調(diào)度和執(zhí)行的流水線。
流水線執(zhí)行模塊
流水線執(zhí)行模塊主要確保流水線中所有Job都被按正確的依賴關(guān)系被并行或順序執(zhí)行，并實時更新流水線流轉(zhuǎn)實時狀態(tài)。

2）Job調(diào)度引擎

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

3）集成引擎

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

4）Channel通道服務

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

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

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

5）構(gòu)建集群

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

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

• Mac OS平臺下啟動虛擬機
  由于蘋果生態(tài)限制，iOS、Mac App構(gòu)建只能在Mac OS系統(tǒng)下進行，而當前Mac OS沒有成熟的類似Docker類容器方案可以使用，最終我們基于虛擬化方案來實現(xiàn)環(huán)境隔離。我們自建了基于云架構(gòu)的Mac虛擬化集群，將Mac物理資源徹底池化，可以快速完成集群彈性擴縮容，完全符合云原生的理念。每次構(gòu)建都從虛擬化集群中動態(tài)創(chuàng)建一臺虛機，構(gòu)建完立即銷毀。
  值得一提的是，Mac虛擬化集群是我們的技術(shù)優(yōu)勢，下面第五章我們將詳細Mobile DevOps在Mac虛擬化集群方向的實踐。

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

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

1. 虛擬化方案選型

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

虛擬化類型的選擇

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

虛擬化方案1：

• 無宿主OS直接基于Hypervisor虛擬化VM，資源利用率高，更適合云服務的虛擬化方案

• 對硬件兼容性有更高的要求

虛擬化方案2：

• 在宿主機的OS上再基于Hypervisor虛擬化VM，更適合桌面用戶的虛擬化方案

• 由于有宿主機OS，硬件兼容性更好

基于我們Mobile DevOps提供公共云服務的考慮，選擇方案1可以更有效的提高資源利用率，硬件兼容性只要選擇合適的硬件產(chǎn)品就能規(guī)避。
蘋果生態(tài)安全合規(guī)問題
蘋果生態(tài)封閉且有諸多安全合規(guī)限制，Mac平臺有如下法務合規(guī)限制：

1.MacOS必須運行Apple硬件之上  
2.在商業(yè)用途下，一個Apple硬件只允許運行一個macOS實例

從上述4種虛擬化方案對比，只有方案4是兼具蘋果生態(tài)合規(guī)性和兼容性的，而且方案4其實也是上節(jié)我們選擇的虛擬化方案1?；谏鲜鎏摂M化類型和蘋果生態(tài)安全合規(guī)性及兼容性考慮，我們最終選定上述方案4。

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

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

① Mac硬件資源池化 - 集群中的各個Mac資源應該是無狀態(tài)的，所有Mac硬件資源共同組成一個資源池，可以被集群統(tǒng)一分配和調(diào)度。
② 彈性擴縮容 - 公共云業(yè)務規(guī)模存在一定的彈性，這就要求虛擬化集群也可以適應業(yè)務場景，可以快速彈性擴縮容，跟上業(yè)務的增長速度。
③ 高可用 - 在個別Mac硬件設(shè)備損壞的情況下，集群可以快速自動響應將任務分配到新的虛機上，提高任務執(zhí)行成功率。
從單虛機到虛擬機集群，除了上述的Mac硬件資源池化，還要解決硬件資源集群化后新引入的分布式存儲和分布式網(wǎng)絡(luò)問題，從虛擬化單機到虛擬化集群如下圖所示：

五、未來展望

未來展望

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

• 增加構(gòu)建錯誤智能分析、提示的能力。公共云用戶眾多的情況下，構(gòu)建錯誤答疑是巨大的人力成本，后續(xù)需要基于關(guān)鍵字匹配，大數(shù)據(jù)分析，甚至是AI自動錯誤歸類等技術(shù)手段直接提示構(gòu)建錯誤原因，減少人工答疑成本

• 跟EMAS其他產(chǎn)品加強更多的聯(lián)動，讓Mobile DevOps串聯(lián)完整的應用研發(fā)生命周期

• 跟社區(qū)保持更好的親和性。支持Github Actions、Azure Pipeline等其他平臺流水線遷移到Mobile DevOps；任務插件直接支持Github Actions 5000+開源插件，享受開源社區(qū)紅利

• 加強被集成能力，讓Mobile DevOps移動研發(fā)平臺可以更好的集成到客戶現(xiàn)有的研發(fā)流程中

• 深度優(yōu)化應用編譯構(gòu)建效率，減少應用構(gòu)建時長。終極目標是要云上的應用構(gòu)建時長大幅短于本地構(gòu)建，讓開發(fā)者直觀感受到云上構(gòu)建的優(yōu)勢

關(guān)于EMAS移動DevOps解決方案Mobile DevOps該怎么理解就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。