微信支付的跨平臺架構到底有多牛?
閱讀本文大概需要 10 分鐘。
來自:方秋枋
背景
iOS 和安卓實現不一致
容易出 Bug
透過溝通保證不了質量
擴充套件性差,無法快速響應業務需求
需求變更迭代週期長
資料上報不全面
質量保障體系不完善
缺少業務及設計知識沉澱
協議管理鬆散
缺少統一的自動化測試
使用者體驗不一致
比如下圖就是之前安卓和 iOS 沒有統一前的收銀臺。
C++
的跨平臺框架,並對核心支付流程進行了重構。線上效果指標
Crash 率
上線前後 Crash 率保持平穩,沒有影響微信穩定性,跨平臺支付無必現 Crash,做到了使用者無感知切換。
舉個例子,大家可以用微信發一筆紅包,拉起的收銀臺和支付流程就是由基於C++編寫的跨平臺程式碼所驅動的。
效能提升
以核心支付流程程式碼為例,跨平臺需要 3512 行,iOS 原生需要 6328 行。減少了近 45% 的程式碼。
以新需求開發為例:
7.0.4 版本需求一:收銀臺改版
7.0.4 版本需求二:簡化版本收銀臺
跨平臺實現:iOS + 安卓 共計 3 人日,在封板時間前完成
原生實現:iOS, 安卓封板時間後一週才基本完成
跨平臺實現:iOS + 安卓共計 5 人日,在封板時間前完成
原生實現:iOS, 安卓封板時間後一週才基本完成
對基於 C++ 如何從零到一構建跨平臺框架感興趣的同學,可以在 %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.
什麼是軟體架構
MVC
,MVVM
等。為什麼需要軟體架構
從零到一構建支付跨平臺軟體架構
C++
來編寫業務程式碼,並沒有成熟的架構。即使使用 C++ 編寫業務邏輯,但都不涉及 UI,不涉及介面的跳轉流程。1. 抽象業務流程
MVC
這種架構的話,很快程式碼會變得難以維護。UseCase
。同時, 把介面抽象為 UIPage
。 一個大的業務流程可以分解為一個個小的業務流程。業務流程的程式碼能夠聚合到 UseCase 中,而不是分散到原來 iOS, 安卓的各個 ViewController,Activity 中。
業務流程和介面得到了複用。
契合微信支付多流程,介面跳轉複雜的業務特點。
2. 加入路由機制
流程之間,頁面之間的流傳。
比如我們要給一個朋友轉賬,輸入金額,確認支付,觸發 Cgi 後。下一個流程是多變的。有可能使用者需要去實名,有可能使用者要進入一個安全攔截的 WebView,或者是正常拉起收銀臺。
本文中的名詞
CGI
可以理解為一個網路請求,類似HTTP請求。那麼以往在 iOS, 安卓分開實現時,都沒有一個統一的處理機制。要麼就是透過網路回包的某個欄位來判斷,要麼就是本地維護一些狀態來決定下一步走什麼流程等等。非常繁瑣,易錯。
特殊流程的處理
支付業務流程還有個特殊的地方,那就是在正常流程的中間,往往很多時候要需要插入一些特殊流程。比如有些地方要跳轉 Webview, 有些地方要跳轉小程式,有些地方要彈窗告知使用者風險,或者終止當前流程,等等。我們經常需要在業務程式碼裡面不斷重複增加這樣的處理。
統一了流程,頁面的流轉。清晰,易維護。
統一了特殊流程的處理,減少重複工作。
在加入路由機制的時候,結合微信支付和網路密切相關的特點進行了支付領域建模。支付後臺協議重構 2.0 的核心思想也是圍繞著這個路由機制展開。
3. 管理網路請求
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. 規範資料傳遞
進入支付首頁時,後臺返回了資料,然後被寫入到一個公共的 Model.
然後進入錢包頁,再進入零錢頁。這個公共 model 一路被傳遞過去。
然後零錢頁讀取了公共 Model 的資料,但是程式碼無法處理,導致出現了這個讓使用者恐慌的問題。
存在公共讀寫的資料型別。
安卓傳遞的資料型別是一個字典,而 iOS 則是一個 Model 物件。所有的介面,業務邏輯都共用一個資料。
無序的資料流動。
資料的流動是不可追溯的,資料的修改可以發生在任意使用公共資料的地方。
去掉公共讀寫的資料型別
傳遞值型別(Value Type)的資料, 後面流程修改資料時,不影響前面的流程。
單向傳遞資料,只依賴注入必要資料。
如果資料修改需要通知前序流程,使用代理模式通訊。
從架構上根本解決了困擾微信支付已久的資料汙染的問題。
資料的流動變為單向,資料流動變得可追溯。
總結
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69900357/viewspace-2682410/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- XorPay 個人支付平臺【支援個人微信支付和支付寶支付介面】
- 微信支付商戶系統架構背後的故事架構
- 一篇文章告訴你:“12306”的架構到底有多牛逼?架構
- 開通微信支付(微信商戶平臺賬戶)流程及所需資料
- Laravel Admin 微信擴充套件,支援多公眾號、多小程式、多微信支付,包含後臺與介面Laravel套件
- 微信支付,支付寶支付
- Java中的微信支付(2):API V3 微信平臺證照的獲取與重新整理JavaAPI
- [Flutter翻譯]Flutter時代的多平臺VS跨平臺Flutter
- 微信平臺應用
- 微信app支付 java後臺接AndroidAPPJavaAndroid
- GStreamer跨平臺多媒體框架框架
- [轉]:多程式等待的跨平臺實現
- 支付寶、微信支付(.NET)
- Facebook AI架構總監即將入職阿里,“村小”出來的賈揚清到底有多牛?AI架構阿里
- ThinkPHP 3.2.2開發微信多使用者管理平臺PHP
- PigCms多使用者微信行銷平臺系統GC
- Php多店鋪微信商城原始碼-平臺經營PHP原始碼
- 關於微信支付,支付寶支付
- 微信JSAPI支付JSAPI
- 微信App支付APP
- [Wechat]概念辨析:微信的生態平臺/運管平臺
- 不止微信、支付寶!一文帶你瞭解所有小程式平臺
- 支付寶微信合單支付
- 微信圈(Wechat)—領先的微信行銷服務平臺
- SaaS架構:開放平臺架構設計架構
- 開發適用於微信小程式的跨平臺圖表庫:part1微信小程式
- 微信小程式的執行緒架構微信小程式執行緒架構
- Go支付中臺方案:多平臺相容與多專案對接Go
- 大佬為你揭祕微信支付的系統架構,你想知道的都在這裡了架構
- 關於支付寶以及微信支付的整合
- android微信分享、微信支付的一些坑Android
- ThinkPhp3.2.1開發的微信平臺PHP
- 使用Electron構建跨平臺的桌面應用
- 微信小程式的支付流程微信小程式
- SAP雲平臺架構概述架構
- 開放平臺架構指南架構
- nodejs微信支付之掃碼支付NodeJS
- 微信、支付寶支付那點事