分布式事務(wù)是這兩年大家討論比較多的話題，其實(shí)淘寶十多年前就開始使用分布式了。當(dāng)時(shí)的淘寶網(wǎng)系統(tǒng)代碼非常臃腫、業(yè)務(wù)解耦性高、開發(fā)效率低、功能上線周期長，業(yè)務(wù)方不滿、開發(fā)人員不夠就繼續(xù)招人，但新來的人看不懂系統(tǒng)原有邏輯，只好摸索著在“合適的地方”加一些“合適的代碼”，看看運(yùn)行起來像那么回事后，就發(fā)布上線。常常是你改了商品相關(guān)的某些代碼，發(fā)現(xiàn)交易出問題了，甚至你改了論壇上的某些代碼，旺旺出問題了。這讓開發(fā)人員苦不堪言，而業(yè)務(wù)方還認(rèn)為開發(fā)人員辦事不力。

并伴隨著淘寶網(wǎng)訪問量逐步上升，新興功能和業(yè)務(wù)數(shù)據(jù)的不斷增加，服務(wù)器的負(fù)載能力慢慢提高，不得不對(duì)系統(tǒng)進(jìn)行肢解和重構(gòu)，從而開啟了分布式時(shí)代。將用戶信息、交易、商品、評(píng)價(jià)這些模塊拆分成具有不同業(yè)務(wù)特征的系統(tǒng)，從底層開始擴(kuò)容，解決海量商品搜索、下單、支付、系統(tǒng)穩(wěn)定性等問題。有助于每個(gè)系統(tǒng)獨(dú)立部署，業(yè)務(wù)簡單，方便擴(kuò)容；有大量可重用的模塊便于開發(fā)新的業(yè)務(wù)；能夠做到專人專事，讓技術(shù)人員更加專注于某一個(gè)領(lǐng)域......這些情況在銀行核心系統(tǒng)中也不例外。

2016年7月15日銀監(jiān)會(huì)在官網(wǎng)發(fā)布的《中國銀行業(yè)信息科技“十三五”發(fā)展規(guī)劃監(jiān)管指導(dǎo)意見》中也提到要“積極開展云計(jì)算架構(gòu)規(guī)劃，制定云計(jì)算標(biāo)準(zhǔn)，聯(lián)合建立行業(yè)云平臺(tái)，主動(dòng)實(shí)施架構(gòu)轉(zhuǎn)型，穩(wěn)步實(shí)施架構(gòu)遷移，到“十三五”末期，面向互聯(lián)網(wǎng)場景的主要信息系統(tǒng)盡可能遷移至云計(jì)算架構(gòu)平臺(tái)”。加上近年來以阿里為代表的互聯(lián)網(wǎng)企業(yè)提出的“去IOE”，希望打破國外技術(shù)壟斷的局面，以及移動(dòng)互聯(lián)網(wǎng)、大數(shù)據(jù)、云計(jì)算等新興技術(shù)的迅速大致和廣泛應(yīng)用、業(yè)務(wù)量的迅速提升，當(dāng)前IT技術(shù)架構(gòu)面臨極大壓力和風(fēng)險(xiǎn)，在這種背景下，分布式架構(gòu)受到越來越多的關(guān)注，應(yīng)用范圍逐步擴(kuò)大。

1、此文適合人群

銀行從業(yè)人員，IT架構(gòu)師，系統(tǒng)分析師、開發(fā)工程師。

2、此文解決問題

對(duì)新人來說，學(xué)習(xí)完后對(duì)核心系統(tǒng)的分布式微服務(wù)有初步認(rèn)識(shí)，對(duì)架構(gòu)體系有新的理解，有助于擴(kuò)展個(gè)人知識(shí)面；對(duì)職場人來說，銀行業(yè)信息系統(tǒng)采用分布式架構(gòu)是大勢所趨，當(dāng)浪潮來臨，是不是只能all in？在第三部分，或許你能看到小編不一樣的看法。

3、此文分為四大部分

一、分布式微服務(wù)概述

（1）微服務(wù)定義

（2）微服務(wù)的主要優(yōu)缺點(diǎn)

（3）微服務(wù)總體架構(gòu)體系

（4）分布式一致性

（5）數(shù)據(jù)一致性級(jí)別

二、分布式事務(wù)常用解決方案

（1）剛性事務(wù)

（2）柔性事務(wù)

