背景
作為一個重要業務，微信支付在客戶端上面臨著各種問題。其中最核心問題就是分平臺實現導致的問題：
- iOS 和安卓實現不一致
- 容易出 Bug
- 通過溝通保證不了質量
- 擴展性差，無法快速響應業務需求
- 需求變更迭代週期長
- 數據上報不全面
- 質量保障體系不完善
- 缺少業務及設計知識沉澱
- 協議管理鬆散
- 缺少統一的自動化測試
- 用戶體驗不一致比如下圖就是之前安卓和 iOS 沒有統一前的收銀臺。
為了解決分平臺實現這個核心問題，並解決以往的技術債務。我們建立起了一整套基於 C++ 的跨平臺框架，並對核心支付流程進行了重構。
微信支付跨平臺從 iOS 7.0.4 版本起， 安卓從 7.0.7 版本起全面覆蓋。
線上效果指標
以 iOS 上線情況為例:
- Crash 率上線前後 Crash 率保持平穩，沒有影響微信穩定性，跨平臺支付無必現 Crash，做到了用戶無感知切換。舉個例子，大家可以用微信發一筆紅包，拉起的收銀臺和支付流程就是由基於C++編寫的跨平臺代碼所驅動的。
- 效能提升以核心支付流程代碼為例，跨平臺需要 3512 行，iOS 原生需要 6328 行。減少了近 45% 的代碼。以新需求開發為例：7.0.4 版本需求一：收銀臺改版7.0.4 版本需求二：簡化版本收銀臺
- 跨平臺實現：iOS + 安卓 共計 3 人日，在封板時間前完成
- 原生實現：iOS， 安卓封板時間後一週才基本完成
- 跨平臺實現：iOS + 安卓共計 5 人日，在封板時間前完成
- 原生實現：iOS， 安卓封板時間後一週才基本完成
那麼支付跨平臺軟件架構怎麼樣有效進行質量保障，並且提升生產力呢？這是這篇文章的主要內容。
對基於 C++ 如何從零到一構建跨平臺框架感興趣的同學，可以在 https://github.com/100mango/zen/blob/master/Qcon2019/%E5%9F%BA%E4%BA%8E%20C%2B%2B%20%E6%9E%84%E5%BB%BA%E5%BE%AE%E4%BF%A1%E5%AE%A2%E6%88%B7%E7%AB%AF%E8%B7%A8%E5%B9%B3%E5%8F%B0%E5%BC%80%E5%8F%91%E6%A1%86%E6%9E%B6.key 下載我在 2019 QCon 廣州站的演講 《基於 C++ 構建微信客戶端跨平臺開發框架》的 Keynote.
什麼是軟件架構
什麼是軟件架構？正如 Ivar Jacobson （UML 之父）說過的一樣，找五個人來回答這個問題，五個人可能都有各自不同的答案。
架構定義可以有很多種說法，從代碼規範到發佈流程都可以是架構的一部分。
針對微信支付的業務特點，這裡對架構的定義是：架構是系統的組成部件及其之間的相互關係（通訊方式）。這更符合我們程序員日常編寫業務代碼時對架構的理解。也就是通俗意義上講的 MVC，MVVM 等。
為什麼需要軟件架構
早在 1986 年的時候，人月神話的作者在討論軟件的複雜性時，談到：軟件的本質複雜性存在於複雜的業務需求中。
而管理複雜性，最根本的手段就是職責分離。為了實現職責分離，代碼重用，架構慢慢地復現出來。架構的本質是管理複雜性。
沒有架構，我們所有的代碼都耦合在一起，人類的心智模型不擅長處理這種複雜性，架構的設立，和圖書館的圖書分類，公司的組織劃分等，本質都是一樣的。是為了管理複雜性，以取得更高的生產力。
從零到一構建支付跨平臺軟件架構
在移動客戶端領域，業界基於 C++ 來編寫業務代碼，並沒有成熟的架構。即使使用 C++ 編寫業務邏輯，但都不涉及 UI，不涉及界面的跳轉流程。
既然業界沒有一個成熟的架構可借鑑，那麼是不是直接把業界通用的架構簡單套用一下就好？
1. 抽象業務流程
現在業界通用的有 MVC , MVP, MVVM 。這些大家都熟悉的軟件架構。但是這些軟件架構都存在一個問題： 那就是沒有處理好業務流程， 界面轉場。
微信支付的流程多。而流程就是由一個個的界面（ViewController，Activity）和相關的業務邏輯組合而成。
上面的 MV(X) 模式忽略了一個非常重要的一點，那就是業務流程，界面的轉場究竟由誰負責。也即 ViewController 與 ViewController 之間的關係由誰維護，業務流程的邏輯寫在哪裡。如果還按照傳統的 MVC 模式，那麼 ViewController 自己負責和不同的 ViewController 通訊。那麼 ViewController 得不到複用，更致命的是業務流程的代碼非常不清晰，業務流程的代碼都被分散到各個 Controller 中， 而一個 Controller 又可能耦合了多個業務的代碼。
舉個例子：一個普通的轉賬流程，可能會涉及風控攔截，實名驗證， 收銀臺， 綁卡，支付成功頁等等。如果是基於 MVC 這種架構的話，很快代碼會變得難以維護。
因此，為了適應微信支付流程多，界面跳轉複雜的特點。架構抽象的第一步就是將業務流程抽象為一個獨立的角色 UseCase。同時, 把界面抽象為 UIPage。 一個大的業務流程可以分解為一個個小的業務流程。
和剛才基於 MVC 混亂的架構相比：
- 業務流程的代碼能夠聚合到 UseCase 中，而不是分散到原來 iOS, 安卓的各個 ViewController，Activity 中。
- 業務流程和界面得到了複用。
- 契合微信支付多流程，界面跳轉複雜的業務特點。
2. 加入路由機制
既然流程得到了抽象，這個時候需要針對業務流程做更深的思考。在開發支付業務流程時，開發者不可繞過的問題有：
- 流程之間，頁面之間的流傳。比如我們要給一個朋友轉賬，輸入金額，確認支付,觸發 Cgi 後。下一個流程是多變的。有可能用戶需要去實名，有可能用戶要進入一個安全攔截的 WebView，或者是正常拉起收銀臺。本文中的名詞 CGI 可以理解為一個網絡請求，類似HTTP請求。那麼以往在 iOS, 安卓分開實現時，都沒有一個統一的處理機制。要麼就是通過網絡回包的某個字段來判斷，要麼就是本地維護一些狀態來決定下一步走什麼流程等等。非常繁瑣，易錯。
- 特殊流程的處理支付業務流程還有個特殊的地方，那就是在正常流程的中間，往往很多時候要需要插入一些特殊流程。比如有些地方要跳轉 Webview, 有些地方要跳轉小程序，有些地方要彈窗告知用戶風險，或者終止當前流程，等等。我們經常需要在業務代碼裡面不斷重複增加這樣的處理。
這些問題，引導我想到，微信支付需要一個路由機制。
首先了解一下路由機制。
路由機制的核心思想，就是通過向路由傳遞數據，然後路由解析數據，並響應。
結合微信支付和網絡密切相關的特點。創新地將支付領域模型作為傳遞的數據。
那麼怎麼建立這個支付領域模型的呢？
建模，就是建立映射。領域知識 + 建模方法 = 領域建模。那麼這裡的領域知識，就是對支付業務流程的理解。建模方法，我採用了 UML 建模。最終會落地為 Proto 協議供客戶端和後臺一起使用。
首先，微信支付業務特點就是和網絡密切相關，流程和頁面往往是由 Cgi 串聯起來。因此建立模型時，最外層便是網絡回包。對於路由機制，這裡我們只關心路由數據模型。
路由數據模型由 路由類型，還有各個路由類型所需要的信息組合成。
路由類型清晰的定義了要觸發的行為。究竟是要開啟一個 UseCase，還是要打開一個界面，或者 網頁，小程序，彈窗等等。
然後就是這些行為所需要的數據。比如打開小程序所需要的參數，彈窗所需要的參數等。
建立支付領域模型後，我們路由的解析就變得非常清晰了。路由解析之後，會根據路由類型，觸發不同的動作。
比如流程，界面流轉，會交給 UseCase 處理。
而特殊流程，比如打開小程序，打開 webview, 彈窗這些行為會統一進行處理。
我們在第一步把業務流程抽象為 UseCase。第二步則加入了路由機制。
加入路由機制後，支付跨平臺的軟件架構演進為這個樣子。
加入路由機制後，對比 iOS，安卓原來的舊架構:
- 統一了流程，頁面的流轉。清晰，易維護。
- 統一了特殊流程的處理，減少重複工作。
- 在加入路由機制的時候，結合微信支付和網絡密切相關的特點進行了支付領域建模。支付後臺協議重構 2.0 的核心思想也是圍繞著這個路由機制展開。
再來看一下，加入路由機制後，對生產力的提升。以支付流程打開 WebView, 小程序為例，減少將近 83% 的代碼。更重要的是，這裡的特殊流程，是在路由機制裡面統一處理的，沒有耦合到業務代碼中，並且是可複用的。
3. 管理網絡請求
首先看看原來 iOS 處理支付網絡請求的缺陷：
原來支付的請求，都是通過一個單例網絡中心去發起請求，然後收到回包後，通過拋通知，或者調用閉包的方式回調給業務側。
會存在這樣的問題：
- CGI 一對多通訊問題。舉個之前遇到的問題。那麼錢包發起的 Cgi 的回包就會覆蓋收付款頁面的數據。之前在 iOS 只能通過修修補補，增加場景值，增加些標記位來解決。可能某一天就會又出現新的坑。
- 進入錢包頁面後，發起了一個 Cgi
- 然後進入收付款頁面也發起同一個 Cgi.
- 如果收付款發起的回包先到
- 然後錢包首頁的回包再到。
- CGI 生命週期問題。不時會有用戶反饋一下，怎麼沒有做什麼操作，突然就會彈出網絡報錯。原因就是 Cgi 的生命週期有問題，在業務結束後，Cgi 的回包仍然得到了處理。
解決方案：
- 將 Cgi 抽象為獨立對象在架構設計上來說，舊架構是通過單例模式實現的集約型 API，而我們新的架構則是通過命令模式實現的離散型 API。也就是將 Cgi 封裝為獨立對象。我們把 Cgi 相關屬性和能力內聚起來。開發業務時，只需簡單繼承 BaseCgi，設置一下參數即可。
- 劃分職責，明確生命週期關於 Cgi 由誰發起，之前安卓和 iOS 都沒有一個統一的做法。有些人會放到 Activity，ViewController，和 UI 代碼耦合起來。因此，在跨平臺軟件架構中，我們統一由業務流程 UseCase 進行發起。並且生命週期是一對一的，一個 Cgi 只會有一個 UseCase 處理， UseCase 銷燬後，Cgi 也隨之銷燬。
對比舊架構：
- 杜絕了一對多通信造成的 Bug
- 生命週期和業務邏輯綁定，不會出現業務結束，Cgi 回來後再觸發動作。
- 高內聚，低耦合。將 Cgi 相關的數據，能力集中處理，業務側無需感知。
- 提供統一的緩存，加密能力。
第一步和第二步，我們抽象了業務流程，加入了路由機制。
在第三步管理網絡請求後。我們的軟件架構演進為這樣子。
4. 規範數據傳遞
iOS 和安卓的舊架構都存在信息傳遞不當和數據汙染問題。這個問題最嚴重。iOS 和 安卓都出過不少 bug。
首先我們來看看最近現網出現過的問題：
之前 iOS 出現，不少內部同事，外部的用戶都在反饋：進行零錢頁後，會無故彈空白框。而支付又和金錢有關，引起用戶的恐慌。
具體原因就是:
- 進入支付首頁時，後臺返回了數據，然後被寫入到一個公共的 Model.
- 然後進入錢包頁，再進入零錢頁。這個公共 model 一路被傳遞過去。
- 然後零錢頁讀取了公共 Model 的數據，但是代碼無法處理，導致出現了這個讓用戶恐慌的問題。
除此之外，之前還有有很多發生在安卓，iOS ，像錢包頁零錢展示錯誤。付款的時候。銀行卡失效等等問題。
這些問題五花八門，看起來發生的地方，場景都不一樣。每次遇到這類問題的時候，就只能去修修補補。
但是深究下去，會發現真正的原因，是軟件架構上存在的問題：
支付舊的架構採用了黑板模式，雖然方便了數據讀寫。但是帶來的問題和收益完全不成正比：
- 存在公共讀寫的數據類型。安卓傳遞的數據類型是一個字典，而 iOS 則是一個 Model 對象。所有的界面，業務邏輯都共用一個數據。
- 無序的數據流動。數據的流動是不可追溯的，數據的修改可以發生在任意使用公共數據的地方。
那麼支付跨平臺軟件架構，為了杜絕這樣的問題。我是這麼做的:
- 去掉公共讀寫的數據類型
- 傳遞值類型（Value Type）的數據, 後面流程修改數據時，不影響前面的流程。
- 單向傳遞數據，只依賴注入必要數據。
- 如果數據修改需要通知前序流程，使用代理模式通訊。
規範數據傳遞後。對比舊架構:
- 從架構上根本解決了困擾微信支付已久的數據汙染的問題。
- 數據的流動變為單向，數據流動變得可追溯。
前面三步，我們抽象了業務流程，加入了路由機制，統一管理網絡請求。
那麼規範數據傳遞後，我們軟件架構就演進為這樣子。
總結
軟件的本質複雜性存在於複雜的業務需求中。而軟件架構的本質就是管理複雜性，因此真正的好的架構，正是在複雜的業務需求中反覆提煉和總結歸納而來，解決了真正的業務問題，不是空談。
軟件架構除了清理歷史舊架構的缺陷，是我們業務開發的基石之外。還能夠賦能業務，為業務帶來價值。在建立軟件架構的基礎上，還圍繞著軟件架構建立起微信支付的跨平臺自動化數據上報機制，防重複支付，安全橫切等帶來巨大業務收益的能力。有機會的話，後面也會進一步編寫相關文章和大家交流探討。
架構是一個不斷演進的過程，隨著新的支付業務基於跨平臺軟件架構的不斷編寫， 我也會對這個架構進行持續的更新迭代。讓這個軟件架構更貼合微信支付，更加健壯和完整。
閱讀更多 Java桔煙 的文章
