開篇 | 模塊化與解耦式開發在螞蟻金服 mPaaS 深度實踐探討

前言

今天很高興有機會給你們分享支付寶的開發經驗，具體的內容將分紅三個部分展開：

1. 支付寶架構設計與發展；

2. 支付寶的敏捷發佈與穩定性保障；

3. 支付寶架構的優點與賦能。

1. 支付寶架構設計與發展

首先看一下支付寶的發展歷史，最開始支付寶只是做爲支付功能支持淘寶業務，後來逐步發展成爲獨立的 App，並從簡單的支付功能衍生出轉帳、水電煤支付等生活服務，如今的支付寶已經成爲一個多應用生態的超級 App。生活中你想作任何事情，幾乎均可以在支付寶上實現。

截止目前，支付寶實名註冊用戶已經超過了 8 億，日活數億。在研發上面，僅 Android、iOS 客戶端開發人員近千人，客戶端代碼行數超過了數百萬行，Android 版本支付寶的工程數業已近千個，每一個工程都有獨立的開發 owner 負責某一個具體的模塊。雖然工程師團隊及工程量愈加龐大，支付寶依舊可以作到日發佈的頻率以確保業務快速迭代。即便業務功能日益複雜，但 App 閃退率僅 0.01%。

那麼，爲了達到這樣的業務指標，咱們作了什麼呢？

隨着互聯網的應用場景進一步豐富，用戶對交互、體驗的要求也愈來愈高。由此，咱們須要在 App 的各方面下足功夫，好比客戶端的運行流暢性、最大努力下降電量、流量的能耗。

咱們最近在推的一個項目即是支付寶的網絡統一：在客戶端創建一條與服務端的長鏈接，經過這個長鏈接通道進行網絡通信協議的封裝，進行業務網絡請求的通信。通常狀況下我們每次髮網絡請求都會創建一個 HTTP 三次握手，這樣會有必定的網絡延遲和不必的流量浪費，支付寶爲了解決這樣的問題作了網絡統一庫，提高了網絡通信效率。

此外，支付寶針對掃一掃功能的性能優化，不只體如今掃碼的及時反饋，也包括對於二維碼的識別範圍相對競品會更廣。同時，國內有著名手機廠商直接在自身的手機系統中集成了支付寶的掃一掃組件，做爲系統默認的掃碼能力，這從側面反映了支付寶在細分領域的優點。

再來談談支付寶如何應對複雜的使用環境：我認爲最典型的複雜使用環境的即手機沒網的狀況下支付寶如何作到順利打開付款碼？

通常狀況下，出於安全考慮，付款碼僅在幾個小時內有效。但支付寶內置了阿里大安所有門提供的黑匣子，經過黑匣子可以有效保障移動端安全，所以即便你在弱網環境或長時間未開啓付款頁面，支付寶依然可以順利完成支付。

接下來，咱們來了解看看這一系列性能優化的背後，技術架構是如何設計和實現的。

這是支付寶客戶端的整體架構圖，從下往上看：

• 最底層是支付寶框架的容器層，包括類加載資源加載和安全模塊；
• 第二層是咱們抽離出來的組件層，包括網絡庫，日誌庫，緩存庫，多媒體庫，日誌等等，簡單說這些是一些通用的能力層；
• 第三層是咱們定製的框架層，這是關鍵部分，是咱們得以實現上千人，上千多個工程共同開發一個 App 的基礎；
• 第四層是基於框架封裝出來的業務服務層；
• 第五層即是具體的業務模塊，其中每個模塊都是一個或多個具體的工程。爲了搭建超級 App 的並行開發模式，咱們必須保證模塊與模塊之間的低耦合，實現插件式靈活的開發，所以總體業務分爲了上千多個工程。

上千個工程低耦合邏輯上是沒有問題，好比你開發網絡庫工程，他開發掃一掃工程，我開發動態發佈工程，我們代碼能夠徹底沒有耦合性，但又能如何作到相互依賴？

支付寶移動端的技術架構設計靈感便來源於 Java 的 OSGi 模塊化思想：內部對每一個工程都叫作 bundle 工程，每一個 bundle 有相應代碼和開發資源。實際上，每一個 bundle 工程都是一個 apk 工程，只是比 apk 多了一個 bundle 描述文件。這三個東西很是關鍵，回到剛纔說的工程與工程之間存在依賴，對方要如何引用？

工程之間的依賴關係只有兩種：

• 第一種：代碼層面的依賴（即我須要調用對方寫的代碼）；
• 第二種：資源層面的依賴（即我須要引用對方定義的資源，好比佈局或者樣式等）。

從代碼轉成可運行的程序能夠簡單分紅兩個時期：

• 1. 編譯期；
• 2. 運行期。

在支付寶的架構裏，編譯參與的部分是和運行期參與的部分是分離的：編譯期使用 bundle 的接口包，運行期使用 bundle 包自己。bundle 的接口包是 bundle 包的一部分，即剛纔說的 bundle 的代碼部分。bundle 的資源包同時打進接口包，在編譯期提供給另外一個 bundle 引用。

傳統模式中，依賴的 SDK 既參與編譯，也參與運行。咱們定製了編譯流程，使得編譯與運行的依賴內容分離。