三、沒被掀開的面紗（個(gè)人看法）

四、快來評(píng)論區(qū)討論（三個(gè)問題）

微服務(wù)是一種架構(gòu)風(fēng)格，將單體應(yīng)用劃分為一組小的服務(wù)，服務(wù)之間相互協(xié)作，實(shí)現(xiàn)業(yè)務(wù)功能；每個(gè)服務(wù)運(yùn)行在獨(dú)立的進(jìn)程中，服務(wù)間采用輕量級(jí)的通信機(jī)制協(xié)作（RPC）；每個(gè)服務(wù)圍繞業(yè)務(wù)能力進(jìn)行構(gòu)建，并且能夠通過自動(dòng)化機(jī)制獨(dú)立地部署（CI/CD）；服務(wù)可以使用不同的語言進(jìn)行開發(fā)，使用不同的存儲(chǔ)方式。

如上圖，我們需要開發(fā)一款簡單的訂單應(yīng)用，我們將產(chǎn)品、訂單、客戶等所有應(yīng)用模塊全部打包在一個(gè)系統(tǒng)中，它提供了應(yīng)用所有功能。盡管是模塊化的架構(gòu)，但應(yīng)用程序被作為一個(gè)整體進(jìn)行打包和部署，很可能出現(xiàn)一個(gè)功能故障影響整個(gè)應(yīng)用、應(yīng)用模塊越大則單個(gè)應(yīng)用啟用時(shí)間越長、代碼功能耦合高不易維護(hù)、或代碼資源修改沖突的問題。那么就引入了微服務(wù)....

微服務(wù)是基于業(yè)務(wù)進(jìn)行拆分的，至于拆分多小沒有一個(gè)固定的標(biāo)準(zhǔn)，這點(diǎn)也一直是個(gè)爭論的話題。因?yàn)榉?wù)進(jìn)行拆分之后，粒度比較細(xì)，那么程序構(gòu)建和部署方面就會(huì)變得簡單。

常見做法是由技術(shù)人員對(duì)應(yīng)用模塊的功能挨個(gè)進(jìn)行拆分，包括交易檢查、功能檢查、邏輯判斷等挨個(gè)列出清單轉(zhuǎn)至業(yè)務(wù)部門，在由業(yè)務(wù)部門拼接進(jìn)行開發(fā)。就像核心系統(tǒng)中的“樂高”積木，借助簡單的頁面/接口，通過選擇預(yù)先設(shè)計(jì)的業(yè)務(wù)元素（如密碼檢查、節(jié)假日檢查、黑名單客戶檢查）并結(jié)合業(yè)務(wù)需求，靈活、直觀、快速的搭配，構(gòu)建創(chuàng)新性的金融服務(wù)。

所以，與其說微服務(wù)是一種系統(tǒng)設(shè)計(jì)思想，不如說是對(duì)原來工程實(shí)踐的一種總結(jié)和組合。

RPC（Remote Procedure Call）：指遠(yuǎn)程過程調(diào)用，是一種進(jìn)程間通信方式，是一種技術(shù)思想，而不是規(guī)范，它允許程序調(diào)用另一個(gè)地址空間（通常是共享網(wǎng)絡(luò)的另一臺(tái)機(jī)器上）的過程或函數(shù)。對(duì)程序員來說，無論是調(diào)用本地的還是遠(yuǎn)程的函數(shù)，本質(zhì)上編寫的調(diào)用代碼基本相同。

本地過程調(diào)用&遠(yuǎn)程過程調(diào)用：本地過程調(diào)用就好比你現(xiàn)在在家里，想要掃地，那你直接打開掃地機(jī)器人開關(guān)就可以了；遠(yuǎn)程過程調(diào)用就好比你現(xiàn)在不在家，家里有客人要來，打個(gè)電話叫家人趕緊打掃下衛(wèi)生。

容器：簡單的說，可以理解為每個(gè)運(yùn)行時(shí)的服務(wù)，便于系統(tǒng)對(duì)若干服務(wù)間的管理。

（2）微服務(wù)的主要優(yōu)缺點(diǎn)

1.解耦了業(yè)務(wù)復(fù)雜度，服務(wù)能夠聚焦一個(gè)指定的業(yè)務(wù)功能或業(yè)務(wù)需求；

1.分布式系統(tǒng)復(fù)雜性，要考慮網(wǎng)絡(luò)延遲、異步、序列化、負(fù)載等，難以管理；

