[[388307]]

本文轉(zhuǎn)載自微信公眾號「石杉的架構(gòu)筆記」，作者崔皓。轉(zhuǎn)載本文請聯(lián)系石杉的架構(gòu)筆記公眾號。

開篇

隨著微服務(wù)架構(gòu)的興起，越來越多的公司會在實際場景中遇到分布式事務(wù)的問題。特別是在金融應(yīng)用場景，幾個跨進程的應(yīng)用共同完成一個任務(wù)，就更離不開分布式事務(wù)的參與。而對于分布式事務(wù)而言，2PC、TCC也是經(jīng)常被提到了，不過在面對長業(yè)務(wù)流程，并且很難進行TCC改造的場景，會選擇使用Saga分布式事務(wù)。今天會給大家介紹Saga實現(xiàn)分布式事務(wù)的內(nèi)容：

1. Saga的分布式解決方案
2. Saga處理事務(wù)一致性
3. Saga分布式事務(wù)協(xié)調(diào)
4. Saga的分布式解決方案

隨著互聯(lián)網(wǎng)的快速發(fā)展，原來的單體應(yīng)用已經(jīng)很難支撐大流量高并發(fā)的請求了，因此軟件系統(tǒng)由原來的單體應(yīng)用逐漸向分布式過度，如圖1所示，左邊的Web App 包含了UI和服務(wù)的模塊，在轉(zhuǎn)變以后會對應(yīng)右邊的微服務(wù)架構(gòu)，服務(wù)之間存在關(guān)聯(lián)地相互調(diào)用。

圖1 單體到分布式的系統(tǒng)架構(gòu)過渡

在進行分布式部署之后，會存在多個服務(wù)共同完成一個事務(wù)操作，并且這些服務(wù)彼此都存在于不同的服務(wù)器或者網(wǎng)絡(luò)環(huán)境，服務(wù)之間需要通過網(wǎng)絡(luò)遠(yuǎn)程協(xié)作完成事務(wù)稱之為分布式事務(wù)。例如：銀行轉(zhuǎn)賬業(yè)務(wù)、下單扣件庫存等。

在分布式事務(wù)場景下，如果對數(shù)據(jù)有強一致性要求，會在業(yè)務(wù)層上才去“兩階段提交”(2PC)的方案。

如果保證最終一致性的話可以采取TCC (Try Confirm Cancel)模式。雖然TCC保證最終一致性的模式被業(yè)內(nèi)廣泛使用，但是對于某些分布式事務(wù)場景，流程多、流程長、還可能要調(diào)用其它公司的服務(wù)。特別是對于不可控的服務(wù)(其他公司的服務(wù))，這些服務(wù)無法遵循 TCC 開發(fā)模式，導(dǎo)致TCC模式的開發(fā)成本增高。體現(xiàn)在具體場景中，以金融核心的業(yè)務(wù)為代表(渠道層、產(chǎn)品層、集成層)，其特點是：流程多、流程長、調(diào)用不可控服務(wù)。同時也是應(yīng)為流程長，事務(wù)邊界太長，加鎖時間長，使用TCC模式會影響并發(fā)性能。

鑒于此類業(yè)務(wù)場景的分布式事務(wù)處理，提出了Saga分布式處理模式。Saga是一種“長事務(wù)的解決方案”，更適合于“業(yè)務(wù)流程長、業(yè)務(wù)流程多”的場景。特別是針對參與事務(wù)的服務(wù)是遺留系統(tǒng)服務(wù)，此類服務(wù)無法提供TCC模式下的三個接口，就可以采用Saga模式。

其適用于的業(yè)務(wù)業(yè)務(wù)場景有，金融機構(gòu)對接系統(tǒng)(需要對接外部系統(tǒng))、渠道整合(流程長)、分布式架構(gòu)服務(wù)等。其優(yōu)勢是一階段提交本地事務(wù)，無鎖，高性能;參與者可異步執(zhí)行，高吞吐;補償服務(wù)易于實現(xiàn)，因為一個更新操作的反向操作是比較容易理解的;當(dāng)然其也存在缺點，就是不保證隔離性。

Saga處理事務(wù)一致性

