【乾貨】銀行核心體系之分布式微處事

分布式微服務概述

分布式微服務概述

（1）微服務定義

微服務是一種架構風格，將單體應用劃分為一組小的服務，服務之間相互協作，做到業務功能；每個服務運行在獨立的進程中，服務間採用輕量級的通信機制協作（RPC）；每個服務圍繞業務能力進行構建，並且能夠通過自動化機制獨立地部署（CI/CD）；服務可以使用不同的語言進行開發，使用不同的存儲方式。

圖片來源：網路

如上圖，我們需要開發一款簡單的訂單應用，我們將產品、訂單、客戶等所有應用模塊全部打包在一個系統中，它提供了應用所有功能。盡管是模塊化的架構，但應用程序被作為一個整體進行打包和部署，很可能出現一個功能故障影響整個應用、應用模塊越大則單個應用啟用時間越長、代碼功能耦合高不易維護、或代碼資源修改衝突的問題。那麼就引入了微服務….

微服務是基於業務進行拆分的，至於拆分多小沒有一個固定的標準，這點也一直是個爭論的話題。因為服務進行拆分之後，粒度比較細，那麼程序構建和部署方面就會變得簡單。

常見做法是由技術人員對應用模塊的功能挨個進行拆分，包括交易檢查、功能檢查、邏輯判斷等挨個列出清單轉至業務部門，在由業務部門拼接進行開發。就像核心系統中的「樂高」積木，借助簡單的頁面/接口，通過選擇預先設計的業務元素（如密碼檢查、節假日檢查、黑名單客戶檢查）並結合業務需求，靈活、直觀、快速的搭配，構建創新性的金融服務。

所以，與其說微服務是一種系統設計思想，不如說是對原來工程實踐的一種總結和組合。

（2）微服務的主要優缺點

優點：

1.解耦了業務複雜度，服務能夠聚焦一個指定的業務功能或業務需求；

2.強模塊化邊界，對其他服務依賴性弱；

3.可獨立部署，獨立升級，團隊新成員不用很深入別人的代碼也能夠很快投入生產；

4.技術多樣性，能使用不同的語言開發，如Java、Python、PHP、C#等。

缺點：

1.分布式系統複雜性，要考慮網路延遲、異步、序列化、負載等，難以管理；

2.分布式一致性，銀行系統相比互聯網公司，對帳戶資金要求更高；

3.運維複雜性，要保證系統成千上萬的服務有效運轉，成本開銷大；

4.測試複雜性，測試需要啟動和它有關的所有服務。

（3）微服務總體架構體系

圖片來源：網路

總體架構在邏輯上劃分為接入層、網關層、業務服務層、支撐服務層、平台服務層和基礎設施層。

基礎設施層：是系統運行的必要條件，原子交易，經過聚合服務整合後有一整套交易能力。

平台服務層：主要用來保證系統的平穩運行，根據實際業務情況合理分配資源及發布系統。

支撐服務層：實根據業務需要給系統提供高質量的服務，與開放平台的流程管理系統類似。

業務服務層：可以分為聚合服務和基礎服務。聚合服務是不同的基礎服務聚合在一起，完成複雜的業務處理；基礎服務是單一的業務處理。

網關層：網關層是接受外部流量的屏障，用於保證系統的安全和穩定，如黑名單過濾、安全認證等。

接入層：是通過負載均衡接入請求到內部平台。

（4）分布式一致性

數據一致性簡單的說，就是對一個副本數據進行更新的時候，必須確保也能夠更新其他的副本，否則不同副本之間的數據將不一致。舉個例子，比如用戶A向用戶B轉100元，那麼用戶A的帳戶減100元，用戶B的帳戶就一定要增加100元，金額多了或是少了都不對，就出現了數據不一致的情況。

微服務化之前：業務採用本地事務，多個本地SQL調用可以用一個大的事務塊封裝起來，如果某一個數據庫操作發生異常，就可以將之前的SQL操作進行回滾，只有所有SQL操作全部成功，才最終提交，這就保證了事務強一致性。

微服務化之後：多個數據庫操作可能被拆分到多個獨立的數據庫中，此時原來的本地SQL調用演變成了 遠程服務調用，事務一致性無法得到保證。

（5）數據一致性級別

數據一致性級別一般分為三類，強一致性、弱一致性和最終一致性。

