前言
今天很高興有機會給大家分享支付寶的開發經驗，具體的内容将分成三個部分展開：
- 支付寶架構設計與發展；
- 支付寶的靈活釋出與穩定性保障；
- 支付寶架構的優勢與賦能。
1. 支付寶架構設計與發展
首先看一下支付寶的發展曆史，最開始支付寶隻是作為支付功能支援淘寶業務，後來逐漸發展成為獨立的 App，并從簡單的支付功能衍生出轉賬、水電煤支付等生活服務，現在的支付寶已經成為一個多應用生态的超級 App。生活中你想做任何事情，幾乎都可以在支付寶上實作。
截止目前，支付寶實名注冊使用者已經超過了 8 億，日活數億。在研發上面，僅 Android、iOS 用戶端開發人員近千人，用戶端代碼行數超過了數百萬行，Android 版本支付寶的工程數業已近千個，每個工程都有獨立的開發 owner 負責某一個具體的子產品。雖然工程師團隊及工程量越發龐大，支付寶依舊能夠做到日釋出的頻率以確定業務快速疊代。即使業務功能日益複雜，但 App 閃退率僅 0.01%。
那麼，為了達到這樣的業務名額，我們做了什麼呢？
随着網際網路的應用場景進一步豐富，使用者對互動、體驗的要求也越來越高。由此，我們需要在 App 的各方面下足功夫，比如用戶端的運作流暢性、最大努力降低電量、流量的能耗。
我們最近在推的一個項目便是支付寶的網絡統一：在用戶端建立一條與服務端的長連接配接，通過這個長連接配接通道進行網絡通訊協定的封裝，進行業務網絡請求的通訊。一般情況下咱們每次發網絡請求都會建立一個 HTTP 三次握手，這樣會有一定的網絡延遲和沒必要的流量浪費，支付寶為了解決這樣的問題做了網絡統一庫，提升了網絡通訊效率。
此外，支付寶針對掃一掃功能的性能優化，不僅展現在掃碼的及時回報，也包括對于二維碼的識别範圍相對競品會更廣。同時，國内有著名手機廠商直接在自身的手機系統中內建了支付寶的掃一掃元件，作為系統預設的掃碼能力，這從側面反映了支付寶在細分領域的優勢。
再來談談支付寶如何應對複雜的使用環境：我認為最典型的複雜使用環境的即手機沒網的情況下支付寶如何做到順利打開付款碼？
一般情況下，出于安全考慮，付款碼僅在幾個小時内有效。但支付寶内置了阿裡大安全部門提供的黑匣子，通過黑匣子能夠有效保障移動端安全，是以即使你在弱網環境或長時間未開啟付款頁面，支付寶依然能夠順利完成支付。
接下來，我們來了解看看這一系列性能優化的背後，技術架構是如何設計和實作的。
這是支付寶用戶端的總體架構圖，從下往上看：
- 最底層是支付寶架構的容器層，包括類加載資源加載和安全子產品；
- 第二層是我們抽離出來的元件層，包括網絡庫，日志庫，緩存庫，多媒體庫，日志等等，簡單說這些是一些通用的能力層；
- 第三層是我們定制的架構層，這是關鍵部分，是我們得以實作上千人，上千多個工程共同開發一個 App 的基礎；
- 第四層是基于架構封裝出來的業務服務層；
- 第五層便是具體的業務子產品，其中每一個子產品都是一個或多個具體的工程。為了搭建超級 App 的并行開發模式，我們必須保證子產品與子產品之間的低耦合，實作插件式靈活的開發，是以整體業務分為了上千多個工程。
上千個工程低耦合邏輯上是沒有問題，比如你開發網絡庫工程，他開發掃一掃工程，我開發動态釋出工程，咱們代碼可以完全沒有耦合性，但又能如何做到互相依賴？
支付寶移動端的技術架構設計靈感便來源于 Java 的 OSGi 子產品化思想：内部對每個工程都叫做 bundle 工程，每個 bundle 有相應代碼和開發資源。實際上，每個 bundle 工程都是一個 apk 工程，隻是比 apk 多了一個 bundle 描述檔案。這三個東西非常關鍵，回到剛才說的工程與工程之間存在依賴，對方要如何引用？
工程之間的依賴關系隻有兩種：
- 第一種：代碼層面的依賴（即我需要調用對方寫的代碼）；
- 第二種：資源層面的依賴（即我需要引用對方定義的資源，比如布局或者樣式等）。
從代碼轉成可運作的程式可以簡單分成兩個時期：
-
- 編譯期；
-
- 運作期。
在支付寶的架構裡，編譯參與的部分是和運作期參與的部分是分離的：編譯期使用 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、全量發版。這樣做有幾個缺點：
- 如果測試階段未發現缺陷，很可能導緻線上使用者出現大規模異常；
- 出現大規模異常沒有修複能力，造成使用者損失；
- 随着業務的疊代，業務越來越多，功能越來越複雜，卡頓現象頻出，使用者體驗變差；
- 關鍵業務監控不到位，不知道使用者怎麼使用 App，或者出現業務異常無感覺，傳統的開發模式裡開發測試的比重基本上占到了 90% 甚至 100%。
而對于支付寶來說，開發測試僅占整體工程量 25%，以下即相應的工作拆解：
3. 支付寶架構的優勢與賦能
最後，支付寶所有在移動端開發方面的技術積累和架構實踐，已經作為螞蟻金服金融科技的一部分對外開放，即我們今天見到的螞蟻金服 mPaaS。mPaaS(Mobile Platform As A Service)，源于支付寶 App 的移動開發平台，為移動開發、測試、營運及運維提供雲到端的一站式解決方案，能有效降低技術門檻、減少研發成本、提升開發效率，協助企業快速搭建穩定高品質的移動 App。
秉承着「給世界帶來小而美的變化」的理念，我們通過 mPaaS 幫助 12306 這樣的國民級 App 重構了用戶端，使得大家可以用上一個好的體驗的 App 進行出行購票，用 mPaaS 這樣成熟的底層架構搭建一個 12306 僅需要 2-3 個月的時間。除了 12306 還有支付寶香港版，廣發銀行發現精彩用戶端，同樣在短短幾個月的時間内便完成了業務重構。
那麼，對你來說，子產品化與解耦式開發是否還有更好的方式？歡迎留言與我們一起探讨。