問題來了，如何保證 App 在運行期代碼和資源不缺失呢？支付寶有一個容器工程（即 portal 工程），該工程中配置了全部 bundle 包的引用，在 portal 中把全部 bundle 包自己合併，最終造成 apk 包自己。這樣 bundle 引用 bundle 的接口包，僅參與編譯，最終全部 bundle 在 portal 中聚集，這樣編譯期沒問題，運行期也沒問題，從而實現了工程與工程之間依賴的解耦。

完成工程間的解耦，那麼如何解決代碼之間存在的強依賴關係？

舉個簡單例子，你引用了某個 Bundle 接口包中類 A 裏的方法 m，這個方法 m 由於一些業務緣由須要變更，那麼你就被迫須要同時改動代碼。針對這樣的問題，咱們經過框架層面提供的微服務來解決，簡單來講，即面向接口編程：具體實現與調用的接口分離，所以只要保證接口包不變，具體實現能夠由開發者任意調整而不影響使用方。

以上是代碼與代碼之間的解耦，接下來再看看業務與業務之間的解耦：

假設某個業務首頁一開始叫 ActivityA，後來由於業務優化致使這個業務首頁的入口被改，那麼跳轉到業務首頁的使用方一樣跟進改動。同理，對於 H5 前端來講，在不一樣平臺想要跳轉到同一個業務，但這兩個平臺跳轉的入口是不同的，前端怎麼跳轉？支付寶是經過框架層面的微服務和微應用來實現解耦的：

微服務是經過面向接口開發、引用，而後在框架中動態註冊的方式來實現的接口隔離解耦。 微應用是經過預先定義好一個數字來惟一標識一個業務模塊，而後動態註冊到框架中，具體這個業務模塊中有什麼，入口叫什麼，徹底由開發負責人本身決定。 全部框架註冊的微應用微服務最終會在框架啓動中動態加載。

那麼你們是否會有疑問，支付寶這麼多工程師團隊和工程量，微服務微應用之間仍須要協同配合，那麼支付寶發佈一個版本是否是很麻煩？

2. 支付寶的敏捷發佈與穩定性保障

傳統的開發模式下你們勢必互相影響，假如你提交的代碼閃退了或者業務異常了，那麼你業務關聯的開發測試必定會受到影響，通常咱們稱這樣的開發模式是「串行開發，互相等待」。而支付寶的工程解耦，代碼解耦能給工程效能帶來多大的效益？接下來咱們來聊一聊支付寶的「並行開發模式」。

支付寶每次發佈一個版本，都是由若干個 bundle 工程組成。若干個 bundle 工程合併在一塊兒叫基線，每次發佈版本以後，參與下一個版本迭代的同窗都基於這個穩定的基線作獨立的開發。而之因此可以支持獨立開發，歸功於咱們介紹的工程解耦和代碼解耦。

好比這張框架圖，餘額寶業務、ofo 小程序、螞蟻森林、網絡庫等能夠同時開發測試完成以後進入某一個大版本發佈便可，若是存在依賴關係，只須要找和本身相關同窗一塊兒進發布，正由於如此支付寶作到了天天都有不少業務進基線，天天都在同時迭代業務。

既然發佈確保了效率，那麼支付寶又是如何保證發佈穩定性的？ 傳統的開發模式是：開發測試、全量發版，而後進入下個版本的迭代，繼續開發測試修 bug、全量發版。這樣作有幾個缺點：

1. 若是測試階段未發現缺陷，極可能致使線上用戶出現大規模異常；
2. 出現大規模異常沒有修復能力，形成用戶損失；
3. 隨着業務的迭代，業務愈來愈多，功能愈來愈複雜，卡頓現象頻出，用戶體驗變差；
4. 關鍵業務監控不到位，不知道用戶怎麼使用 App，或者出現業務異常無感知，傳統的開發模式裏開發測試的比重基本上佔到了 90% 甚至 100%。

而對於支付寶來講，開發測試僅佔總體工程量 25%，如下即相應的工做拆解：

3. 支付寶架構的優點與賦能

最後，支付寶全部在移動端開發方面的技術積累和架構實踐，已經做爲螞蟻金服金融科技的一部分對外開放，即咱們今天見到的螞蟻金服 mPaaS。mPaaS(Mobile Platform As A Service)，源於支付寶 App 的移動開發平臺，爲移動開發、測試、運營及運維提供雲到端的一站式解決方案，能有效下降技術門檻、減小研發成本、提高開發效率，協助企業快速搭建穩定高質量的移動 App。

秉承着「給世界帶來小而美的變化」的理念，咱們經過 mPaaS 幫助 12306 這樣的國民級 App 重構了客戶端，使得你們能夠用上一個好的體驗的 App 進行出行購票，用 mPaaS 這樣成熟的底層框架搭建一個 12306 僅須要 2-3 個月的時間。除了 12306 還有支付寶香港版，廣發銀行發現精彩客戶端，一樣在短短几個月的時間內便完成了業務重構。

那麼，對你來講，模塊化與解耦式開發是否還有更好的方式？歡迎留言與咱們一塊兒探討。

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