·強一致性：也稱為剛性事務，本身就支持ACID，所以不會存在數據不一致的問題。也是最符合用戶直覺的，它要求系統寫入什麼，讀出來的也會是什麼，用戶體驗好，但做到起來往往對系統的性能影響大。比如網銀系統涉及的金融交易，所以交易數據都必須符合核心系統的對帳。

·弱一致性：也稱為柔性事務，與強一致性相反，這種一致性級別約束了系統在寫入成功後，不承諾立即可以讀到寫入的值，也不承諾多久之後數據能夠達到一致，但會盡可能地保證到某個時間級別（比如秒級別）後，數據能夠達到一致狀態。

·最終一致性：是弱一致性的一個特例，系統會保證在一定時間內，能夠達到一個數據一致性。它是弱一致性中非常推崇的一種一致性模型，也是業界在大型分布式系統的數據一致性上比較推崇的模型。在技術上做到難度不高，一般借助異步消息機制做到，基於網路正常且系統交易平穩前提下，可以接近同步效果，客戶體驗也好。

銀行核心系統與互聯網有很大不同，以保證事務一致性為先，而分布式一致性正是微服務架構下一個比較大的弊端。因為直接涉及到客戶帳戶金額的變動，一是客戶不能容忍，二是銀行每秒都有成百上千筆業務，所以一旦出現數據一致性問題，後果不堪設想。

分布式事務常用解決方案

關於分布式事務中的一些基本概念，我們先回顧下。

◇事務：由一組操作構成的可靠、獨立的工作單元。

◇事務的特性ACID

Atomicity（原子性）：事務作為整體來執行，要麼全部執行，要麼全部執行。

Consistency（一致性）：事務應確保數據從一個一致的狀態轉變為另一個一致的狀態。

Isolation（隔離線）：多個事務並發執行時，一個事務的執行不應影響其他事務的執行。

Durability（持久性）：已提交的事務修改數據會被持久保存。

◇本地事務：事務由資源管理器（如RDMS）本地管理。

優點：

1.支持ACID屬性；

2.可靠且高效；

3.狀態可以只在資源管理器中維護；

4.應用編程模型簡單。

缺點:

1.不具備分布式處理能力；

2.隔離的最小單位由資源管理器決定，如單筆記錄。

◇全局事務（DTP模型）-標誌分布式事務

大家應該都聽過兩階段提交，其實兩階段提交是X/Open這個組織發布的DTP模型來定義的一個協議，主要定義規範和API接口，由廠商進行具體的做到。不過一般很少採用兩階段提交做到分布式事務做到。

◇兩階段提交（Two Phase Commit）

圖片來源：網路

準備操作與ACID：

·A：準備後，仍可提交與回滾，主要是確認能否執行提交操作並分配資源、加鎖…

·C：準備時，操作者發送響應，一致性檢查必須ok

·I：準備後，事務結果仍然只在事務內可見

·D：準備後，事務結果已經持久，即準備好提交

缺點：

1.協議成本（長時間資源占用），比如有多個資源管理器，必須等到所有資源管理器準備完成後才統一發起提交；

2.準備階段的持久成本

3.全局事務狀態的持久成本

4.潛在故障點多帶來的脆弱性

5.準備後，提交前的故障引發一些列隔離與恢復難題

◇JavaEE平台中的分布式事務做到

與兩階段提交類似，是針對上層應用做到分布式事務的協議。

◇標準分布式事務解決方案的利弊

優點是嚴格的ACID；

缺點是效率非常低（微服務架構下已不太使用）。

（1）剛性事務

◇CAP定理

一致性（C）

指數據在多個副本之間是否能夠保持一致的特徵。當執行數據更新操作後，仍然可以保證系統數據處於一致的狀態。

可用性（A）

系統提供的服務必須一直處理可用的狀態。對於用戶的每一個操作請求總是能夠在「有限時間內」返回結果。這個有限時間是系統涉及之初就指定好的系統運行指標。返回的結果指的是系統返回用戶的一個正常相應結果，而不是「out ot memory error」之類的系統錯誤信息。

分區容錯性（P）

分布式系統在遇到任何網路分區故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性服務，除非是整個網路環境都發生了故障。組成分布式系統的每個節點的加入與退出都可以看成是一個特殊的網路分區。簡單的說就是：系統部分節點出現故障後，連接正常節點還可以使用系統提供的服務。

