來源| 阿里云峰會

文| 技術(shù)領(lǐng)導力社區(qū)

本文整理自，阿里高級技術(shù)專家-許文奇在2019阿里云峰會上的分享《技術(shù)中臺-分布式架構(gòu)在螞蟻金服的實踐》，結(jié)合技術(shù)領(lǐng)導力社區(qū)架構(gòu)專家的點評和解讀，全面解析阿里技術(shù)中臺的架構(gòu)實踐。

一、分布式架構(gòu)的優(yōu)勢和理念

01

傳統(tǒng)單體架構(gòu)特點

（本文圖片來源：阿里云峰會 版權(quán)歸作者）

通常一個初創(chuàng)型項目，都是從單體架構(gòu)開始的。

優(yōu)點就是快，易于開發(fā)、測試、部署，一個WAR包發(fā)上生產(chǎn)就完事了。

缺點也很明顯，因為所有模塊都在一個程序包里，導致編譯慢、啟動慢、代碼沖突，每次合并代碼的時候都是惡夢，發(fā)布成功率？完全靠運氣。

02

微服務架構(gòu) vs 單體架構(gòu)

（點擊圖片放大）

復雜度較小時采用單體應用生產(chǎn)效率更高，復雜度到了一定規(guī)模時單體應用的生產(chǎn)效率開始急劇下降，這時對其進行服務化拆分才是合算的。

微服務架構(gòu)之所以得到廣泛認可，源于對業(yè)務多變性的不可預測，微服架構(gòu)能夠不斷的自演化 ，進而快速適應業(yè)務變化。

03

模塊化開發(fā)

微服務架構(gòu)，從業(yè)務頂層設(shè)計開始，按照業(yè)務線進行模塊拆分，從表現(xiàn)層、邏輯層、數(shù)據(jù)層進行獨立的剝離單體應用。很多企業(yè)都經(jīng)歷過單體應用到服務化應用的拆分過程，這里要注意業(yè)務的連續(xù)性、數(shù)據(jù)的完整性問題。

04

微服務架構(gòu)的負載均衡優(yōu)勢

以前通常用LVS、F5作為接入層的負載均衡服務，主要提供限流、負載、安全等等。

在微服務架構(gòu)中，由網(wǎng)關(guān)作為接入層，提供輕量級的負載均衡、協(xié)議轉(zhuǎn)換、鑒權(quán)等服務，微服務通常有服務治理框架，如DUBBO等，提供服務治理、服務注冊、服務發(fā)現(xiàn)、隔離等。

05

數(shù)據(jù)訪問瓶頸解決方案--數(shù)據(jù)庫垂直切分

分布式架構(gòu)是如何解決數(shù)據(jù)訪問瓶頸的呢？首先是數(shù)據(jù)庫的垂直切分，比如，按用戶、交易、賬務拆分到獨立的數(shù)據(jù)庫當中，緩解了數(shù)據(jù)存儲和訪問的壓力，當然也可以做主備庫，進行讀寫分離的。

06

數(shù)據(jù)訪問瓶頸解決方案--數(shù)據(jù)庫水平切分

其次，進行數(shù)據(jù)庫的水平切分，比如交易數(shù)據(jù)庫和數(shù)據(jù)表的數(shù)據(jù)量太大，可以按交易時間進行分表、分庫，拆分表的數(shù)量計算方法見上圖。

拆表拆庫是解決數(shù)據(jù)訪問、存儲問題，但是會給數(shù)據(jù)查詢帶來很大麻煩，比如跨多表、多庫的復雜查詢場景。解決的辦法很多，通常有：用ES進行復雜查詢，篩用ID再到庫里撈數(shù)據(jù)（即復雜查詢拆分多次查詢），或用分布式海量數(shù)據(jù)庫方案，不去做太細粒度的拆分庫表，如下面會提到的OceanBase。

二、分布式架構(gòu)實踐舉例--分布式TA系統(tǒng)

07

傳統(tǒng)TA系統(tǒng)架構(gòu)

傳統(tǒng)TA系統(tǒng)架構(gòu)，清算串行效率低，無法通過增加機器線性擴展性能，一般使用大事務，出現(xiàn)問題全部回滾。

