螞蟻金服 mPaaS 模塊化開發與架構重構深度解析

本文整理於螞蟻金服無線工程師刺胃在 2019 安卓巴士開發者大會現場的分享《螞蟻金服 mPaaS 模塊化開發與架構重構深度解析》，經過「模塊化開發架構設計」做爲切入口，聚焦 mPaaS 如何深度應用與實踐模塊化開發架構，以及在架構重構中遇到了哪些挑戰和具體解決思路。

內容概要

主要分爲如下三個部分：

1. 支付寶在移動端的架構演進與思考
2. mPaaS 模塊化架構及能力
3. 基於 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 業務、小程序，均可以有本身的發佈流程，無需阻塞等待其餘團隊。各業務團隊進行徹底拆分，每一個業務獨立演進，獨立發佈。

在發佈過程當中，要遵照如下流程：

1. 指標線性，定義每次發佈的業務和性能指標
2. 智能灰度，內部灰度、外部灰度、指定灰度
3. 實時監控，修復循環
4. 線上運維修復手段技術兜底

運維重構

在上面咱們也講到了運維理念的重構，在這裏，咱們要介紹下 mPaaS 架構是如何保障線上應用的質量的呢？
咱們引入了多維度運維的概念，如圖所示

最上面一層是開關。經過開關，將一些咱們新開發的，或者是將穩定性不太肯定的代碼包起來。這樣，若是真的線上發生故障，咱們能夠及時經過服務器推送開關，將故障代碼關閉，這種方式是推拉結合的，即時到達率 100%。
第二層緯度就是經過 H5 離線包。若是某些故障是發生在離線包內，那麼咱們能夠定位到問題，直接再發送新的版本便可，這種方式也是推拉結合，但因爲離線包須要下發，因此不如開關那麼即時，不過在 1 分鐘以內也能覆蓋 99% 以上的用戶
第三個緯度就是小程序。若是故障發生在小程序上，那麼同離線包，咱們只須要從新修改小程序，從新發布，不過這裏可能會涉及到審覈問題，效率比離線包要略慢一點。
在下一個緯度第四個緯度是咱們的熱修復。不到萬不得已通常不會進行熱修復，這是一個原生 Native 兜底的手段，經過熱修復補丁包的下發，咱們來彌補咱們的缺陷，通常成功率會在 95% 以上。

最後若是以上手段都沒法修復，那麼咱們會啓動緊急發版流程，發佈新的版原本覆蓋故障。

重構案例

12306

2017 年末經過 mPaaS 進行了系統的重構，使用了 mPaaS 框架以及多項組件及服務，解決了 12306 移動端開發多年的痛點。好比 12306 的彈性動態化，以前會有在啓動頁面強制更新下載的狀況，用戶體驗不太好，經過 mPaaS 優化後，進行了無感知更新，用戶體驗提高了一個臺階；還有就是 12306 使用了 mPaaS 的網關，其服務安全性獲得了質的提高，也使得正經常使用戶的總體購買流程獲得了好的體驗優化。
做爲開發角度，客戶表示當年是移動端開發、運營最輕鬆的一年。做爲使用者角度，多數用戶也表示使用體驗改善了不少。

廣發銀行

廣發銀行以前採用其餘移動端研發平臺，性能一直是瓶頸，尤爲啓動時間，在部分低端機型上體驗不太友好，使用 mPaaS 重構後，平均啓動性能有了質的提高。
廣發銀行是「發現精彩」與「手機銀行」兩款 App 前後完成上線，兩個 App 均使用 mPaaS 框架進行重構。其內部有多個模塊的功能是重疊的，經過 mPaaS 模塊化架構拆除可複用的微服務、微應用以及離線包，使得開發後的手機銀行客戶端在研發工時上節省了大齡的研發工時。

針對移動端架構設計和重構實踐，相信你們也有本身相應的思考，以及實際開發過程當中遇到的相關問題和痛點，歡迎你們添加釘釘羣「23124039」和咱們互動交流。
目前「消息推送」、「熱修復」、「移動分析」三款組件也已面向我的開發者正式放開體驗資格，誠邀你的體驗反饋，點擊「閱讀原文」當即跳轉開通地址。

| 移動開發平臺 mPaaS 三款組件重磅上線螞蟻金服開放平臺：

• 公測期，歡迎體驗試用。支付寶掃碼或登陸開放平臺

往期閱讀

《開篇 | 螞蟻金服 mPaaS 服務端核心組件體系概述》

《螞蟻金服 mPaaS 服務端核心組件體系概述：移動 API 網關 MGS》

《螞蟻金服 mPaaS 服務端核心組件：億級併發下的移動端到端網絡接入架構解析》

《mPaaS 服務端核心組件：消息推送 MPS 架構及流程設計》

《mPaaS 核心組件：支付寶如何爲移動端產品構建輿情分析體系？》

《mPaaS 服務端核心組件：移動分析服務 MAS 架構解析》

關注咱們公衆號，得到第一手 mPaaS 技術實踐乾貨

釘釘羣：經過釘釘搜索羣號「23124039」

期待你的加入～