CP：放棄可用性，追求一致性和分區容錯性，基本不會選擇，網路問題會直接讓整個系統不可用。

AP：放棄一致性（這里說的一致性是強一致性），追求分區容錯性和可用性，這是很多分布式系統設計時的選擇，例如很多NoSQL系統就是如此。

CA：放棄分區容錯性，加強一致性和可用性，其實就是傳統單機數據庫的選擇。

結論：分布式系統，最重要的是滿足業務需求，而不是追求抽象、決定的系統特性。由於網路分區是分布式應用的基本要素，由此開發者需要在C和A上做出平衡。

◇BASE理論

BASE是基於CAP定義演化而來，是對CAP中一致性和可用性權衡的結果。

BASE就是為了解決關係型數據庫強一致性引起的問題而引發的可用性降低，而提出的解決方案。

BA：Basic Availability 基本業務可用性（支持分區失敗）

S：Soft state 柔性狀態（狀態允許有短時間不同步，異步）

E：Eventual consistency 最終一致性（最終數據是一致的，但不是實時一致）

原子性（A）與持久性（D）必須根本保障

為了可用性、性能的需要，只有降低一致性（C）與隔離性（I）的要求。

（2）柔性事務

圖片來源：網路

柔性事物可以分為四大類，兩階段型、補償性、異步確保型和最大努力通知型。理解這四種類型，有助於在實際業務場景中我們進行分析，哪些場景和業務更適合用哪種分布式事務解決方案。業務活動舉例如下：

圖片來源：網路

由上圖我們可以看到，兩階段型是分布式環境下事務處理的典型模型，比如處理紅包、更新客戶帳、收費處理等；異步確保型主要是異步處理事務，比如核心系統中的熱點帳戶異步記帳、核算分離、虛實帳戶餘額更新等，可以理解為與交易無直接關係，但必須要做的動作；最大努力通知型主要是通知的處理，比如有銀行帳戶動帳簡訊通知、理財產品提前到期通知、商戶通知、對帳文件等。

◇柔性事務中的服務模式

◇TCC操作

TCC是一種業務模型，位於業務服務層而非資源層，沒有單獨的準備階段，Try操作更靈活且業務是可控的，但是開發成本比較高。TCC操作可以分為3個部分，如下：

圖片來源：網路

1.Try：嘗試執行業務

·完成所有業務檢查（一致性）

·預留必須業務資源（準隔離性）

2.Confirm:確認執行任務

·真正執行業務

·不作任何業務檢查

·只使用Try階段預留的業務

·Confirm操作要滿足冪等性

3.Cancel:取消執行業務

·釋放Try階段預留的業務資源

·Cancel操作要滿足冪等性

◇柔性事務解決方案：TCC（兩階段型、補償型）

圖片來源：網路

做到

·一個完整的業務活動由一個主業務服務與若干從業務服務組成

·主業務服務負責發起並完成整個業務活動

·從業務服務提供TCC型業務操作

·業務活動管理器控制業務活動的一致性，它登記業務活動中的操作，並在業務活動提交時確認所有的TCC型操作的confirm操作，在業務活動取消時調用所有TCC型操作的cancel操作

成本

·做到TCC操作的成果

·業務活動結束時confirm或cancel操作的執行成本

·業務活動日志成本

使用範圍

·強隔離性、嚴格一致性要求的業務活動

·適用於執行時間較短的業務（如處理帳戶、收費等業務）

TCC的案例比如銀行轉帳會用到；可靠消息最終一致性（異步確定型），案例可以參考支付寶、eBay；最大努力通知（定期校對），案例可以銀行通知、商戶通知等，目前也還在學習之中，就先說到這里，有機會的話在拿案例做演示。

總的來說，分布式事務常用解決方案分剛性事務和柔性事務。剛性事務一般不適用於微服務場景的，基於CAP定理和BASE理論衍生出柔性事務，柔性事物又分為TCC（典型場景有轉帳）、可靠消息最終一致（可以理解為基於提高性能的前提下，異步處理的交易對本次交易沒有決定性作用的轉異步處理，但必須可靠。案例可以參考支付寶、eBay）、最大努力通知（典型案例有銀行簡訊通知）。

（來自：小貸嘚吧嘚）