08

分布式TA系統(tǒng)架構(gòu)

分布式TA系統(tǒng)架構(gòu)，結(jié)構(gòu)更合理，也更復雜。分成了：接入層、業(yè)務服務層、SOFAStack層、LAAS、運維工具鏈、治理控制。

接入層：包括協(xié)議轉(zhuǎn)換、訪問控制、文件傳輸、運維工作臺。

業(yè)務服務層：即業(yè)務核心邏輯服務，如：賬戶、交易、賬單、清算等。

SOFAStack：螞蟻金服的通用服務組件，許多都開源了，包括：微服務框架、分布式事務、任務調(diào)度、消息隊列、數(shù)據(jù)代理、鏈路跟蹤等。

分布式TA系統(tǒng)的需求攻克的技術(shù)難題。分布式清算任務如何高效實現(xiàn)？分布式下，加大應用處理出錯可能性，那清算任務如何確保正確性?下面會談談如何解決。

09

分布式任務調(diào)度平臺

分布式任務調(diào)度平臺，支持：

自定義分片，高效利用集群計算能力。

執(zhí)行中可對任務進行暫停/續(xù)跑，強制取消。

任務失敗重試機制，保障整體計算任務成功。

10

清算任務調(diào)度

清算任務調(diào)度，整個架構(gòu)分為：1）任務拆分，即申請交易文件，按一定的邏輯進行數(shù)據(jù)分片；2）任務執(zhí)行，將執(zhí)行處理過后的數(shù)據(jù)，存入流水庫；3）核心服務，包括交易、清算、賬務、賬戶等。

11

清算的容錯和核對機制

清算的容錯和核對機制，包含：日初始化、文件導入、清算處理、收益計算、份額調(diào)整、清算導出、二次清算、收益導出。

每個環(huán)節(jié)都可以沖正重做。

可以按文件、用戶、備份點進行作業(yè)回滾。

優(yōu)點是，任意流程可回滾、精準逐筆核對，支持按中臺用戶回滾，縮短了清算時長。

三、分布式架構(gòu)下如何保障系統(tǒng)的可靠性及穩(wěn)定性

02

灰度發(fā)布機制

灰度發(fā)布機制，流程包括：beta發(fā)布、分組發(fā)布、灰度引流、全量發(fā)布。

清算灰度，可以靈活的按用戶維度抽取分片，縮短灰度時間。

13

線上全鏈路壓測

線上全鏈路壓測，通過數(shù)據(jù)訪問代理，壓測數(shù)據(jù)進入線上影子表，不影響正常業(yè)務數(shù)據(jù)，全鏈路壓測特點有：

1、壓測環(huán)境復用生產(chǎn)，結(jié)果可靠；優(yōu)于線下。

2、壓測數(shù)據(jù)打標無法進入生產(chǎn)環(huán)境，表級隔離。

14

OceanBase高可用機制

OceanBase高可用機制，基于Paxos協(xié)議的典型三副本部署：

1）數(shù)據(jù)強一致性；

2）持續(xù)可用；

3）主備自動切換；

4）單機、機房、城市級故障：不停服務，不丟數(shù)據(jù)；

OceanBase分布式數(shù)據(jù)庫方案，優(yōu)于商用數(shù)據(jù)庫的主備庫方案，主要體現(xiàn)在：分布式數(shù)據(jù)庫，寫事務到達超過半數(shù)庫，少數(shù)庫異常不影響業(yè)務，兩地三中心多活，灰度升級。

15

OceanBase常用部署方案

OceanBase的部署方案有：

同城三機房，同城多個核心機房，相距30公里以內(nèi)，延遲約在0.5~2ms之間；

兩地三中心，正常情況下和同城三中心部署的延遲一致，其中一個城市的一臺ObServer 宕機會增加異地同步延遲。

16

同城雙活容災架構(gòu)

同城容災雙活架構(gòu)，平時以主機房為主，承載日常交易，少量交易走備機房，架構(gòu)特點是：

1）同機房優(yōu)先，避免跨損耗

2）對應用無任何侵入

3）像單機房一樣開發(fā)部署應用

4）容災自動切換

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