此系列文章共分為三篇，第一篇介紹概念和相關(guān)模式，第二篇和第三篇針對(duì)第一篇給出的三種模式分別介紹實(shí)現(xiàn)方法和需要注意的問題，敬請(qǐng)關(guān)注此公眾號(hào)。

轉(zhuǎn)載本文需注明出處：EAII企業(yè)架構(gòu)創(chuàng)新研究院，違者必究。如需加入微信群參與微服務(wù)架構(gòu)下的數(shù)據(jù)一致性保證（二）、（三）微課堂直播請(qǐng)直接回復(fù)此公眾號(hào)：“加群 姓名 公司 職位 微信號(hào)”。

大家好，今天我給大家分享的題目是微服務(wù)架構(gòu)下的數(shù)據(jù)一致性保證。

今天分享第一篇，主要內(nèi)容包括：

1.傳統(tǒng)使用本地事務(wù)和分布式事務(wù)保證一致性。

2.傳統(tǒng)分布式事務(wù)不是微服務(wù)中一致性的最佳選擇。

3.微服務(wù)架構(gòu)中應(yīng)滿足數(shù)據(jù)最終一致性原則。

4.微服務(wù)架構(gòu)實(shí)現(xiàn)最終一致性的三種模式。

5.對(duì)賬是最后的終極防線。

一、傳統(tǒng)使用本地事務(wù)和分布式事務(wù)保證一致性

傳統(tǒng)單機(jī)應(yīng)用一般都會(huì)使用一個(gè)關(guān)系型數(shù)據(jù)庫(kù)，好處是應(yīng)用可以使用 ACID transactions。為保證一致性我們只需要：開始一個(gè)事務(wù)，改變（插入，刪除，更新）很多行，然后提交事務(wù)（如果有異常時(shí)回滾事務(wù)）。更進(jìn)一步，借助開發(fā)平臺(tái)中的數(shù)據(jù)訪問技術(shù)和框架（如Spring），我們需要做的事情更少，只需要關(guān)注數(shù)據(jù)本身的改變。

隨著組織規(guī)模不斷擴(kuò)大，業(yè)務(wù)量不斷增長(zhǎng)，單機(jī)應(yīng)用和數(shù)據(jù)庫(kù)已經(jīng)不足以支持龐大的業(yè)務(wù)量和數(shù)據(jù)量，這個(gè)時(shí)候需要對(duì)應(yīng)用和數(shù)據(jù)庫(kù)進(jìn)行拆分，就出現(xiàn)了一個(gè)應(yīng)用需要同時(shí)訪問兩個(gè)或兩個(gè)以上的數(shù)據(jù)庫(kù)情況。開始我們用分布式事務(wù)來(lái)保證一致性，也就是我們常說(shuō)的兩階段提交協(xié)議（2PC）。

本地事務(wù)和分布式事務(wù)現(xiàn)在已經(jīng)非常成熟，相關(guān)介紹很豐富，此處不多作討論。

二、傳統(tǒng)分布式事務(wù)不是微服務(wù)中一致性的最佳選擇

首先，對(duì)于微服務(wù)架構(gòu)來(lái)說(shuō)，數(shù)據(jù)訪問變得更加復(fù)雜，這是因?yàn)閿?shù)據(jù)都是微服務(wù)私有的，唯一可訪問的方式就是通過API。這種打包數(shù)據(jù)訪問方式使得微服務(wù)之間松耦合，并且彼此之間獨(dú)立非常容易進(jìn)行性能擴(kuò)展。

其次，不同的微服務(wù)經(jīng)常使用不同的數(shù)據(jù)庫(kù)。應(yīng)用會(huì)產(chǎn)生各種不同類型的數(shù)據(jù)，關(guān)系型數(shù)據(jù)庫(kù)并不一定是最佳選擇。

例如，某個(gè)產(chǎn)生和查詢字符串的應(yīng)用采用Elasticsearch的字符搜索引擎；某個(gè)產(chǎn)生社交圖片數(shù)據(jù)的應(yīng)用可以采用圖數(shù)據(jù)庫(kù)，例如，Neo4j；

基于微服務(wù)的應(yīng)用一般都使用SQL和NoSQL結(jié)合的模式。但是這些非關(guān)系型數(shù)據(jù)大多數(shù)并不支持2PC。

可見在微服務(wù)架構(gòu)中已經(jīng)不能選擇分布式事務(wù)了。

三、微服務(wù)架構(gòu)中應(yīng)滿足數(shù)據(jù)最終一致性原則

依據(jù)CAP理論，必須在可用性（availability）和一致性（consistency）之間做出選擇。如果選擇提供一致性需要付出在滿足一致性之前阻塞其他并發(fā)訪問的代價(jià)。這可能持續(xù)一個(gè)不確定的時(shí)間，尤其是在系統(tǒng)已經(jīng)表現(xiàn)出高延遲時(shí)或者網(wǎng)絡(luò)故障導(dǎo)致失去連接時(shí)。

依據(jù)目前的成功經(jīng)驗(yàn)，可用性一般是更好的選擇，但是在服務(wù)和數(shù)據(jù)庫(kù)之間維護(hù)數(shù)據(jù)一致性是非常根本的需求，微服務(wù)架構(gòu)中選擇滿足最終一致性。

當(dāng)然選擇了最終一致性，就要保證到最終的這段時(shí)間要在用戶可接受的范圍之內(nèi)。

那么我們?cè)趺磳?shí)現(xiàn)最終一致性呢？

四、微服務(wù)架構(gòu)實(shí)現(xiàn)最終一致性的三種模式

從一致性的本質(zhì)來(lái)看，是要保證在一個(gè)業(yè)務(wù)邏輯中包含的服務(wù)要么都成功，要么都失敗。那我們?cè)趺催x擇方向呢？保證成功還是保證失敗呢？

我們說(shuō)業(yè)務(wù)模式?jīng)Q定了我們的選擇。實(shí)現(xiàn)最終一致性有三種模式：可靠事件模式、業(yè)務(wù)補(bǔ)償模式、TCC模式。

1) 可靠事件模式

可靠事件模式屬于事件驅(qū)動(dòng)架構(gòu)，當(dāng)某件重要事情發(fā)生時(shí)，例如更新一個(gè)業(yè)務(wù)實(shí)體，微服務(wù)會(huì)向消息代理發(fā)布一個(gè)事件。消息代理會(huì)向訂閱事件的微服務(wù)推送事件，當(dāng)訂閱這些事件的微服務(wù)接收此事件時(shí)，就可以完成自己的業(yè)務(wù)，也可能會(huì)引發(fā)更多的事件發(fā)布。

1. 如訂單服務(wù)創(chuàng)建一個(gè)待支付的訂單，發(fā)布一個(gè)“創(chuàng)建訂單”的事件。

2.支付服務(wù)消費(fèi)“創(chuàng)建訂單”事件，支付完成后發(fā)布一個(gè)“支付完成”事件。

3.訂單服務(wù)消費(fèi)“支付完成”事件，訂單狀態(tài)更新為待出庫(kù)。

從而就實(shí)現(xiàn)了完成的業(yè)務(wù)流程。

這個(gè)過程可能導(dǎo)致出現(xiàn)不一致的地方在于：某個(gè)微服務(wù)在更新了業(yè)務(wù)實(shí)體后發(fā)布事件卻失?。浑m然微服務(wù)發(fā)布事件成功，但是消息代理未能正確推送事件到訂閱的微服務(wù)；接受事件的微服務(wù)重復(fù)消費(fèi)了事件。

可靠事件模式在于保證可靠事件投遞和避免重復(fù)消費(fèi)，可靠事件投遞定義為（a）每個(gè)服務(wù)原子性的業(yè)務(wù)操作和發(fā)布事件（b）消息代理確保事件傳遞至少一次。

避免重復(fù)消費(fèi)要求服務(wù)實(shí)現(xiàn)冪等性，如支付服務(wù)不能因?yàn)橹貜?fù)收到事件而多次支付。

2) 補(bǔ)償模式

為了描述方便，這里先定義兩個(gè)概念：

業(yè)務(wù)異常：業(yè)務(wù)邏輯產(chǎn)生錯(cuò)誤的情況，比如賬戶余額不足、商品庫(kù)存不足等。

技術(shù)異常：非業(yè)務(wù)邏輯產(chǎn)生的異常，如網(wǎng)絡(luò)連接異常、網(wǎng)絡(luò)超時(shí)等。

補(bǔ)償模式使用一個(gè)額外的協(xié)調(diào)服務(wù)來(lái)協(xié)調(diào)各個(gè)需要保證一致性的微服務(wù)，協(xié)調(diào)服務(wù)按順序調(diào)用各個(gè)微服務(wù)，如果某個(gè)微服務(wù)調(diào)用異常（包括業(yè)務(wù)異常和技術(shù)異常）就取消之前所有已經(jīng)調(diào)用成功的微服務(wù)。

補(bǔ)償模式建議僅用于不能避免出現(xiàn)業(yè)務(wù)異常的情況，如果有可能應(yīng)該優(yōu)化業(yè)務(wù)模式，以避免要求補(bǔ)償事務(wù)。如賬戶余額不足的業(yè)務(wù)異?？赏ㄟ^預(yù)先凍結(jié)金額的方式避免，商品庫(kù)存不足可要求商家準(zhǔn)備額外的庫(kù)存等。

我們通過一個(gè)實(shí)例來(lái)說(shuō)明補(bǔ)償模式，一家旅行公司提供預(yù)訂行程的業(yè)務(wù)，可以通過公司的網(wǎng)站提前預(yù)訂飛機(jī)票、火車票、酒店等。

假設(shè)一位客戶規(guī)劃的行程是，（1）上海-北京6月19日9點(diǎn)的某某航班，（2）某某酒店住宿3晚，（3）北京-上海6月22日17點(diǎn)火車。在客戶提交行程后，旅行公司的預(yù)訂行程業(yè)務(wù)按順序串行的調(diào)用航班預(yù)訂服務(wù)、酒店預(yù)訂服務(wù)、火車預(yù)訂服務(wù)。最后的火車預(yù)訂服務(wù)成功后整個(gè)預(yù)訂業(yè)務(wù)才算完成。

如果火車票預(yù)訂服務(wù)沒有調(diào)用成功，那么之前預(yù)訂的航班、酒店都得取消。取消之前預(yù)訂的酒店、航班即為補(bǔ)償過程。

需要注意的是酒店的取消預(yù)訂、航班的取消預(yù)訂同樣不能保證一定成功，所以補(bǔ)償過程往往也同樣需要實(shí)現(xiàn)最終一致性，需要保證取消服務(wù)至少被調(diào)用一次和取消服務(wù)必須實(shí)現(xiàn)冪等性。

我們應(yīng)該盡可能通過設(shè)計(jì)避免采用補(bǔ)償方式，比如上面的例子中，在預(yù)訂火車票失敗的時(shí)候可以提示客戶更改其他的時(shí)間。

 3) TCC模式（Try-Confirm-Cancel）

一個(gè)完整的TCC業(yè)務(wù)由一個(gè)主業(yè)務(wù)服務(wù)和若干個(gè)從業(yè)務(wù)服務(wù)組成，主業(yè)務(wù)服務(wù)發(fā)起并完成整個(gè)業(yè)務(wù)活動(dòng)，TCC模式要求從服務(wù)提供三個(gè)接口：Try、Confirm、Cancel。

第一階段：主業(yè)務(wù)服務(wù)分別調(diào)用所有從業(yè)務(wù)的try操作，并在活動(dòng)管理器中登記所有從業(yè)務(wù)服務(wù)。當(dāng)所有從業(yè)務(wù)服務(wù)的try操作都調(diào)用成功或者某個(gè)從業(yè)務(wù)服務(wù)的try操作失敗，進(jìn)入第二階段。

第二階段：活動(dòng)管理器根據(jù)第一階段的執(zhí)行結(jié)果來(lái)執(zhí)行confirm或cancel操作。如果第一階段所有try操作都成功，則活動(dòng)管理器調(diào)用所有從業(yè)務(wù)活動(dòng)的confirm操作。否則調(diào)用所有從業(yè)務(wù)服務(wù)的cancel操作。

需要注意的是第二階段confirm或cancel操作本身也是滿足最終一致性的過程，在調(diào)用confirm或cancel的時(shí)候也可能因?yàn)槟撤N原因（比如網(wǎng)絡(luò)）導(dǎo)致調(diào)用失敗，所以需要活動(dòng)管理支持重試的能力，同時(shí)這也就要求confirm和cancel操作具有冪等性。

五、對(duì)賬是最后的終極防線

如果有些業(yè)務(wù)由于瞬時(shí)的網(wǎng)絡(luò)故障或調(diào)用超時(shí)等問題，通過上文所講的3種模式一般都能得到很好的解決。但是在當(dāng)今云計(jì)算環(huán)境下，很多服務(wù)是依賴于外部系統(tǒng)的可用性情況，在一些重要的業(yè)務(wù)場(chǎng)景下還需要周期性的對(duì)賬來(lái)保證真實(shí)的一致性。比如支付系統(tǒng)和銀行之間每天日終是都會(huì)有對(duì)賬過程。

以上就是今天分享的內(nèi)容，主要介紹的是微服務(wù)架構(gòu)中需要滿足最終一致性原則以及實(shí)現(xiàn)最終一致性的3種模式。關(guān)于每種模式的實(shí)現(xiàn)方法以及可能遇到的問題會(huì)在今后逐步和大家分享。

謝謝大家！