本文整理於螞蟻金服無線工程師刺胃在 2019 安卓巴士開發者大會現場的分享《螞蟻金服 mPaaS 模組化開發與架構重構深度解析》，通過“模組化開發架構設計”作為切入口，聚焦 mPaaS 如何深度應用與實踐模組化開發架構，以及在架構重構中遇到了哪些挑戰和具體解決思路。
內容概要
主要分為以下三個部分：
- 支付寶在移動端的架構演進與思考
- mPaaS 模組化架構及能力
- 基於 mPaaS 架構的重構思考
支付寶在移動端的架構演進與思考
支付寶現狀
根據 2019 年移動網際網路最新的資料包告，目前支付寶全球總使用者數已超過 10 億人，月活使用者數超過 6.5 億，成為國內第二大 App。
在研發上面，支付寶的客戶端研發人員超過 300+，整體工程數同樣也是超過 300+，總體程式碼超過 200 萬行，提供的服務超過 200+，並且整體的閃退率維持萬分之五以下，那麼支付寶是如何保證在如此龐大的研發規模下，保證服務的告訴迭代，以及應用的整體穩定性的呢？
三個階段
支付寶做到今天，主要分為三個階段：
1. 獨木舟階段
支付寶剛開始推出的時候，和很多簡單的應用一樣，都是一個單體應用，除了一些簡單的公共元件被作為 lib 模組，其他大部分業務程式碼全部寫到一起。這種單工程的輕量結構，對於當時的支付寶來說，還算是可以滿足需求，但是隨著支付寶業務的迅速成長，問題開始暴露出來了，由於單工程，所有工程師程式碼都要合到一起，並行開發變得異常艱難，同時，由於釋出時間固定，各團隊匆忙合併程式碼，很可能出現程式碼覆蓋、汙染的情況，從而導致穩定性無法保證。這種開發模式，我們稱之為「序列開發模式」。
2. 戰列艦階段
為了解決獨木舟階段我們存在的問題，在 13 年底，支付寶進行了一次徹底的重構，基於 OSGi 模組化思想，推出了 Quinox 容器化框架。基於這套框架，支付寶完成了從單體應用到平臺型應用的轉變，從單工程「序列開發模式」變為了多工程「並行開發模式」。各工程之間只關注介面，不用在意實現細節，頁面間路由只需一個 id。程式碼完全隔離，開發、發版效率有了明顯提升。因為基於框架提供的 pipeline 機制，業務治理變得非常方便，使得整體應用的啟動效能有了明顯的提升。
3. 航空母艦階段
時間來到了 15 年，在解決了協作效率、啟動效能等問題後，隨著移動支付的普及，業務的井噴，使用者對應用體驗要求的提高，彈性動態、高可用這兩個變為了這個階段的重點。為了解決這些問題，支付寶引入了 Nebula 容器、小程式、多維釋出以及全鏈路的監控等元件，來保障轉型成為超級 App。
架構升級技術挑戰及解決方向
通過剛才我們簡要的回溯支付寶近些年的架構升級歷程，我們可以總結出，重構升級成超級 App，需要解決的幾大塊技術點：
- 協同開發，業務解耦
- 啟動效能調優，業務治理
- 複雜業務動態化，多維釋出
- 保證高可用，資料全鏈路採集，多維度修復
mPaaS 模組化架構及能力
帶著上面提出的四個技術問題，我們來先了解下 mPaaS 的整體架構圖
整個客戶端架構總共分成四層：框架層、元件層、服務層、業務層。
- 框架層：最關鍵的部分，整個模組化的基礎。提供微應用、微服務、pipeline、切面、監控等服務。整體模組化協同開發，都是基於框架層提供的能力，來達到「並行開發」的目的。
- 元件層：這一層提供的是客戶端通用能力，如安全、網路、多媒體、儲存這些，這些元件都是支付寶多年沉澱下來的經典元件，它們提供穩定的介面給上層使用者，作為客戶端的基石，它們至關重要。
- 服務層：本層就是和支付寶相關的一些核心服務能力，我們將他們抽取出來，進行服務化，服務 App 本身，也服務各個生態業務。
- 業務層：業務方和第三方服務提供者，只需專注於業務邏輯與介面的實現，呼叫整體框架提供的各種能力，最後通過整體應用的動態化能力進行多維釋出。
通過 Quinox 框架、微服務、微應用，即可實現上面的架構分層，接下來我們將逐一介紹。
Quinox 框架
Quinox 客戶端框架是類 OSGi（ like-as）框架的實現。Quinox 一詞來源於著名的 OSGi 框架的實現 Equinox。
基於 mPaaS 的 App 研發，就像積木搭建（Bundle）一樣輕鬆，天生具有以下優勢：
- 靈活性：模組/元件可插拔，不影響編譯
- 獨立性：模組可由團隊或個人獨立維護
- 複用性：模組可被任意宿主程式所引用
- 隔離性：介面和實現分離，微應用路由跳轉
微服務
mPaaS 框架提供微服務功能，該服務類似於 Android 原生的 Service，直接通過框架的方法，即可獲得服務的實現。這種設計模式本身核心是控制反轉，依賴注入的這種理念，減少各模組間的依賴，初始化等複雜的工作，完成解耦。
作為使用者方，無需瞭解實現細節，只需要提供引數，呼叫服務提供的介面即可獲得服務。
作為開發者，只需要將服務介面註冊到框架上，框架在初始化後，會自動去生成服務，控制服務的生命週期。
微應用
mPaaS 框架提供微應用功能，微應用我們可以理解為 mPaaS 的路由。
作為使用方，通過唯一的 appId，進行不同微應用之間的呼叫，使用者並不需要引用對方的 activity，也無需關注對方內部的跳轉邏輯。
作為開發者，只需要將 appId 註冊到框架上，當有業務調到該 ID 後，後續的操作完全有開發者掌握，業務之間完全隔離解耦。
微應用的概念不僅適用於原生頁面，同樣也適用於H5和小程式。註冊為H5或者小程式型別的應用 ID，框架會自動將啟動過程delegate給H5或者小程式容器，而使用者完全不必關心應用 ID 對應的應用型別。
綜上所述，微應用和微服務可以使各個業務之間的耦合降到最低，大家都無需關注其他團隊的實現，程式碼之間無侵染，這樣整體的協作研發效率也就隨之提升上來了。
Pipeline 機制及啟動優化
上面的內容主要是講如何高效的進行協同開發，接下來該第二個技術點，也就是 mPaaS 是如何對框架的效能進行治理的。對於效能優化，mPaaS 框架主要從業務和技術兩個方面進行處理：
技術優化：
- mPaaS 通過黑科技，將啟動時的 JIT 關閉，從而有效降低因即時編譯導致的效能問題
- 通過關閉啟動時的 GC，從而將啟動速度提升到最快，當啟動完成後，在進行一次較大的 GC。
- 提供各種切面及監控能力，全方面監控啟動異常
業務優化：
- mPaaS 框架提供統一的啟動流程、執行緒池、併發工具類等，可以有效的使業務規範化
- 並且，mPaaS 提供 pipeline 機制，可以根據業務優先順序進行初始化調優，從而達到啟動優化的目的。
動態化
解決了上面兩個技術點，mPaaS 框架就已經具備成為戰列艦的能力了，接下來，我們看下如何更近一步，提供航空母艦的能力。
作為超級 App 的核心能力，就是如何構建生態。”快速起飛、降落，承載大量、不同的艦載機“是其要解決的核心問題。解決這個問題的關鍵就是框架的 Hybrid 能力，mPaaS 上面，採用了支付寶多年積累下來的 Hybrid 經驗，使用 Nebula 作為 H5 容器，同時承載 H5 離線包以及小程式。
H5 容器及離線包的特點：
- 全面相容主流 H5 框架，遷移成本低
- 使用離線包技術，體驗接近原生，網路請求走原生，高效安全。
- 提供統一 UC 核心，效能及穩定性有保障
- 離線包差量更新，節省流量
- 提供容錯機制，下載失敗後走線上 fallback
- 實時觸達客戶，通過推拉結合，下發離線包
H5 離線包作為動態化方案，有點多多，但是，其有一點不足就是無法管控質量，寬泛的前端規範讓服務管控變得異常困難，如果所有服務都是我們內部的業務還好說，如果開放給第三方，就需要有完整的規範來約束。這時，我們就要引入小程式來規範化服務，提供給第三方。
小程式特點：
- 統一的小程式架構，可在任意基於 mPaaS 架構開發的應用上進行投放
- 強大的 Web 渲染引擎
- 提供豐富元件，快速實現業務
- 整合離線包技術，可以複用 H5 外掛
- 完善的生命週期管理
當我們解決完動態化的技術點後，應用將會有以下四點優化：
- 包尺寸有效減少，節省流量和儲存。
- 服務不再受發版所限制，快速釋出，快速迭代。
- 業務開發效率更加優秀，一次開發，多端執行。
- 應用升級為平臺，提供優質服務並按需載入。
多維釋出
作為一套完整的動態化方案，光有容器其實是不夠的，我們還需要有多維觸達使用者的手段，將各種服務釋出給使用者，接下來，我們就聊聊 mPaaS 多維釋出都具備哪些能力。
通過 mPaaS 釋出平臺，我們可以輕鬆地將我們的 App 新版本、H5 離線包、小程式包、熱修復包以及開關配置進行下發。
同時釋出平臺提供了正式釋出和灰度釋出，通過灰度釋出，我們可以有效的驗證待發布的內容，檢查是否有潛在的風險，若灰度釋出時出了問題，可進行及時回滾，減少覆蓋面，有效的降低了正式釋出的風險。
另外發布平臺還提供不同的緯度，包括白名單、機型、城市、系統版本等，這些緯度可以使釋出可以更具有針對性。
運維體系
上面解決了協同開發、效能優化、動態化等技術點，最後一個技術點就是如何保障高可用，確保應用的穩定性。
mPaaS 提供一套完整的運維體系來保證線上 App 的穩定。
1. 開發測試
通過介面實現分離，各模組充分進行單元測試，整合之後進行聯調測試，聯調測試之後，交給 mPaaS 雲測平臺，進行穩定性測試以及功能測試。充分的測試，可以將 80% 問題發現出來，並在發版前及時修復。
2. 灰度釋出
結合上面提供的灰度能力，進行灰度釋出。對於客戶端來說，有些問題，模擬測試環境是很難測出來的，那麼這個時候，真實的線上灰度環境就是預防風險的重要手段之一了。通過灰度釋出，逐步放量，不斷擴大灰度範圍，直到閃退率、卡死率等指標符合釋出標準後，再進行全量的釋出。
3. 實時監控
全方面監控各種緯度的 App 資料，如閃退、卡死、卡頓、電量、流量等。指定一定的異常規則，有問題及時進行報警。這些診斷資料是會週期性的進行上報，不過當有些特定機型或者特定使用者出現無法復現的問題時，我們還可以通過撈日誌的方式，將指定裝置的開發日誌上報給服務端，進行分析排查。
4. 動態修復
最後，當問題發現並解決後，可以通過上面提到的釋出平臺，將修復後的配置、離線包、小程式、熱修復 patch 包等，下發到對應裝置上，進行容災修復。
基於 mPaaS 架構的重構思考
上面介紹完了 mPaaS 的能力，接下來我們聊下基於 mPaaS 的重構思考，本章會從五個維度來考慮重構。
架構重構
當我們決定架構重構後，一般會有兩種選擇進行重構，一種是全部推倒重來，還有一種是融合遷移。
這兩種方案，我們可以比喻為一架比較老的飛機，已經不足以滿足現在的飛行任務，第一種方案就是將飛機飛回機場，重新拆掉，結合新的設計架構從新組裝。第二種方案是在執行飛行任務的過程中，我們逐步去替換髮動機、替換不滿足架構的地方，直至飛機滿足最新的任務需求。
無論我們採取哪種方式進行重構，首要的工作就是梳理現有業務，將整體結構進行模組化拆分，同時對我們整體的架構進行合理分層。
基於第一種方案，我們首先需要基於 mPaaS 架構搭建一個全新的框架，同時，由於我們是推倒重建，所以我們需要儘量減少在此階段提的新需求。等當整體架構完成後，再增加新需求。框架搭好後，我們需要將各項業務也進行重構，並逐個插到 mPaaS 容器化框架上來。最後當所有業務全部重構完成後，我們再進行全量的迴歸測試。
這種方式的優勢和劣勢都很明顯，優勢就是完全基於新的架構來實現，拋棄原有的包袱以及不合理的地方，但是劣勢就是，完全重構所需要的工作量是巨大的，同時有些企業可能無法接受如此長的時間不能或只能少量的更新需求。
基於第二種方案，第一件事情就是將 mPaaS 架構接入進我們原有的工程中，然後再對原有框架進行融合適配：比如開發一個相容新老框架跳轉的路由，相容新老 H5 容器的原生外掛等等。相容工作完成後，我們就要對原有業務進行改造升級，我們可以將業務逐漸的拆分出來，跑在新的框架上。每完成一點，我們都可以進行一次迭代釋出，測試的壓力也會比較小。
這種方式的好處就是整個重構過程是一個持續性的過程，每一步都可以有產物輸出，小步快跑，持續迭代。但是劣勢就是，可能最終的版本，會有融合的痕跡存在，一些歷史包袱也可能無法很好地甩掉。
當然，這兩種重構方式沒有誰好誰壞，根據業務自身的需求來選擇自己合適的方式才是最好的。
能力重構
上面我們介紹了架構重構以及相應的方式，接下來我們來聊聊能力重構。
所謂能力重構，就是我們希望通過整合整個架構，在基礎層面，將通用的元件下沉，避免重複創造輪子，同時標準化服務介面，為更多的上層業務提供優質、穩定且標準的服務。
那麼我們就需要從兩個方面來處理這個事情。
基礎元件
我們在開發過程中可能會存在這樣一個問題，就是兩個團隊協作開發，可能大家有自己的一套儲存邏輯、網路請求、工具庫或是其他冗餘重複的程式碼，這時候我們就需要將重複的部分，進行合併，沉澱，通過公共 bundle 的形式，對其他團隊提供能力。
當然，mPaaS 框架自帶了非常優秀的網路、安全、儲存、多媒體等 App 開發過程中都需要使用的元件，供開發者直接呼叫。
核心能力服務化
元件沉澱後，對於一些核心的業務能力，我們需要將這部分能力進行服務化，抽象出標準的服務介面，供其他團隊或是第三方生態呼叫。比如說支付寶的支付服務、芝麻信用服務等，都是依託於服務化，最終良好的為其他業務提供服務的。
業務重構
在我們完成框架重構和能力重構之後，整體的骨架和能力就已經具備了，剩下的就是基於這套框架，將我們的業務介面進行重構，在這裡，我們建議大家參考以下原則：
核心業務微應用化
針對一些非常核心的業務邏輯，比如支付報的支付，以及一些對效能要求比較高的業務，比如首頁，亦或是一些特殊互動的頁面。通常我們是希望通過使用原生頁面，並將頁面打成微應用的形式進行重構優化。因為這些頁面，通常不會有大改，所以對動態化能力要求不是很嚴格，同時原生又能滿足這些頁面多種多樣定製化的需求。
複雜業務 H5 化
對一些複雜的二級業務，可能業務本身會頻繁的進行迭代，那麼對於原生 native 將會是災難般的開發體驗，這時候，我們需將這部分業務剝離出來，通過前端技術將業務打成 H5 離線包，再通過釋出服務將離線包釋出到應用上。這樣，就滿足了我們業務複雜多變的場景。
三方生態小程式化
我們不僅自身提供各種各樣的服務，也需要引入第三方服務來服務更多的人群，傳統的 H5 頁面由於過於寬泛的前端標準，加上有一定的技術門檻，這裡就不如規範、簡單的小程式了。所以，一般第三方的服務，我們希望將其小程式化。
釋出重構
當一切開發工作都 OK 之後，我們是否能夠說，本次的重構就完成了呢？答案是否定的。重構，不僅僅是針對程式碼層面的重構，基於新的架構之後，整體的釋出、運維理念也需要進行重構。
如上圖所示，我們重新定義了研發模式與釋出流程，Native 應用、H5 業務、小程式，都可以有自己的釋出流程，無需阻塞等待其他團隊。各業務團隊進行完全拆分，每個業務獨立演進，獨立釋出。
在釋出過程中，要遵守以下流程：
- 指標線性，定義每次釋出的業務和效能指標
- 智慧灰度，內部灰度、外部灰度、指定灰度
- 實時監控，修復迴圈
- 線上運維修復手段技術兜底
運維重構
在上面我們也講到了運維理念的重構，在這裡，我們要介紹下 mPaaS 架構是如何保障線上應用的質量的呢？
我們引入了多維度運維的概念，如圖所示
最上面一層是開關。通過開關，將一些我們新開發的，或者是將穩定性不太確定的程式碼包起來。這樣，如果真的線上發生故障，我們可以及時通過伺服器推送開關，將故障程式碼關閉，這種方式是推拉結合的，即時到達率 100%。
第二層緯度就是通過 H5 離線包。如果某些故障是發生在離線包內，那麼我們可以定位到問題，直接再傳送新的版本即可，這種方式也是推拉結合，但由於離線包需要下發，所以不如開關那麼即時，不過在 1 分鐘之內也能覆蓋 99% 以上的使用者
第三個緯度就是小程式。如果故障發生在小程式上，那麼同離線包，我們只需要重新修改小程式，重新發布，不過這裡可能會涉及到稽核問題，效率比離線包要略慢一點。
在下一個緯度第四個緯度是我們的熱修復。不到萬不得已一般不會進行熱修復，這是一個原生 Native 兜底的手段，通過熱修復補丁包的下發，我們來彌補我們的缺陷，一般成功率會在 95% 以上。
最後如果以上手段都無法修復，那麼我們會啟動緊急發版流程，釋出新的版本來覆蓋故障。
重構案例
12306
2017 年底通過 mPaaS 進行了系統的重構，使用了 mPaaS 框架以及多項元件及服務，解決了 12306 移動端開發多年的痛點。比如 12306 的彈性動態化，之前會有在啟動頁面強制更新下載的情況，使用者體驗不太好，通過 mPaaS 優化後，進行了無感知更新，使用者體驗提升了一個臺階；還有就是 12306 使用了 mPaaS 的閘道器，其服務安全性得到了質的提升，也使得正常使用者的整體購買流程得到了好的體驗優化。
作為開發角度，客戶表示當年是移動端開發、運營最輕鬆的一年。作為使用者角度，多數使用者也表示使用體驗改善了很多。
廣發銀行
廣發銀行之前採用其他移動端研發平臺，效能一直是瓶頸，尤其啟動時間，在部分低端機型上體驗不太友好，使用 mPaaS 重構後，平均啟動效能有了質的提升。
廣發銀行是“發現精彩”與“手機銀行”兩款 App 先後完成上線，兩個 App 均使用 mPaaS 框架進行重構。其內部有多個模組的功能是重疊的，通過 mPaaS 模組化架構拆除可複用的微服務、微應用以及離線包，使得開發後的手機銀行客戶端在研發工時上節省了大齡的研發工時。
針對移動端架構設計和重構實踐，相信大家也有自己相應的思考，以及實際開發過程中遇到的相關問題和痛點，歡迎大家新增釘釘群“23124039”和我們互動交流。
目前“訊息推送”、“熱修復”、“移動分析”三款元件也已面向個人開發者正式放開體驗資格，誠邀你的體驗反饋，點選“閱讀原文”立即跳轉開通地址。
| 移動開發平臺 mPaaS 三款元件重磅上線螞蟻金服開放平臺：
- 公測期，歡迎體驗試用。支付寶掃碼或登入開放平臺
往期閱讀
《螞蟻金服 mPaaS 服務端核心元件體系概述：移動 API 閘道器 MGS》
《螞蟻金服 mPaaS 服務端核心元件：億級併發下的移動端到端網路接入架構解析》
《mPaaS 服務端核心元件：訊息推送 MPS 架構及流程設計》
關注我們公眾號，獲得第一手 mPaaS 技術實踐乾貨
釘釘群：通過釘釘搜尋群號“23124039”
期待你的加入～