高可用、彈性動態的金融級移動架構在螞蟻金服的演進之路
| 導語
本文基於重嶽在 2018 年 Arch Summit 北京站的分享內容進行總結，希望通過本篇文章介紹近些年來支付寶在移動端架構的上演進和思考，期冀能給讀者們帶來些許幫助。支付寶作為國民級應用，當前全球使用者已經超過 10 億，提供了超過 200 項以上的服務，而崩潰率始終維持在萬分之五以下，而且每天支付寶都上線新的功能和改進。做到今天這樣的成績，並不容易，是經過長時間的實踐經驗積累下來的。 支付寶的架構演進主要經歷了三個階段，如果用比喻的話，可以分為獨木舟、戰列艦和航空母艦三個階段。
| 獨木舟時代
支付寶剛推出移動端時，它的結構非常之簡單，除了一些工具元件被劃分為模組，業務程式碼都是糅合在一起。剛開始並沒有太大問題，但是當我們的研發人員迅速增長時，問題開始變得棘手起來，僅僅舉幾個例子便可見一斑。- 研發同學晚上提交的可以執行的程式碼，到第二天早上來更新一下就完全不能用，原因是其他不相干團隊提交程式碼覆蓋或者汙染了自己的程式碼。
- 臨近釋出點的時候，通常是最忙的，但不是忙著趕功能，而是忙著解決合併程式碼產生的各種問題，不僅浪費時間，還耽誤測試同學的寶貴時間。
- 即使最後勉強釋出了，穩定性和效能也是非常糟糕的，因為各個模組只管自己的，沒有統一的規範，也缺乏統一的監控。
- 最令 Android 開發頭痛的是 65535 的問題，彼時 Google 還沒有推出 multi-dex 的方案。
| 戰列艦時代
當設計新一代的客戶端架構時，我們從三個方向進行思考：團隊協作、研發效率、效能與穩定。
團隊協作方面，我們希望整個架構分層合理，基礎層面，將通用能力下沉，為更多的上層業務服務，避免重複創造輪子；業務層面，各個業務團隊能夠獨立開發管理，不會對不相關的業務造成影響。基於這個初衷，我們形成了下圖這樣的架構：
整個客戶端架構總共分成四層：業務層、服務層、元件層、框架層。
- 業務層：只需專注於業務邏輯與介面的實現，當需要呼叫如支付這樣的通用能力時，研發同學直接使用下層提供的服務能力，不需自己開發，如此能夠保證核心能力有收口，方便監控。
- 服務層：常用模組，如登入、支付、營銷等，它們不僅自己是業務，也向其他業務提供自己的服務，我們將此類模組歸類到服務層。
- 元件層：這一層提供的是客戶端通用能力，如安全、網路、多媒體、儲存這些，它們提供穩定的介面給上層使用者，同時不斷優化自身內部的效能和穩定性，作為客戶端的基石，它們至關重要。
- 框架層：最為關鍵的部分，包括容器、微應用、服務框架以及 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 機制提高程序活躍時間，實現應用秒起。| 航母時代
隨著移動支付的不斷普及，面對海量的使用者和業務需求，高可用、彈性動態成為支付寶客戶端更為艱鉅的挑戰。支付寶作為集支付、金融、生活為一體的服務平臺，需要能夠快速穩定的釋出服務和引入第三方服務，同時對於使用者的反饋和訴求必須能夠積極迅速的響應。 我們在研發模式上作出改變以業務快速迭代的要求，業務逐步由原生頁面向 Web 混合頁面遷移。原有的研發模式能夠很好的滿足團隊協作的要求，但是隨著業務規模的不斷增大，程式碼量相應膨脹導致安裝包太大，在iOS上一度超過程式碼段上限，無法通過 AppStore 稽核，另外基於集中時間點的迭代釋出，通常是一個月釋出一個版本，遠不能滿足業務的更新速度要求。相較於原生應用開發，Web應用的優勢非常明顯：- 只需要一套程式碼，Web 應用可以在 iOS 和 Android 客戶端中執行，能夠相對減少人員的投入。
- 每個使用者日常使用的功能僅僅是支付寶龐大平臺中的一小部分，H5 應用可以做到動態下發，因此可以消除冗餘的儲存，降低包大小。
- 近些年來 React Native，Weex 等動態渲染引擎在社群非常活躍，但經過小範圍的應用以及考慮到 Web 技術的不斷髮展以及其在業界公認的地位，我們最終還是選擇 Web 技術作為動態研發模式的基礎。
- Web 應用迭代擺脫了客戶端集中時間點發布的束縛，各業務線迭代計劃變得自主可控。
- 前後端分離，我們將頁面資源離線化，這樣節省了資源請求消耗的時間，使得頁面開啟速度提升明顯，解決了在網路環境較差下容易出現白屏的問題。同時，資料請求使用 native 網路通道，可優化的空間更大，安全性更高。
- 差量更新，客戶端更新某業務應用版本時，不需下載完整的新版本資源包，而是下載由釋出平臺根據客戶端本地安裝版本計算生成的體積更小的差量包，這樣不僅能夠節省頻寬和流量，也提升了業務更新的速度。
- 推拉結合，解決業務最新版本覆蓋率的問題，每次釋出新版本時，業務可主動觸發訊息到客戶端，客戶端收到通知後會更新該業務應用版本。同時，客戶端會定時去檢查服務端是否有版本釋出，這樣能夠保證版本釋出後大多數使用者在短時間內獲得最新的應用。
- 容錯補償，客戶端可能由於網路、安全或者儲存許可權等原因，不能使用或者及時獲得離線包，這種情況我們也考慮進來了。我們在釋出離線資源時，釋出平臺會自動生成對應的線上 URL 並配置到應用資訊中，當客戶端載入 Web 應用時發現離線包不可用，會立刻啟用該url載入內容，能夠最大程度保證業務可用性。
- Android 獨立瀏覽器核心，Android 碎片化的問題自其誕生之初業已存在，而且目前看上去沒有得以解決的跡象。不同系統、不同廠商中的瀏覽器核心同樣存在差異，這導致層出不窮的相容性問題令研發同學頭疼不已，這也違背 Web 一統天下的願景。為了徹底解決並掌控這些問題，我們引入了獨立的 UC 瀏覽器核心並整合在應用中，這樣所有的問題都集中到UC團隊解決，變得非常可控，根據資料統計，使用 UC 瀏覽器核心後瀏覽器相關的閃退和 ANR 有明顯的下降。同時，安全上出現的漏洞，我們可以在第一時間修復併發布，遠比廠商升級更有效率。
- Web 應用全方位監控，資源載入異常、JS執行異常、白屏、載入耗時等效能資料會被收集上報至後臺，可以及時發現異常。
灰度釋出
灰度釋出是預防風險的有效手段之一，對於客戶端來說，線下測試的再怎麼完備也無法保證在使用者環境下一切正常，直接釋出至全量使用者是非常危險的操作，在支付寶內部屬於嚴重違規。我們的釋出平臺提供多種灰度策略，包括白名單灰度、時間窗灰度、百分比灰度、基於機型地域系統等維度的灰度。新版釋出前，優先選取活躍使用者和問題高發的機型進行灰度，灰度期間發現並修復問題，不斷擴大灰度範圍，直到閃退率、卡死率等指標符合釋出標準後再進行全量的釋出。實時監控
首先，制定各種線上監控指標，包括閃退、卡死、流暢度、流量、記憶體、儲存以及業務不可用埋點等。 其次，上報策略上閃退、卡死、業務不可用埋點等高優先指標實時上報，第一時間發現異常；資料上報使用獨立的程序，確保不影響主業務邏輯；當處於業務高峰時期，比如春節紅包、雙 11 等大型活動時，我們能夠動態調整上報策略以緩解日誌服務端的壓力。除了自動上傳和週期性上傳策略外，我們通過下發診斷指令至客戶端去獲取平時用不到但駐留在客戶端的日誌，比如 logcat 日誌。診斷定位
我們能夠根據客戶端上報的各種埋點日誌，完整描繪出使用者的操作路徑，根據這些資訊，我們得以嘗試重現使用者的問題，資料的真實性相對使用者提供的資訊更加可靠，能減少錯誤資訊產生的干擾。另外，通過診斷指令上傳的 logcat 日誌，能夠更加完整的資訊，幫助我們更清晰的定位問題，因此我們通常都要求研發同學在寫程式碼的過程中能夠多輸出些有用的資訊。容災處理
當故障發生時，第一時間要求是能夠止血，避免損失擴大，我們通常會預置開關到業務邏輯當中，當出現業務大面積異常或資損時，後臺推送業務開關至客戶端中，將業務能夠臨時遮蔽下線。 客戶端在啟動階段發生的死鎖、閃退或者主頁異常超過一定閾值，會自動清理應用資料，將應用還原至初始狀態，能夠一部分因為資料異常導致的啟動問題。 我們使用 hotpatch 技術來修復原生程式碼，同樣 hotpatch 本身是個有風險的技術，因此也要經歷灰度釋出的階段來逐步驗證線上穩定性，一旦發生因 patch 引起的問題，要立刻回滾 patch。| 啟航出海
支付寶的移動架構 mPaaS 不僅僅在螞蟻金服內部得到廣泛的採用，而且其核心的元件以及背後的研發理念如今已輸出包括廣發銀行、西安銀行、華夏銀行等眾多金融機構，幫助他們打造更具競爭力的移動平臺入口。關於支付寶移動架構如何演進、如何滿足業務和使用者的需求，這其中還有很多細節和硬貨可以跟讀者分享，這裡因篇幅限制不能夠一一敘述，後續會有更多的相關文章更加深入探討各方面的話題。
往期閱讀
《螞蟻金服 mPaaS 服務端核心元件體系概述：移動 API 閘道器 MGS》
《螞蟻金服 mPaaS 服務端核心元件：億級併發下的移動端到端網路接入架構解析》