以下文章來源於mPaaS ，作者重岳
mPaaS
mPaaS (https://aliyun.com/product/mpaas) 源於螞蟻金服金融科技，致力於提供高效、靈活、穩定的移動研發、管理平台。
| 導語
本文基於重岳在 2019 年 DevOps 國際峰會北京站的分享內容進行總結，希望通過本篇文章介紹近些年來支付寶面向超大業務體量的挑戰，在移動端構建彈性動態架構部分做了怎樣的實戰與思考，期冀能給讀者們帶來些許幫助。
同時，關於 mPaaS 五大組件能力，目前已正式開放試用（文末有申請地址），歡迎體驗。
支付寶作為國民級應用，當前國內年活躍用戶已經超過 8.7 億，提供了超過 200 項以上的服務，而崩潰率始終維持在萬分之五以下，而且每天支付寶都上線新的功能和改進。做到今天這樣的成績，並不容易，是經過長時間的實踐經驗積累下來的。
支付寶的架構演進主要經歷了三個階段，如果用比喻的話，可以分為獨木舟、戰列艦和航空母艦三個階段。
1
獨木舟時代
支付寶剛推出移動端時，它的結構非常之簡單，除了一些工具組件被劃分為模塊，業務代碼都是糅合在一起。剛開始並沒有太大問題，但是當我們的研發人員迅速增長時，問題開始變得棘手起來，僅僅舉幾個例子便可見一斑。
- 研發同學晚上提交的可以運行的代碼，到第二天早上來更新一下就完全不能用，原因是其他不相干團隊提交代碼覆蓋或者污染了自己的代碼。
- 臨近發布點的時候，通常是最忙的，但不是忙着趕功能，而是忙着解決合併代碼產生的各種問題，不僅浪費時間，還耽誤測試同學的寶貴時間。
- 即使最後勉強發布了，穩定性和性能也是非常糟糕的，因為各個模塊只管自己的，沒有統一的規範，也缺乏統一的監控。
- 最令 Android 開發頭痛的是 65535 的問題，彼時 Google 還沒有推出 multi-dex 的方案。
這些嚴重的問題讓我們的產品研發迭代變得無法持續下去，因此我們決定來一次徹底的重構，於是步入了戰列艦時代。
2
戰列艦時代
當設計新一代的客戶端架構時，我們從三個方向進行思考：團隊協作、研發效率、性能與穩定。
團隊協作方面，我們希望整個架構分層合理，基礎層面，將通用能力下沉，為更多的上層業務服務，避免重複創造輪子；業務層面，各個業務團隊能夠獨立開發管理，不會對不相關的業務造成影響。基於這個初衷，我們形成了下圖這樣的架構：
整個客戶端架構總共分成四層：業務層、服務層、組件層、框架層。
- 業務層：只需專註於業務邏輯與界面的實現，當需要調用如支付這樣的通用能力時，研發同學直接使用下層提供的服務能力，不需自己開發，如此能夠保證核心能力有收口，方便監控。
- 服務層：常用模塊，如登錄、支付、營銷等，它們不僅自己是業務，也向其他業務提供自己的服務，我們將此類模塊歸類到服務層。
- 組件層：這一層提供的是客戶端通用能力，如安全、網絡、多媒體、存儲這些，它們提供穩定的接口給上層使用者，同時不斷優化自身內部的性能和穩定性，作為客戶端的基石，它們至關重要。
- 框架層：最為關鍵的部分，包括容器、微應用、服務框架以及 Pipeline，客戶端的微應用化、啟動管理都依賴框架層的運作。
我們將服務層、組件層和框架層合稱為 mPaaS，即移動端上的 PaaS 服務。這些 PaaS 服務可以復用，我們不僅在支付寶里使用它們，也在其他集團應用，如螞蟻財富、網商銀行等中使用。
| 業務分治
要實現業務分治，最好的方式就在代碼上能夠進行隔離，大家不必在同一個 Codebase 中開發，避免代碼合併衝突的現象。這個通常在 Android 上通常可以通過 aar 的方式來實現，但是可惜的是我們重構的時候 aar 還沒出來，而且即使有 aar，也存在打包時間隨代碼體積增大線性增長的問題。
我們的解決方案借鑒 OSGi 的概念，將整個客戶端以 Bundle 為單位劃分，每個 Bundle 可以包含自己的代碼、頁面和資源。讀者可能會想，這究竟和 aar 有什麼分別呢？其實區別很大！
首先，Bundle 里的代碼部分是已編譯的 dex，當編譯 apk 時，我們只需要合併 dex 即可，不需要像 aar 那樣將 class 編譯成 dex 再進行合併，這樣大大節省了打包時間；其次，Bundle 是可以獨立運行於自己的 ClassLoader 中的，並且我們可以通過殼代理的方式加載 Activity 等基礎組件，使得動態下發業務成為可能；最後，Bundle 里還包含微應用、服務和 Pipeline 相關的配置信息，框架會根據這些信息啟動相應的組件。
mPaaS 的服務，即 Service 類似於 Spring 框架中的 Service，它對外提供接口服務，而使用者不需要知道如何初始化服務的實例以及生命周期管理，這些完全由框架來託管。使用者只需要知道目標服務接口類的方法參數即可，調用時通過框架提供的 API 來獲取實例。對於服務的發布者來說，他在自己的 bundle 中聲明接口類以及實現接口類派生的實例類，並註冊相關信息到 bundle 的 manifest 文件中。這種做法的本質思想是 Inversion of Control，減少類之間的複雜依賴，避免繁瑣的初始化工作。
以依賴接口的方式進行開發，能夠解除服務使用者對服務提供者的依賴，在服務提供者尚未完全開發完成時，使用者可以完全以 mock 的方式來模擬服務，而不需要修改自己的業務代碼，當然，前提是雙方協商好服務接口的協議。
支付寶中的頁面非常多，直接啟動 Activity 或者 ViewController 對我們來說遠遠不夠，我們選擇在它們上面增加 MicroApp，即微應用的概念。微應用具備唯一的應用 ID，在框架中標識自己的存在。微應用具有統一的入口，根據使用方傳入的字典參數來管理 Activity 或 ViewController。這樣能夠帶來很多好處：
- 只要應用 ID 和參數協議不變，使用方不需擔心目標應用內部重構帶來的影響，直接使用 Activity 或者 ViewController 類名造成的引用泛濫的問題不復存在。
- 微應用的 ID 和字典參數特性，很容易生成 URL，從而實現外部應用使用 URL 跳轉應用內頁面。
- 從數據的角度，我們可以按業務維度來統計用戶行為數據。
- 微應用的概念不僅適用於原生頁面，同樣也適用於H5和小程序。註冊為H5或者小程序類型的應用 ID，框架會自動將啟動過程delegate給H5或者小程序容器，而使用者完全不必關心應用 ID 對應的應用類型。
綜上所述，微應用化和服務接口所賦予的特性極大提高團隊間協作效率，各研發小組之間的依賴更加簡單，可以各行其道，更關注於自身服務的打造建設。
| 性能優化
我們一方面在架構上作出重大改變來提高研發效率，另一方面也在不斷的進行性能優化，改善用戶體驗。我們主要從三個層面來着手：
- 框架層面
- 制定統一開發規範，業務方使用統一的線程池、存儲、網絡等組件，並按需進行加載，避免不必要的啟動和耗時操作。
- 引入 Pipeline 機制，業務模塊如需在應用啟動時進行初始化工作，必須使用Pipeline。框架依據業務優先級確定業務初始化實際。
- 利用 AOP 切面，對常用路徑進行耗時統計，追蹤性能瓶頸。
- 基礎指標
對於常用指標，如閃退、ANR、內存、存儲、電量、流量等，進行長期追蹤。我們能夠明確獲悉每個版本之間這些指標上的差異，並進行採樣分析，定位並解決問題。
- 向下突破
我們不僅僅在應用層面進行優化，同時也向下探索性能提升的可能性。在這方面，我們也收穫頗豐，比如在 Android 上某些系統版本，通過在啟動階段禁用 GC 的方式獲得 20%~30% 的啟動時間縮減；在 iOS 上，利用系統本身的 Background Fetch 機制提高進程活躍時間，實現應用秒起。
3
航母時代
隨着移動支付的不斷普及，面對海量的用戶和業務需求，高可用、彈性動態成為支付寶客戶端更為艱巨的挑戰。支付寶作為集支付、金融、生活為一體的服務平台，需要能夠快速穩定的發布服務和引入第三方服務，同時對於用戶的反饋和訴求必須能夠積極迅速的響應。
| 動態研發模式
我們在研發模式上作出改變以業務快速迭代的要求，業務逐步由原生頁面向 Web 混合頁面遷移。原有的研發模式能夠很好的滿足團隊協作的要求，但是隨着業務規模的不斷增大，代碼量相應膨脹導致安裝包太大，在 iOS 上一度超過代碼段上限，無法通過 AppStore 審核；另外基於集中時間點的迭代發布，通常是一個月發布一個版本，遠不能滿足業務的更新速度要求。相較於原生應用開發，Web 應用的優勢非常明顯：
- 只需要一套代碼，Web 應用可以在 iOS 和 Android 客戶端中運行，能夠相對減少人員的投入。
- 每個用戶日常使用的功能僅僅是支付寶龐大平台中的一小部分，H5應用可以做到動態下發，因此可以消除冗餘的存儲，降低包大小。
- 近些年來 React Native，Weex 等動態渲染引擎在社區非常活躍，但經過小範圍的應用以及考慮到 Web 技術的不斷發展以及其在業界公認的地位，我們最終還是選擇 Web 技術作為動態研發模式的基礎。
- Web 應用迭代擺脫了客戶端集中時間點發布的束縛，各業務線迭代計劃變得自主可控。
| 打磨 Web 體驗
儘管 Web 應用優勢明顯，但在移動端上的短板也是顯而易見的，它提供的用戶體驗、性能以及能力上的限制與原生應用有相當大的差距。為了彌補這些差距，我們做了大量的改進，主要在以下幾個方面：
- 前後端分離，我們將頁面資源離線化，這樣節省了資源請求消耗的時間，使得頁面打開速度提升明顯，解決了在網絡環境較差下容易出現白屏的問題。同時，數據請求使用 Native 網絡通道，可優化的空間更大，安全性更高。
- 差量更新，客戶端更新某業務應用版本時，不需下載完整的新版本資源包，而是下載由發布平台根據客戶端本地安裝版本計算生成的體積更小的差量包，這樣不僅能夠節省帶寬和流量，也提升了業務更新的速度。
- 推拉結合，解決業務最新版本覆蓋率的問題，每次發布新版本時，業務可主動觸發消息到客戶端，客戶端收到通知後會更新該業務應用版本。同時，客戶端會定時去檢查服務端是否有版本發布，這樣能夠保證版本發布後大多數用戶在短時間內獲得最新的應用。
- 容錯補償，客戶端可能由於網絡、安全或者存儲權限等原因，不能使用或者及時獲得離線包，這種情況我們也考慮進來了。我們在發布離線資源時，發布平台會自動生成對應的在線 URL 並配置到應用信息中，當客戶端加載 Web 應用時發現離線包不可用，會立刻啟用該 URL 加載內容，能夠最大程度保證業務可用性。
- Android 獨立瀏覽器內核，Android 碎片化的問題自其誕生之初業已存在，而且目前看上去沒有得以解決的跡象。不同系統、不同廠商中的瀏覽器內核同樣存在差異，這導致層出不窮的兼容性問題令研發同學頭疼不已，這也違背 Web 一統天下的願景。為了徹底解決並掌控這些問題，我們引入了獨立的UC瀏覽器內核並集成在應用中，這樣所有的問題都集中到 UC 團隊解決，變得非常可控，根據數據統計，使用 UC 瀏覽器內核後瀏覽器相關的閃退和 ANR 有明顯的下降。同時，安全上出現的漏洞，我們可以在第一時間修復並發布，遠比廠商升級更有效率。
- Web 應用全方位監控，資源加載異常、JS 執行異常、白屏、加載耗時等性能數據會被收集上報至後台，可以及時發現異常。
| 小程序
我們不僅自身提供各種各樣的服務，也需要引入第三方服務來服務更多的人群，以往我們只能引入簡單的第三方 H5 頁面，它們只能使用支付寶提供的少量功能，而且開發人員能力的差異導致用戶體驗不是很理想。小程序將支付寶的能力全面開放出來，從開發到測試皆有完整的 IDE 等工具鏈支持，同時 DSL 簡單易用，對於第三方來說，能夠快速開發上線一款體驗和功能比以往更強大的小程序。
| 線上高可用保障體系
在支付寶，線上風險是每個研發人員在業務前必須釐清的事情，評估風險，預防風險，監控風險，風險應急處理方案在上線都要準備好。支付寶線上的高可用保障體系由灰度發布、實時監控、診斷定位和容災恢復四大部分組成。
- 灰度發布
灰度發布是預防風險的有效手段之一，對於客戶端來說，線下測試的再怎麼完備也無法保證在用戶環境下一切正常，直接發布至全量用戶是非常危險的操作，在支付寶內部屬於嚴重違規。我們的發布平台提供多種灰度策略，包括白名單灰度、時間窗灰度、百分比灰度、基於機型地域系統等維度的灰度。新版發布前，優先選取活躍用戶和問題高發的機型進行灰度，灰度期間發現並修復問題，不斷擴大灰度範圍，直到閃退率、卡死率等指標符合發布標準後再進行全量的發布。
- 實時監控
首先，制定各種線上監控指標，包括閃退、卡死、流暢度、流量、內存、存儲以及業務不可用埋點等。
其次，上報策略上閃退、卡死、業務不可用埋點等高優先指標實時上報，第一時間發現異常；數據上報使用獨立的進程，確保不影響主業務邏輯；當處於業務高峰時期，比如春節紅包、雙 11 等大型活動時，我們能夠動態調整上報策略以緩解日誌服務端的壓力。除了自動上傳和周期性上傳策略外，我們通過下發診斷指令至客戶端去獲取平時用不到但駐留在客戶端的日誌，比如 logcat 日誌。
- 診斷定位
我們能夠根據客戶端上報的各種埋點日誌，完整描繪出用戶的操作路徑，根據這些信息，我們得以嘗試重現用戶的問題，數據的真實性相對用戶提供的信息更加可靠，能減少錯誤信息產生的干擾。另外，通過診斷指令上傳的 logcat 日誌，能夠更加完整的信息，幫助我們更清晰的定位問題，因此我們通常都要求研發同學在寫代碼的過程中能夠多輸出些有用的信息。
- 容災處理
當故障發生時，第一時間要求是能夠止血，避免損失擴大，我們通常會預置開關到業務邏輯當中，當出現業務大面積異常或資損時，後台推送業務開關至客戶端中，將業務能夠臨時屏蔽下線。
客戶端在啟動階段發生的死鎖、閃退或者主頁異常超過一定閾值，會自動清理應用數據，將應用還原至初始狀態，能夠一部分因為數據異常導致的啟動問題。
我們使用 hotpatch 技術來修復原生代碼，同樣 hotpatch 本身是個有風險的技術，因此也要經歷灰度發布的階段來逐步驗證線上穩定性，一旦發生因 patch 引起的問題，要立刻回滾 patch。