2.分布式一致性，銀行系統(tǒng)相比互聯(lián)網(wǎng)公司，對(duì)賬戶資金要求更高；

3.運(yùn)維復(fù)雜性，要保證系統(tǒng)成千上萬的服務(wù)有效運(yùn)轉(zhuǎn)，成本開銷大；

4.測試復(fù)雜性，測試需要啟動(dòng)和它有關(guān)的所有服務(wù)。

（3）微服務(wù)總體架構(gòu)體系

總體架構(gòu)在邏輯上劃分為接入層、網(wǎng)關(guān)層、業(yè)務(wù)服務(wù)層、支撐服務(wù)層、平臺(tái)服務(wù)層和基礎(chǔ)設(shè)施層。

基礎(chǔ)設(shè)施層：是系統(tǒng)運(yùn)行的必要條件，原子交易，經(jīng)過聚合服務(wù)整合后有一整套交易能力。

平臺(tái)服務(wù)層：主要用來保證系統(tǒng)的平穩(wěn)運(yùn)行，根據(jù)實(shí)際業(yè)務(wù)情況合理分配資源及發(fā)布系統(tǒng)。

支撐服務(wù)層：實(shí)根據(jù)業(yè)務(wù)需要給系統(tǒng)提供高質(zhì)量的服務(wù)，與開放平臺(tái)的流程管理系統(tǒng)類似。

業(yè)務(wù)服務(wù)層：可以分為聚合服務(wù)和基礎(chǔ)服務(wù)。聚合服務(wù)是不同的基礎(chǔ)服務(wù)聚合在一起，完成復(fù)雜的業(yè)務(wù)處理；基礎(chǔ)服務(wù)是單一的業(yè)務(wù)處理。

網(wǎng)關(guān)層：網(wǎng)關(guān)層是接受外部流量的屏障，用于保證系統(tǒng)的安全和穩(wěn)定，如黑名單過濾、安全認(rèn)證等。

接入層：是通過負(fù)載均衡接入請(qǐng)求到內(nèi)部平臺(tái)。

（4）分布式一致性

數(shù)據(jù)一致性簡單的說，就是對(duì)一個(gè)副本數(shù)據(jù)進(jìn)行更新的時(shí)候，必須確保也能夠更新其他的副本，否則不同副本之間的數(shù)據(jù)將不一致。舉個(gè)例子，比如用戶A向用戶B轉(zhuǎn)100元，那么用戶A的賬戶減100元，用戶B的賬戶就一定要增加100元，金額多了或是少了都不對(duì)，就出現(xiàn)了數(shù)據(jù)不一致的情況。

微服務(wù)化之前：業(yè)務(wù)采用本地事務(wù)，多個(gè)本地SQL調(diào)用可以用一個(gè)大的事務(wù)塊封裝起來，如果某一個(gè)數(shù)據(jù)庫操作發(fā)生異常，就可以將之前的SQL操作進(jìn)行回滾，只有所有SQL操作全部成功，才最終提交，這就保證了事務(wù)強(qiáng)一致性。

微服務(wù)化之后：多個(gè)數(shù)據(jù)庫操作可能被拆分到多個(gè)獨(dú)立的數(shù)據(jù)庫中，此時(shí)原來的本地SQL調(diào)用演變成了 遠(yuǎn)程服務(wù)調(diào)用，事務(wù)一致性無法得到保證。

（5）數(shù)據(jù)一致性級(jí)別

數(shù)據(jù)一致性級(jí)別一般分為三類，強(qiáng)一致性、弱一致性和最終一致性。

強(qiáng)一致性：也稱為剛性事務(wù)，本身就支持ACID，所以不會(huì)存在數(shù)據(jù)不一致的問題。也是最符合用戶直覺的，它要求系統(tǒng)寫入什么，讀出來的也會(huì)是什么，用戶體驗(yàn)好，但實(shí)現(xiàn)起來往往對(duì)系統(tǒng)的性能影響大。比如網(wǎng)銀系統(tǒng)涉及的金融交易，所以交易數(shù)據(jù)都必須符合核心系統(tǒng)的對(duì)賬。

弱一致性：也稱為柔性事務(wù)，與強(qiáng)一致性相反，這種一致性級(jí)別約束了系統(tǒng)在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數(shù)據(jù)能夠達(dá)到一致，但會(huì)盡可能地保證到某個(gè)時(shí)間級(jí)別（比如秒級(jí)別）后，數(shù)據(jù)能夠達(dá)到一致狀態(tài)。

