螞蟻金服的“技術中臺”：億級分布式系統架構實踐
一、分布式架構的優勢和理念
01 傳統單體架構特點
（圖片來源：阿里云峰會）
通常一個初創型項目，都是從單體架構開始的。
優點就是快，易于開發、測試、部署，一個WAR包發上生產就完事了。
缺點也很明顯，因為所有模塊都在一個程序包里，導致編譯慢、啟動慢、代碼沖突，每次合并代碼的時候都是惡夢，發布成功率？完全靠運氣。
02 微服務架構 vs 單體架構
（圖片來源：阿里云峰會）
復雜度較小時采用單體應用生產效率更高，復雜度到了一定規模時單體應用的生產效率開始急劇下降，這時對其進行服務化拆分才是合算的。
微服務架構之所以得到廣泛認可，源于對業務多變性的不可預測，微服架構能夠不斷的自演化 ，進而快速適應業務變化。
03 模塊化開發
（圖片來源：阿里云峰會）
微服務架構，從業務頂層設計開始，按照業務線進行模塊拆分，從表現層、邏輯層、數據層進行獨立的剝離單體應用。很多企業都經歷過單體應用到服務化應用的拆分過程，這里要注意業務的連續性、數據的完整性問題。
04 微服務架構的負載均衡優勢
（圖片來源：阿里云峰會）
以前通常用LVS、F5作為接入層的負載均衡服務，主要提供限流、負載、安全等等。
在微服務架構中，由網關作為接入層，提供輕量級的負載均衡、協議轉換、鑒權等服務，微服務通常有服務治理框架，如DUBBO等，提供服務治理、服務注冊、服務發現、隔離等。
05 數據訪問瓶頸解決方案--數據庫垂直切分
（圖片來源：阿里云峰會）
分布式架構是如何解決數據訪問瓶頸的呢？首先是數據庫的垂直切分，比如，按用戶、交易、賬務拆分到獨立的數據庫當中，緩解了數據存儲和訪問的壓力，當然也可以做主備庫，進行讀寫分離的。
06 數據訪問瓶頸解決方案--數據庫水平切分
（圖片來源：阿里云峰會）
其次，進行數據庫的水平切分，比如交易數據庫和數據表的數據量太大，可以按交易時間進行分表、分庫，拆分表的數量計算方法見上圖。
拆表拆庫是解決數據訪問、存儲問題，但是會給數據查詢帶來很大麻煩，比如跨多表、多庫的復雜查詢場景。解決的辦法很多，通常有：用ES進行復雜查詢，篩用ID再到庫里撈數據（即復雜查詢拆分多次查詢），或用分布式海量數據庫方案，不去做太細粒度的拆分庫表，如下面會提到的OceanBase。
二、分布式架構實踐舉例--分布式TA系統
07 傳統TA系統架構
（圖片來源：阿里云峰會）
傳統TA系統架構，清算串行效率低，無法通過增加機器線性擴展性能，一般使用大事務，出現問題全部回滾。
08 分布式TA系統架構
（圖片來源：阿里云峰會）
分布式TA系統架構，結構更合理，也更復雜。分成了：接入層、業務服務層、SOFAStack層、LAAS、運維工具鏈、治理控制。
接入層：包括協議轉換、訪問控制、文件傳輸、運維工作臺。
業務服務層：即業務核心邏輯服務，如：賬戶、交易、賬單、清算等。
SOFAStack：螞蟻金服的通用服務組件，許多都開源了，包括：微服務框架、分布式事務、任務調度、消息隊列、數據代理、鏈路跟蹤等。
分布式TA系統的需求攻克的技術難題。分布式清算任務如何高效實現？分布式下，加大應用處理出錯可能性，那清算任務如何確保正確性?下面會談談如何解決。
09 分布式任務調度平臺
（圖片來源：阿里云峰會）
分布式任務調度平臺，支持：
自定義分片，高效利用集群計算能力。
執行中可對任務進行暫停/續跑，強制取消。
任務失敗重試機制，保障整體計算任務成功。
10 清算任務調度
（圖片來源：阿里云峰會）
清算任務調度，整個架構分為：1）任務拆分，即申請交易文件，按一定的邏輯進行數據分片；2）任務執行，將執行處理過后的數據，存入流水庫；3）核心服務，包括交易、清算、賬務、賬戶等。
11 清算的容錯和核對機制
（圖片來源：阿里云峰會）
清算的容錯和核對機制，包含：日初始化、文件導入、清算處理、收益計算、份額調整、清算導出、二次清算、收益導出。
每個環節都可以沖正重做。
可以按文件、用戶、備份點進行作業回滾。
優點是，任意流程可回滾、精準逐筆核對，支持按中臺用戶回滾，縮短了清算時長。
三、分布式架構下如何保障系統的可靠性及穩定性
12 灰度發布機制
（圖片來源：阿里云峰會）
灰度發布機制，流程包括：beta發布、分組發布、灰度引流、全量發布。
清算灰度，可以靈活的按用戶維度抽取分片，縮短灰度時間。
13 線上全鏈路壓測
（圖片來源：阿里云峰會）
線上全鏈路壓測，通過數據訪問代理，壓測數據進入線上影子表，不影響正常業務數據，全鏈路壓測特點有：
1、壓測環境復用生產，結果可靠；優于線下。
2、壓測數據打標無法進入生產環境，表級隔離。
14 OceanBase高可用機制
（圖片來源：阿里云峰會）
OceanBase高可用機制，基于Paxos協議的典型三副本部署：
1）數據強一致性；
2）持續可用；
3）主備自動切換；
4）單機、機房、城市級故障：不停服務，不丟數據；
OceanBase分布式數據庫方案，優于商用數據庫的主備庫方案，主要體現在：分布式數據庫，寫事務到達超過半數庫，少數庫異常不影響業務，兩地三中心多活，灰度升級。
15 OceanBase常用部署方案
（圖片來源：阿里云峰會）
OceanBase的部署方案有：
同城三機房，同城多個核心機房，相距30公里以內，延遲約在0.5~2ms之間；
兩地三中心，正常情況下和同城三中心部署的延遲一致，其中一個城市的一臺ObServer 宕機會增加異地同步延遲。
16 同城雙活容災架構
（圖片來源：阿里云峰會）
同城容災雙活架構，平時以主機房為主，承載日常交易，少量交易走備機房，架構特點是：
1）同機房優先，避免跨損耗
2）對應用無任何侵入
3）像單機房一樣開發部署應用
4）容災自動切換