1987年普林斯頓大學(xué)的Hector Garcia-Molina和Kenneth Salem發(fā)表了一篇Paper Sagas，講述的是如何處理long lived transaction(長活事務(wù))。Saga是一個長活事務(wù)可被分解成可以交錯運行的子事務(wù)集合。其中每個子事務(wù)都是一個保持?jǐn)?shù)據(jù)庫一致性的真實事務(wù)。

在這位老兄的論文中提到，每個Saga由一系列sub-transaction Ti組成。每個Ti都有對應(yīng)的補償動作Ci，補償動作用于撤銷Ti造成的結(jié)果。這里可以理解為，針對每一個分布式事務(wù)的每個執(zhí)行操作或者是步驟都是一個 Ti，例如扣減庫存是T1、創(chuàng)建訂單是T2、支付服務(wù)是T3。那么針對每個Ti都對應(yīng)一個補償動作Ci，例如回復(fù)庫存C1、訂單回滾C2、支付回滾C3。

Saga事務(wù)有兩種恢復(fù)策略：

向前恢復(fù)(forward recovery)，也就是“勇往直前”。

對于執(zhí)行不通過的事務(wù)，會嘗試重試事務(wù)，這里有一個假設(shè)就是每個子事務(wù)最終都會成功。這種方式適用于必須要成功的場景，如圖2 所示，上面的圖例，子事務(wù)按照從左到右的順序執(zhí)行，T1執(zhí)行完畢以后T2 執(zhí)行，然后是T3、T4、T5。

圖2 Saga事務(wù)執(zhí)行的策略

事務(wù)恢復(fù)的順序也是按照：T1、T2、T3、T4、T5的方向進行，如果在執(zhí)行T1的時候失敗了就重試T1，以此類推在哪個子事務(wù)執(zhí)行時失敗了就執(zhí)行哪個事務(wù)。因此叫做“勇往直前”。

向后恢復(fù)(backward recovery)，在執(zhí)行事務(wù)失敗時，補償所有已完成的事務(wù)，是“一退到底”的方式。如圖2所示，下面的圖例，子事務(wù)依舊從左往右執(zhí)行，在執(zhí)行到事務(wù)T3的時候，該事務(wù)執(zhí)行失敗了，于是按照紅線的方向開始執(zhí)行補償事務(wù)，先執(zhí)行C3、然后是C2和C1，直到T0、T1、T2的補償事務(wù)C1、C2、C3都執(zhí)行完畢。也就是回滾整個Saga的執(zhí)行結(jié)果。

Saga分布式事務(wù)協(xié)調(diào)

上面介紹了Saga的概念和事務(wù)恢復(fù)方式，每個事務(wù)存在多個子事務(wù)，每個子事務(wù)都有一個補償事務(wù)，其在事務(wù)回滾的時候使用。由于子事務(wù)對應(yīng)的操作在分布式的系統(tǒng)架構(gòu)中會部署在不同的服務(wù)中，這些子事務(wù)為了完成共同的事務(wù)需要進行協(xié)同。

實際上在啟動一個Saga事務(wù)時，協(xié)調(diào)邏輯會告訴第一個Saga參與者，也就是子事務(wù)，去執(zhí)行本地事務(wù)。事務(wù)完成之后Saga的會按照執(zhí)行順序調(diào)用Saga的下一個參與的子事務(wù)。這個過程會一直持續(xù)到Saga事務(wù)執(zhí)行完畢。

如果在執(zhí)行子事務(wù)的過程中遇到子事務(wù)對應(yīng)的本地事務(wù)失敗，則Saga會按照相反的順序執(zhí)行補償事務(wù)。通常來說我們把這種Saga執(zhí)行事務(wù)的順序稱為個Saga的協(xié)調(diào)邏輯。這種協(xié)調(diào)邏輯有兩種模式，編排(Choreography)和控制(Orchestration)分別如下：

編排(Choreography)：參與者(子事務(wù))之間的調(diào)用、分配、決策和排序，通過交換事件進行進行。是一種去中心化的模式，參與者之間通過消息機制進行溝通，通過監(jiān)聽器的方式監(jiān)聽其他參與者發(fā)出的消息，從而執(zhí)行后續(xù)的邏輯處理。由于沒有中間協(xié)調(diào)點，靠參與靠自己進行相互協(xié)調(diào)。

控制(Orchestration)：Saga提供一個控制類，其方便參與者之前的協(xié)調(diào)工作。事務(wù)執(zhí)行的命令從控制類發(fā)起，按照邏輯順序請求Saga的參與者，從參與者那里接受到反饋以后，控制類在發(fā)起向其他參與者的調(diào)用。所有Saga的參與者都圍繞這個控制類進行溝通和協(xié)調(diào)工作。

下面通過一個例子來介紹這兩種協(xié)調(diào)模式，假設(shè)有一個下單的業(yè)務(wù)，從訂單服務(wù)的創(chuàng)建訂單操作發(fā)起，會依次調(diào)用支付服務(wù)中的支付訂單，庫存服務(wù)中的扣減庫存以及發(fā)貨服務(wù)中的發(fā)貨操作，最終如果所有參與者(服務(wù))中的操作(子事務(wù))完成的話，整個下單事務(wù)就算完成。

編排(Choreography)，由于沒有中心的控制類參與參與者操作之間的協(xié)調(diào)工作，因此通過消息發(fā)送的方式進行協(xié)調(diào)。

如圖3所示：

圖3 編排模式-事務(wù)執(zhí)行成功

1. “訂單服務(wù)”中執(zhí)行“創(chuàng)建訂單”操作，此時會發(fā)送一個“創(chuàng)建訂單消息”到隊列中。

2. “支付服務(wù)”監(jiān)聽到隊列中的這個訂單消息，調(diào)用“支付訂單”的操作，同時也發(fā)送“只服務(wù)消息”到隊列中。

3. “庫存服務(wù)”在監(jiān)聽到“支付消息”之后會進行“扣減庫存”的處理，并且發(fā)送“扣減庫存消息”等待下一個消費者接受。

4. “發(fā)貨服務(wù)”作為整個事務(wù)的最后一個子事務(wù)，在接到“扣減庫存消息”以后會執(zhí)行發(fā)貨的子事務(wù)，完成事務(wù)以后會給“訂單服務(wù)”發(fā)送“發(fā)貨消息”，訂單服務(wù)在接受到消息以后完成整個事務(wù)閉環(huán)，并且提交。

上面說的是事務(wù)執(zhí)行成功的情況，如果事務(wù)執(zhí)行失敗那應(yīng)該如何處理?

如圖4所示：

圖4 編排模式-事務(wù)執(zhí)行失敗

1. 假設(shè)在執(zhí)行“發(fā)貨”時子事務(wù)失敗了，會發(fā)送“發(fā)貨失敗消息”。

2. 庫存服務(wù)在接受到“發(fā)貨失敗消息”之后會執(zhí)行“回滾庫存”的操作，該操作將原來扣減的庫存加回去，同時發(fā)送“扣減失敗消息”。

3. “支付服務(wù)”在接受到“扣減失敗消息”之后會執(zhí)行“回滾支付”，進行退款的操作，同時發(fā)送“支付失敗消息”。訂單服務(wù)在接受到該消息以后將下單事務(wù)標(biāo)記為失敗。

從上面的描述可以看出編排的好處：

簡單：每個子事務(wù)進行操作時只用發(fā)布事件消息，其他子事務(wù)監(jiān)聽處理。

松耦合：參與者(服務(wù))之間通過訂閱事件進行溝通，組合會更加靈活。

當(dāng)然也有一些缺點：

理解困難：沒有對業(yè)務(wù)流程進行完整的描述，要了解整個事務(wù)的執(zhí)行過程需要通過閱讀代碼完成。增加開發(fā)人員理解和維護代碼的難度。

存在服務(wù)的循環(huán)依賴：由于通過消息和事件進行溝通，參與者之間會存在循環(huán)依賴的情況。也就是A服務(wù)調(diào)用B服務(wù)，B服務(wù)又調(diào)用A服務(wù)的情況。這也增加了架構(gòu)設(shè)計的復(fù)雜度，在設(shè)計初期需要認(rèn)真考慮。

緊耦合風(fēng)險：每個參與者執(zhí)行的方法都依賴于上一步參與者發(fā)出的消息，但是上一步的參與者的所有消息都需要被訂閱，才能了解參與者的真實狀態(tài)，無形中增加了兩個服務(wù)的耦合度。

控制(Orchestration)，其核心是定義一個控制類，它會告訴參與者(服務(wù))應(yīng)該執(zhí)行哪些操作(子事務(wù))。 Saga控制類通過命令以及異步回復(fù)的方式與參與者進行交互。

如圖5所示：

圖5 控制模式-成功

1. 訂單服務(wù)執(zhí)行下單事務(wù)時，向Saga協(xié)調(diào)器發(fā)送請求命令，Saga協(xié)調(diào)器接受到命令以后按照子事務(wù)執(zhí)行的順序調(diào)用服務(wù)中的方法。

2. 最開始執(zhí)行“支付訂單”的操作，調(diào)用“支付服務(wù)”中的“支付訂單”操作，并且通過虛線的部分返回執(zhí)行結(jié)果“支付完成”。

3. 接下來，執(zhí)行“庫存服務(wù)”中的“扣減庫存”方法，同樣通過虛線部分返回扣減完成的消息給“請求反饋“模塊。

4. 緊接著就是執(zhí)行“發(fā)貨“命令，調(diào)用”發(fā)貨服務(wù)“中的”發(fā)貨“方法，并且返回”發(fā)貨完成“的響應(yīng)。

5. 最后，三個子事務(wù)都執(zhí)行完畢以后，返回訂單服務(wù)，完成整個分布式事務(wù)。

介紹完成成功完成事務(wù)之后，再來看看出現(xiàn)異常的情況。

如圖6所示：

圖6 控制模式-失敗

1. 在執(zhí)行“發(fā)貨”命令時發(fā)現(xiàn)“發(fā)貨失敗”，于是“發(fā)貨服務(wù)”反饋給Saga協(xié)調(diào)器。

2. 此時協(xié)調(diào)器調(diào)用“庫存服務(wù)”中的“回滾庫存”操作，將扣減的庫存恢復(fù)。

3. 然后調(diào)用“支付服務(wù)”中的“回滾支付”完成支付退款的工作。

4. 最后，通知訂單服務(wù)事務(wù)處理失敗。

需要指出的是控制模式也是基于事件驅(qū)動的，與編排模式一樣會發(fā)送消息通知參與者執(zhí)行命令，上面兩個圖中命令的執(zhí)行和調(diào)用也是通過消息的方式進行。

控制器設(shè)計的優(yōu)點：

避免循環(huán)依賴：在編排模式中存在參與者之間的循環(huán)調(diào)用，而中心控制類的方式可以避免這種情況的發(fā)生。

降低復(fù)雜性：所有事務(wù)交給控制器完成，它負(fù)責(zé)命令的執(zhí)行和回復(fù)的處理，參與者只需要完成自身的任務(wù)，不用考慮處理消息的方式，降低參與者接入的復(fù)雜性。

容易測試：測試工作集中在集中控制類上，其他服務(wù)單獨測試功能即可。

容易擴展：如果事務(wù)需要添加新步驟，只需修改控制類，保持事務(wù)復(fù)雜性保持線性，回滾更容易管理。

當(dāng)然這種方法也存在缺點：

依賴控制器：控制器中集中太多邏輯的風(fēng)險。

增加管理難度：這種模式除了管理各個業(yè)務(wù)服務(wù)以外，還需要額外管理控制類服務(wù)，無形中增加了管理的難度和復(fù)雜度。而且存在單點風(fēng)險，一旦控制器出現(xiàn)問題，整個業(yè)務(wù)就處于癱瘓中。

總結(jié) 

這里對Saga進行一個總結(jié)，首先Saga是針對分布式長活事務(wù)的解決方案，針對事務(wù)長、多、復(fù)雜的情況，特別是服務(wù)由多個公司開發(fā)具有不可控性，可以使用Saga模式進行分布式事務(wù)的處理。Saga在處理事務(wù)一致性方面采取了向前恢復(fù)和向后恢復(fù)策略，前者通過不斷重試的方式保證事務(wù)完成，而后者通過子事務(wù)的補償事務(wù)，逐一回滾的方式讓事務(wù)標(biāo)記失敗。在分布式協(xié)調(diào)方面，Saga采用了兩種模式：編排和控制。前者讓參與者(服務(wù))之間通過消息進行溝通，根據(jù)事件出發(fā)事務(wù)的執(zhí)行流程，是一種去中心化的模式。后者通過中心控制類，處理事務(wù)的執(zhí)行和回滾步驟，統(tǒng)一調(diào)用服務(wù)和接受服務(wù)的反饋。