最終一致性：是弱一致性的一個(gè)特例，系統(tǒng)會(huì)保證在一定時(shí)間內(nèi)，能夠達(dá)到一個(gè)數(shù)據(jù)一致性。它是弱一致性中非常推崇的一種一致性模型，也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型。在技術(shù)上實(shí)現(xiàn)難度不高，一般借助異步消息機(jī)制實(shí)現(xiàn)，基于網(wǎng)絡(luò)正常且系統(tǒng)交易平穩(wěn)前提下，可以接近同步效果，客戶體驗(yàn)也好。

銀行核心系統(tǒng)與互聯(lián)網(wǎng)有很大不同，以保證事務(wù)一致性為先，而分布式一致性正是微服務(wù)架構(gòu)下一個(gè)比較大的弊端。因?yàn)橹苯由婕暗娇蛻糍~戶金額的變動(dòng)，一是客戶不能容忍，二是銀行每秒都有成百上千筆業(yè)務(wù)，所以一旦出現(xiàn)數(shù)據(jù)一致性問題，后果不堪設(shè)想。

兩階段提交（Two Phase Commit）

JavaEE平臺(tái)中的分布式事務(wù)實(shí)現(xiàn)

標(biāo)準(zhǔn)分布式事務(wù)解決方案的利弊

優(yōu)點(diǎn)是嚴(yán)格的ACID；

缺點(diǎn)是效率非常低（微服務(wù)架構(gòu)下已不太使用）。

（1）剛性事務(wù)

CAP定理

一致性（C）

指數(shù)據(jù)在多個(gè)副本之間是否能夠保持一致的特征。當(dāng)執(zhí)行數(shù)據(jù)更新操作后，仍然可以保證系統(tǒng)數(shù)據(jù)處于一致的狀態(tài)。

可用性（A）

系統(tǒng)提供的服務(wù)必須一直處理可用的狀態(tài)。對(duì)于用戶的每一個(gè)操作請(qǐng)求總是能夠在“有限時(shí)間內(nèi)”返回結(jié)果。這個(gè)有限時(shí)間是系統(tǒng)涉及之初就指定好的系統(tǒng)運(yùn)行指標(biāo)。返回的結(jié)果指的是系統(tǒng)返回用戶的一個(gè)正常相應(yīng)結(jié)果，而不是“out ot memory error”之類的系統(tǒng)錯(cuò)誤信息。

分區(qū)容錯(cuò)性（P）

分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然需要能夠保證對(duì)外提供滿足一致性和可用性服務(wù)，除非是整個(gè)網(wǎng)絡(luò)環(huán)境都發(fā)生了故障。組成分布式系統(tǒng)的每個(gè)節(jié)點(diǎn)的加入與退出都可以看成是一個(gè)特殊的網(wǎng)絡(luò)分區(qū)。簡單的說就是：系統(tǒng)部分節(jié)點(diǎn)出現(xiàn)故障后，連接正常節(jié)點(diǎn)還可以使用系統(tǒng)提供的服務(wù)。

CP：放棄可用性，追求一致性和分區(qū)容錯(cuò)性，基本不會(huì)選擇，網(wǎng)絡(luò)問題會(huì)直接讓整個(gè)系統(tǒng)不可用。

AP：放棄一致性（這里說的一致性是強(qiáng)一致性），追求分區(qū)容錯(cuò)性和可用性，這是很多分布式系統(tǒng)設(shè)計(jì)時(shí)的選擇，例如很多NoSQL系統(tǒng)就是如此。

CA：放棄分區(qū)容錯(cuò)性，加強(qiáng)一致性和可用性，其實(shí)就是傳統(tǒng)單機(jī)數(shù)據(jù)庫的選擇。

結(jié)論：分布式系統(tǒng)，最重要的是滿足業(yè)務(wù)需求，而不是追求抽象、決定的系統(tǒng)特性。由于網(wǎng)絡(luò)分區(qū)是分布式應(yīng)用的基本要素，由此開發(fā)者需要在C和A上做出平衡。

BASE理論

BASE是基于CAP定義演化而來，是對(duì)CAP中一致性和可用性權(quán)衡的結(jié)果。

