摘要: 支付寶作為國民級應用,當前全球用戶已經超過 10 億,提供了超過 200 項以上的服務,而崩潰率始終維持在萬分之五以下,而且每天支付寶都上線新的功能和改進。做到今天這樣的成績,並不容易,是經過長時間的實踐經驗積累下來的。
本文基於重岳在 2018 年 Arch Summit 北京站的分享內容進行總結,希望通過本篇文章介紹近些年來支付寶在移動端架構的上演進和思考,期冀能給讀者們帶來些許幫助。
支付寶的架構演進主要經歷了三個階段,如果用比喻的話,可以分為獨木舟、戰列艦和航空母艦三個階段。
支付寶剛推出移動端時,它的結構非常之簡單,除了一些工具組件被劃分為模塊,業務代碼都是糅合在一起。剛開始並沒有太大問題,但是當我們的研發人員迅速增長時,問題開始變得棘手起來,僅僅舉幾個例子便可見一斑。
這些嚴重的問題讓我們的產品研發迭代變得無法持續下去,因此我們決定來一次徹底的重構,於是步入了戰列艦時代。
當設計新一代的客戶端架構時,我們從三個方向進行思考:團隊協作、研發效率、性能與穩定。
團隊協作方面,我們希望整個架構分層合理,基礎層面,將通用能力下沉,為更多的上層業務服務,避免重複創造輪子;業務層面,各個業務團隊能夠獨立開發管理,不會對不相關的業務造成影響。基於這個初衷,我們形成了下圖這樣的架構:
我們將服務層、組件層和框架層合稱為 mPaaS,即移動端上的 PaaS 服務。這些 PaaS 服務可以復用,我們不僅在支付寶里使用它們,也在其他集團應用,如螞蟻財富、網商銀行等中使用。
要實現業務分治,最好的方式就在代碼上能夠進行隔離,大家不必在同一個 Codebase 中開發,避免代碼合併衝突的現象,這個通常在 Android 上通常可以 aar 的方式來實現,但是可惜的是我們重構的時候 aar 還沒出來,而且即使有 aar,也存在打包時間隨代碼體積增大線性增長的問題。
我們的解決方案借鑒 OSGi 的概念,將整個客戶端以 Bundle 為單位劃分,每個 Bundle 可以包含自己的代碼、頁面和資源。讀者可能會想,這究竟和 aar 有什麼分別呢?其實區別很大!
首先,Bundle 里的代碼部分是已編譯的 dex,當編譯 apk 時,我們只需要合併 dex 即可,不需要像 aar 那樣將 class 編譯成 dex 再進行合併,這樣大大節省了打包時間;其次,Bundle 是可以獨立運行於自己的 ClassLoader 中的,並且我們可以通過殼代理的方式載入 Activity 等基礎組件,使得動態下發業務成為可能;最後,Bundle 里還包含微應用、服務和 Pipeline 相關的配置信息,框架會根據這些信息啟動相應的組件。
對於服務的發布者來說,他在自己的 bundle 中聲明介面類以及實現介面類派生的實例類,並註冊相關信息到 bundle 的 manifest 文件中。這種做法的本質思想是 Inversion of Control,減少類之間的複雜依賴,避免繁瑣的初始化工作。以依賴介面的方式進行開發,能夠解除服務使用者對服務提供者的依賴,在服務提供者尚未完全開發完成時,使用者可以完全以 mock 的方式來模擬服務,而不需要修改自己的業務代碼,當然,前提是雙方協商好服務介面的協議。
綜上所述,微應用化和服務介面所賦予的特性極大提高團隊間協作效率,各研發小組之間的依賴更加簡單,可以各行其道,更關注於自身服務的打造建設。
我們一方面在架構上作出重大改變來提高研發效率,另一方面也在不斷的進行性能優化,改善用戶體驗。我們主要從三個層面來著手:
框架層面
基礎指標
對於常用指標,如閃退、ANR、內存、存儲、電量、流量等,進行長期追蹤。我們能夠明確獲悉每個版本之間這些指標上的差異,並進行採樣分析,定位並解決問題。
向下突破
我們不僅僅在應用層面進行優化,同時也向下探索性能提升的可能性。在這方面,我們也收穫頗豐,比如在 Android 上某些系統版本,通過在啟動階段禁用 GC 的方式獲得 20%~30% 的啟動時間縮減;在 iOS 上,利用系統本身的 Background Fetch 機制提高進程活躍時間,實現應用秒起。
隨著移動支付的不斷普及,面對海量的用戶和業務需求,高可用、彈性動態成為支付寶客戶端更為艱巨的挑戰。支付寶作為集支付、金融、生活為一體的服務平台,需要能夠快速穩定的發布服務和引入第三方服務,同時對於用戶的反饋和訴求必須能夠積極迅速的響應。
我們在研發模式上作出改變以業務快速迭代的要求,業務逐步由原生頁面向 Web 混合頁面遷移。原有的研發模式能夠很好的滿足團隊協作的要求,但是隨著業務規模的不斷增大,代碼量相應膨脹導致安裝包太大,在iOS上一度超過代碼段上限,無法通過 AppStore 審核,另外基於集中時間點的迭代發布,通常是一個月發布一個版本,遠不能滿足業務的更新速度要求。相較於原生應用開發,Web應用的優勢非常明顯:
儘管 Web 應用優勢明顯,但在移動端上的短板也是顯而易見的,它提供的用戶體驗、性能以及能力上的限制與原生應用有相當大的差距。為了彌補這些差距,我們做了大量的改進,主要在以下幾個方面:
我們不僅自身提供各種各樣的服務,也需要引入第三方服務來服務更多的人群,以往我們只能引入簡單的第三方 H5 頁面,它們只能使用支付寶提供的少量功能,而且開發人員能力的差異導致用戶體驗不是很理想。小程序將支付寶的能力全面開放出來,從開發到測試皆有完整的 IDE 等工具鏈支持,同時 DSL 簡單易用,對於第三方來說,能夠快速開發上線一款體驗和功能比以往更強大的小程序。
本文作者:josephjin
原文鏈接
更多技術乾貨敬請關注云棲社區知乎機構號:阿里云云棲社區 - 知乎
本文為雲棲社區原創內容,未經允許不得轉載。
推薦閱讀: