本文整理自,阿里高級技術專家-許文奇在2019阿里雲峰會上的分享《技術中臺-分佈式架構在螞蟻金服的實踐》。
一、分佈式架構的優勢和理念
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)容災自動切換
閱讀更多 壹號職 的文章