BASE就是為了解決關(guān)系型數(shù)據(jù)庫強(qiáng)一致性引起的問題而引發(fā)的可用性降低，而提出的解決方案。

BA：Basic Availability 基本業(yè)務(wù)可用性（支持分區(qū)失敗）

S：Soft state 柔性狀態(tài)（狀態(tài)允許有短時(shí)間不同步，異步）

E：Eventual consistency 最終一致性（最終數(shù)據(jù)是一致的，但不是實(shí)時(shí)一致）

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

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

（2）柔性事務(wù)

由上圖我們可以看到，兩階段型是分布式環(huán)境下事務(wù)處理的典型模型，比如處理紅包、更新客戶賬、收費(fèi)處理等；異步確保型主要是異步處理事務(wù)，比如核心系統(tǒng)中的熱點(diǎn)賬戶異步記賬、核算分離、虛實(shí)賬戶余額更新等，可以理解為與交易無直接關(guān)系，但必須要做的動(dòng)作；最大努力通知型主要是通知的處理，比如有銀行賬戶動(dòng)賬短信通知、理財(cái)產(chǎn)品提前到期通知、商戶通知、對(duì)賬文件等。

柔性事務(wù)中的服務(wù)模式

TCC操作

TCC是一種業(yè)務(wù)模型，位于業(yè)務(wù)服務(wù)層而非資源層，沒有單獨(dú)的準(zhǔn)備階段，Try操作更靈活且業(yè)務(wù)是可控的，但是開發(fā)成本比較高。TCC操作可以分為3個(gè)部分，如下：

1.Try：嘗試執(zhí)行業(yè)務(wù)

完成所有業(yè)務(wù)檢查（一致性）

預(yù)留必須業(yè)務(wù)資源（準(zhǔn)隔離性）

2.Confirm:確認(rèn)執(zhí)行任務(wù)

真正執(zhí)行業(yè)務(wù)

不作任何業(yè)務(wù)檢查

只使用Try階段預(yù)留的業(yè)務(wù)

Confirm操作要滿足冪等性

3.Cancel:取消執(zhí)行業(yè)務(wù)

釋放Try階段預(yù)留的業(yè)務(wù)資源

Cancel操作要滿足冪等性

柔性事務(wù)解決方案：TCC（兩階段型、補(bǔ)償型）

一個(gè)完整的業(yè)務(wù)活動(dòng)由一個(gè)主業(yè)務(wù)服務(wù)與若干從業(yè)務(wù)服務(wù)組成

主業(yè)務(wù)服務(wù)負(fù)責(zé)發(fā)起并完成整個(gè)業(yè)務(wù)活動(dòng)

從業(yè)務(wù)服務(wù)提供TCC型業(yè)務(wù)操作

業(yè)務(wù)活動(dòng)管理器控制業(yè)務(wù)活動(dòng)的一致性，它登記業(yè)務(wù)活動(dòng)中的操作，并在業(yè)務(wù)活動(dòng)提交時(shí)確認(rèn)所有的TCC型操作的confirm操作，在業(yè)務(wù)活動(dòng)取消時(shí)調(diào)用所有TCC型操作的cancel操作

實(shí)現(xiàn)TCC操作的成果

業(yè)務(wù)活動(dòng)結(jié)束時(shí)confirm或cancel操作的執(zhí)行成本

業(yè)務(wù)活動(dòng)日志成本

強(qiáng)隔離性、嚴(yán)格一致性要求的業(yè)務(wù)活動(dòng)

適用于執(zhí)行時(shí)間較短的業(yè)務(wù)（如處理賬戶、收費(fèi)等業(yè)務(wù)）

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

總的來說，分布式事務(wù)常用解決方案分剛性事務(wù)和柔性事務(wù)。剛性事務(wù)一般不適用于微服務(wù)場景的，基于CAP定理和BASE理論衍生出柔性事務(wù)，柔性事物又分為TCC（典型場景有轉(zhuǎn)賬）、可靠消息最終一致（可以理解為基于提高性能的前提下，異步處理的交易對(duì)本次交易沒有決定性作用的轉(zhuǎn)異步處理，但必須可靠。案例可以參考支付寶、eBay）、最大努力通知（典型案例有銀行短信通知）。實(shí)際場景方案方面業(yè)余時(shí)間在了解中，有機(jī)會(huì)的話在拿案例做演示，就先說到這里。