解碼 | 25 分鐘開發分散式架構的轉賬小程式

螞蟻金服分散式架構發表於2018-09-19

如今，轉賬場景深入在我們生活的方方面面，也有很多技術團隊在獨立開發轉賬的小程式。
本文將給大家對比常見的小程式和分散式小程式的優劣，最後藉助 SOFAStack 的能力，提供 25 分鐘實現穩定的分散式架構的轉賬小程式的 Demo。

背景

2017 年 12 月，螞蟻金服釋出自主研發的分散式中介軟體（Scalable Open Financial Architecture，以下簡稱 SOFA ），並提出金融機構進行業務突破和創新的關鍵是：行業 IT 架構從傳統的集中式架構向分散式架構轉型。

2018 年 4 月，螞蟻金服 SOFA 啟動開源計劃，並開放多個元件，這一系列的動作受到大家的關注和支援，同時，SOFA 社群也日益壯大，除了積極參加開源社群的分享之外，目前已經在杭州、北京、深圳的 Meetup 與大家相見。

2018 年 9 月，杭州螞蟻金服 ATEC（Ant Technology Exploration Conference），SOFA 再次與開發者們相約，聯合支付寶小程式推出《 25 分鐘開發分散式架構的轉賬小程式》的體驗課程，大家可在杭州雲棲小鎮國際會展中心場館 B 場館- ATEC 開發者樂園 CodeLab 來現場動手實踐，時間為 2018/9/19 - 9/22。

場景介紹

一個精簡的轉賬業務，一般會包含幾個部分：

使用者發起轉賬
系統記錄使用者的支出記錄
將資金從 A 使用者轉 B 使用者
返回給使用者“操作成功”提醒，並且定期會給使用者傳送一些日結或者月結的收支賬單

這裡涉及到賬戶、轉賬、賬單三個功能模組。

小程式集中式後臺架構

常見的集中式架構如下圖所示，轉賬涉及的賬戶、轉賬、賬單等功能模組都集中在一個後臺系統中，所有的資料都在同一個資料庫裡面。在業務量不大的情況下，集中式後臺系統設計簡單，部署方便，沒有太多複雜的場景。

但是在大業務量的情況下，集中式架構的缺點也一一體現，例如成本較高、系統容量有限、擴充套件能力受限、程式碼繁重、故障影響面大等等。

小程式分散式後臺架構

在上圖中，可以看到原來集中式的系統已經拆分為多個後臺系統，原來的集中式資料庫也已經拆分為兩個資料庫，原來程式內的系統互動也變成了程式間的系統互動。

分散式後臺架構很好的解決了集中式架構的問題的同時，但是也帶來了一些新的挑戰。

例如：

系統間的同步呼叫、非同步呼叫
分散式資料來源的資料庫訪問
分散式事務

我們來舉個例子，假設轉賬業務的前端是小程式，其完整的流程圖如下：

使用者掃描二維碼進行登入，成功後可以檢視當前的餘額
選取另一個使用者進行轉賬，輸入金額並提交，同時會做限額的校驗
轉賬應用記錄流水明細
轉賬應用呼叫賬號應用，進行兩個賬號餘額增減
轉賬應用傳送成功訊息給使用者

採用以上的方案，可能會面對一些問題，比如：

如何保證轉賬應用跟賬號應用之間的事務一致性？
轉賬的明細庫容量不夠了如何動態水平擴容？
資料如何由單庫遷移到多庫？如何保證訊息傳送的可靠性？等等

這時候，需要一套成熟的中介軟體來為使用者解決分散式架構下的問題。業內有不少不錯的中介軟體產品，比如開源的 Spring Cloud 、SOFAStack 框架等。

今天，我們現場體驗一下「基於 SOFAStack 中介軟體的轉賬小程式」的特別之處

螞蟻金融科技的 SOFAStack 中介軟體從螞蟻內部演變發展而來，經歷了數 10 年金融級業務的發展。

SOFAStack 可以幫忙使用者快速構建健壯的系統：

分散式事務 DTX 可以解決轉賬鏈路上 payment 跟 account 之間跨資源的分散式事務問題，業務程式碼幾乎不用調整；
資料訪問代理 DBP 可以解決 payment 資料庫容量的問題，使用者像使用單庫單表一樣訪問分庫分表的資料訪問代理 DBP 例項，並且可以跟分散式事務 DTX 整合使用；
任務排程及訊息佇列可以解決賬單系統（Bill）複雜的賬單任務以及傳送可靠的賬單訊息、支付成功訊息給使用者。