[[418363]]

【51CTO.com快譯】在微服務(wù)架構(gòu)中，單個服務(wù)內(nèi)的事務(wù)通常使用ACID事務(wù)來提供數(shù)據(jù)一致性。

介紹

本文描述了在微服務(wù)系統(tǒng)中管理分布式和長時間運(yùn)行的事務(wù)的架構(gòu)和概念框架。作者發(fā)表此文旨在與開發(fā)社區(qū)分享經(jīng)驗，表達(dá)對事件驅(qū)動架構(gòu)的熱情，并促進(jìn)對復(fù)雜事件處理分布式系統(tǒng)的討論興趣。

概述

微服務(wù)在其真正的場景中是一個分布式系統(tǒng)。一個事務(wù)被分發(fā)到多個服務(wù)，這些服務(wù)被順序或并行調(diào)用以完成整個事務(wù)。在微服務(wù)架構(gòu)中，單個服務(wù)中的事務(wù)使用ACID事務(wù)來提供數(shù)據(jù)一致性。然而，面臨挑戰(zhàn)在于處理跨多個服務(wù)的事務(wù)，在某些情況下需要很長時間才能完成。在這種情況下，應(yīng)用程序必須使用復(fù)雜的機(jī)制來管理事務(wù)。而ACID是指數(shù)據(jù)庫管理系統(tǒng)(DBMS)在寫入或更新資料的過程中，為保證事務(wù)是正確可靠的，所必須具備的四個特性：原子性、一致性、隔離性、持久性。

設(shè)想

考慮一個使用微服務(wù)架構(gòu)實現(xiàn)的航空公司航班座位預(yù)訂簡單的場景。在這個場景中，一個微服務(wù)來鎖定預(yù)訂座位，另一個微服務(wù)接受付款，還有一個微服務(wù)在付款之后解鎖并分配席位，每個微服務(wù)都實現(xiàn)一個本地事務(wù)。旅客要成功完成航班預(yù)訂流程，必須完成所有三個步驟。如果任何一個步驟失敗，則必須回滾之前完成的所有步驟。由于整體事務(wù)的邊界跨越多個服務(wù)和數(shù)據(jù)庫，因此被認(rèn)為是一個分布式事務(wù)。

考慮通過微服務(wù)方法實現(xiàn)另一個訂單實現(xiàn)場景。工作流事務(wù)從訂單服務(wù)開始，首先創(chuàng)建訂單，隨后采用另一個服務(wù)進(jìn)行付款，接下來為交易創(chuàng)建發(fā)票，然后進(jìn)行發(fā)貨，最后交付訂單并完成工作流，并循環(huán)執(zhí)行每個本地事務(wù)。這里的訂單處理本質(zhì)上是分布式的，完成工作流程可能需要幾天到幾周的時間。這樣的事務(wù)可以稱為長時間運(yùn)行的事務(wù)，因為不能使用傳統(tǒng)的ACID事務(wù)語義一次性執(zhí)行所有步驟。

挑戰(zhàn)

隨著微服務(wù)架構(gòu)的出現(xiàn)，分布式事務(wù)管理存在兩個關(guān)鍵問題：

• 原子性：原子性意味著事務(wù)中的所有步驟都必須獲得成功，或者如果一個步驟失敗，則應(yīng)該回滾之前完成的所有步驟。但是在微服務(wù)架構(gòu)中，一個事務(wù)可以由不同微服務(wù)處理的多個本地事務(wù)組成。因此，如果其中一個本地事務(wù)失敗，那么如何回滾之前成功完成的事務(wù)?
• 隔離性：事務(wù)隔離指定對事務(wù)中的語句可見的數(shù)據(jù)量，特別是當(dāng)多個服務(wù)調(diào)用同時訪問同一數(shù)據(jù)源時。如果來自任何一個微服務(wù)的對象持久地保存在數(shù)據(jù)庫中，而另一個請求同時讀取同一個對象，那么該服務(wù)應(yīng)該提交舊數(shù)據(jù)還是新數(shù)據(jù)?

為了解決這些問題并提供有效的事務(wù)管理能力，可以采取兩種方法：一是兩階段提交(2PC) ;二是Saga。

(1)兩階段提交(2PC)

保持跨多個服務(wù)的數(shù)據(jù)一致性的傳統(tǒng)方法是使用分布式事務(wù)，其事實標(biāo)準(zhǔn)是兩階段提交(2PC)。兩階段提交(2PC) 確保事務(wù)中的所有參與者或者提交或者回滾。它分為兩個階段工作;階段1稱為準(zhǔn)備階段，控制節(jié)點詢問所有參與節(jié)點是否準(zhǔn)備好提交;階段2稱為提交階段，如果所有節(jié)點都回答是肯定的，則控制節(jié)點要求它們提交，否則回滾。

盡管兩階段提交(2PC)可以幫助在分布式系統(tǒng)中提供事務(wù)管理，但它也會成為單點故障，因為事務(wù)的責(zé)任落在了協(xié)調(diào)器上，并且這種協(xié)調(diào)器的典型實現(xiàn)本質(zhì)上是同步的，這會導(dǎo)致減少未來的吞吐量。因此，兩階段提交(2PC)還存在以下不足：

• MongoDB和Cassandra等現(xiàn)代NoSQL數(shù)據(jù)庫不提供支持。
• Apache Kafka等現(xiàn)代消息代理不提供支持。
• 同步IPC降低了可用性。
• 所有參與者都必須在場。

(2)Saga

為了解決在微服務(wù)架構(gòu)中維護(hù)數(shù)據(jù)一致性這一更復(fù)雜的問題，應(yīng)用程序必須使用基于松耦合異步服務(wù)概念的不同機(jī)制。這就是Saga發(fā)揮重要作用的地方。

Saga是一種架構(gòu)模式，它提供了一種優(yōu)雅的方法來實現(xiàn)跨多個服務(wù)的事務(wù)，在本質(zhì)上是異步和反應(yīng)式的。因此，Saga可以定義為事件驅(qū)動的本地事務(wù)序列，其中每個本地事務(wù)更新數(shù)據(jù)庫，并發(fā)布命令或事件以觸發(fā)Saga中的下一個本地事務(wù)。如果本地事務(wù)因為違反業(yè)務(wù)規(guī)則而失敗，那么Saga將執(zhí)行一系列補(bǔ)償事務(wù)，這些補(bǔ)償事務(wù)將撤消先前本地事務(wù)所做的更改。

Saga實現(xiàn)確保執(zhí)行所有事務(wù)或撤消所有更改，從而提供原子性保證。將Saga設(shè)計為狀態(tài)機(jī)模型將提供處理隔離的對策。

Saga模式如何提供幫助

使用微服務(wù)架構(gòu)，單個業(yè)務(wù)流程將多個微服務(wù)聚合在一起以提供整體解決方案。使用微服務(wù)架構(gòu)實現(xiàn)ACID(原子性、一致性、隔離性、持久性)事務(wù)非常困難，并且在某些情況下是不可能的。

例如，在以上提到的航班座位預(yù)訂場景中，具有預(yù)訂座位功能的微服務(wù)無法實現(xiàn)支付數(shù)據(jù)庫的鎖定，因為它在大多數(shù)情況下可能是外部服務(wù)。但是仍然需要某種形式的事務(wù)管理，這種事務(wù)被稱為BASE事務(wù)：基本可用、軟狀態(tài)和最終一致。

必須采取補(bǔ)償措施來恢復(fù)作為事務(wù)一部分發(fā)生的任何事情。以下是Saga如何為航班預(yù)訂座位場景圖：

補(bǔ)償事務(wù)

當(dāng)Saga的一個步驟由于違反業(yè)務(wù)規(guī)則而失敗時，Saga必須通過執(zhí)行補(bǔ)償事務(wù)撤消先前步驟所做的更新。假設(shè)Saga的第(n+1)個交易失敗，則必須撤銷之前n個事務(wù)的影響。

從概念上來說，每個步驟Ti都有一個相應(yīng)的補(bǔ)償事務(wù)Ci，它可以消除Ti的影響。為了消除前n個步驟的影響，Saga必須以相反的順序執(zhí)行每個Ci。如圖所示，其步驟順序為T1…Tn、Cn…C1。

在這一示例中，Tn+1步驟失敗，這需要撤消T1…Tn步驟。Saga以與遠(yuǎn)期事務(wù)相反的順序執(zhí)行補(bǔ)償事務(wù)：Cn…C1。Cis測序的機(jī)制與Tis測序沒有任何區(qū)別。Ci的完成必須觸發(fā)Ci-1的執(zhí)行。

Pivot事務(wù)和Retryable事務(wù)

下表顯示了Saga在航班座位預(yù)訂中每個步驟的補(bǔ)償事務(wù)，其三個步驟被稱為補(bǔ)償事務(wù)，因為它們之后是可能失敗的步驟。在此需要注意的是，并非所有步驟都需要補(bǔ)償事務(wù)。

Saga模式中還有另外兩種事務(wù)類型;一個是Pivot事務(wù)，就像Saga中的一個成功/失敗點。如果Pivot事務(wù)提交，則Saga將一直運(yùn)行到結(jié)束。另一個是Retryable事務(wù)，跟隨Pivot事務(wù)并保證事務(wù)成功。

Saga保證

Saga保證以下兩種結(jié)果之一： Saga中的所有請求或者都成功完成，或者執(zhí)行一部分請求及其補(bǔ)償請求。而請求和補(bǔ)償請求都需要遵循一定的原則：

• 單個事務(wù)可以中止，并且必須是冪等的。
• 補(bǔ)償事務(wù)必須是冪等的、可交換的，并且不能中止(必須無限期重試或在必要時通過人工干預(yù)解決)。

Saga協(xié)調(diào)策略

Saga執(zhí)行協(xié)調(diào)器(SEC)是實現(xiàn)成功的Saga流程的核心組件。Saga協(xié)調(diào)可在以下方面實施：

• 編排(choreography)——在Saga參與者之間分配決策和排序。換句話說，參與者在沒有集中控制點的情況下交換事件，每個本地事務(wù)都會發(fā)布觸發(fā)其他服務(wù)中的本地事務(wù)的域事件。

盡管Saga編排是簡單且可靠的基于事件的通信，但它只能處理簡單用例，并且存在一些限制，這使其無法成為管理分布式事務(wù)的理想選擇。而基于編排的Saga難以理解，經(jīng)常會產(chǎn)生循環(huán)依賴，并且Saga參與者之間存在緊密耦合的風(fēng)險。

• 協(xié)調(diào)(orchestration)——將Saga的協(xié)調(diào)邏輯集中在Saga協(xié)調(diào)器類中。Saga協(xié)調(diào)器向Saga 參與者發(fā)送命令并對事件的結(jié)果采取行動。協(xié)調(diào)器執(zhí)行Saga請求，存儲和解釋每個任務(wù)的狀態(tài)，并通過補(bǔ)償事務(wù)處理故障恢復(fù)?；趨f(xié)調(diào)器的Saga更適合復(fù)雜的事件處理，并使它們成為管理分布式事務(wù)的一種理想選擇。

Saga協(xié)調(diào)器(Saga Orchestrator)

正如Saga“協(xié)調(diào)”模式所暗示的那樣，有一個單獨的協(xié)調(diào)器組件負(fù)責(zé)管理整個流程工作流。在使用編制時可以定義一個協(xié)調(diào)器類，它的唯一職責(zé)是告訴Saga參與者要做什么。Saga協(xié)調(diào)器使用命令/異步回復(fù)式交互與參與者進(jìn)行通信。為了執(zhí)行Saga步驟，它會向參與者發(fā)送命令消息，告訴它要執(zhí)行什么操作。在Saga參與者執(zhí)行操作后，它會向協(xié)調(diào)器發(fā)送回復(fù)消息。然后協(xié)調(diào)器處理這一消息并確定下一步要執(zhí)行的Saga步驟。

上圖顯示了航班座位預(yù)訂采用Saga的基于協(xié)調(diào)器的過程。Saga由Saga協(xié)調(diào)器組件編排，該組件使用異步請求/響應(yīng)調(diào)用Saga參與者。Saga協(xié)調(diào)器跟蹤進(jìn)程并通過命令組件向Saga參與者發(fā)送命令操作，例如座位鎖定服務(wù)(Seat Blocking Service)和付款服務(wù)(Payment Service)，并通過事件處理器從其回復(fù)通道讀取回復(fù)消息，然后確定下一個步驟，采用Saga協(xié)調(diào)器預(yù)訂航班座位的步驟如下：

(1)FrontEnd UI向Saga協(xié)調(diào)器發(fā)送座位預(yù)訂請求。

(2)Saga協(xié)調(diào)器啟動一個新的工作流并向座位鎖定服務(wù)(Seat Blocking Service)發(fā)送一個座位鎖定命令(Seat Blocking Command)。

(3)座位鎖定服務(wù)(Seat Blocking Service)處理命令并回復(fù)一個座位鎖定事件(Seat Blocked Event)。

(4)Saga協(xié)調(diào)器觸發(fā)工作流中的下一個動作，并向付款服務(wù)(Payment Service)發(fā)送付款請求命令(Payment Request Command)。

(5)付款服務(wù)(Payment Service)回復(fù)付款成功事件(Payment Success Event)。

(6)Saga協(xié)調(diào)器然后向座位分配服務(wù)(Seat Allocation Service)發(fā)送一個座位分配命令(Seat Allocation Command)。

(7)座位分配服務(wù)(Seat Allocation Service)回復(fù)一個座位分配事件(Seat Allocated Event)。

(8)Saga協(xié)調(diào)器結(jié)束事務(wù)并完成工作流。

但是，如果座位鎖定服務(wù)、付款服務(wù)或座位分配服務(wù)中任何一個步驟失敗，Saga航班預(yù)訂的場景可能會失敗。為了有效地管理工作流并處理故障，建議將Saga建模為狀態(tài)機(jī)，因為它描述了所有可能的場景，并讓協(xié)調(diào)器確定需要執(zhí)行的操作。

作為狀態(tài)機(jī)的Saga

將Saga協(xié)調(diào)器建模為狀態(tài)機(jī)是一種有效的方式，不僅可以管理分布式事務(wù)，還可以支持長時間運(yùn)行的事務(wù)。狀態(tài)機(jī)由一組狀態(tài)和一組由事件觸發(fā)的狀態(tài)之間的轉(zhuǎn)換組成。每個轉(zhuǎn)換都可以有一個動作，對于Saga來說，它是一個Saga參與者的調(diào)用。

狀態(tài)之間的轉(zhuǎn)換由Saga參與者執(zhí)行的本地事務(wù)的完成觸發(fā)。當(dāng)前狀態(tài)和本地事務(wù)的特定結(jié)果決定了狀態(tài)轉(zhuǎn)換以及要執(zhí)行的操作。因此，使用狀態(tài)機(jī)模型可以更輕松地設(shè)計、實現(xiàn)和測試Sagas。

上圖突出顯示了Saga航班預(yù)訂的狀態(tài)機(jī)模型。該狀態(tài)機(jī)由許多狀態(tài)和轉(zhuǎn)換組成，其中包括以下內(nèi)容：

• 開放訂單(Order Open)——初始狀態(tài)。Saga在工作流開始時設(shè)置這一狀態(tài)。
• 鎖定座位(Blocking Seat)——當(dāng)處于這種狀態(tài)時，Saga正在等待座位鎖定服務(wù)(Seat Blocking Service)來阻止預(yù)訂座位。
• 授權(quán)付款(Authorizing Payment)——Saga正在等待來自付款服務(wù)(Payment Service)的支付授權(quán)命令的回復(fù)。
• 分配座位(Allocating Seat)——在支付成功后等待座位分配服務(wù)(Seat Allocation Service)分配座位。
• 反向付款(Reverse Payment)——如果座位分配失敗，Saga將發(fā)送付款退款請求。
• 解鎖座位(Unblock Seat)——如果支付授權(quán)失敗，Saga將發(fā)送一個失敗事件來解除對座位的封定。
• 訂單完成(Order Completed)——表示Saga成功完成的最終狀態(tài)。
• 訂單被拒絕(Order Rejected)——表示訂單被其中一位參與者拒絕的最終狀態(tài)。

最后，Saga工作流可以重新設(shè)計為Saga狀態(tài)機(jī)。Saga協(xié)調(diào)器鏈接到一個狀態(tài)機(jī)，它負(fù)責(zé)通過狀態(tài)管理器API管理事務(wù)狀態(tài)。除此之外，它還負(fù)責(zé)將事務(wù)狀態(tài)存儲在持久數(shù)據(jù)存儲設(shè)備中，以確保發(fā)生系統(tǒng)故障時的恢復(fù)。

因此，Saga狀態(tài)機(jī)有責(zé)任或者完成所有事務(wù)，或者使系統(tǒng)處于已知狀態(tài)，以便它可以確定可能執(zhí)行下一個動作狀態(tài)或補(bǔ)償活動的順序，無論發(fā)生的事務(wù)是分布的還是長期的。

好處和潛在用例

• 更簡單的依賴關(guān)系——Saga協(xié)調(diào)器調(diào)用Saga參與者，但參與者不調(diào)用協(xié)調(diào)器。因此，協(xié)調(diào)器依賴于參與者，反之則不然，因此不存在循環(huán)依賴關(guān)系。
• 減少耦合——每個服務(wù)都實現(xiàn)了一個由協(xié)調(diào)器調(diào)用的API，因此它不需要知道Saga參與者發(fā)布的事件。
• 關(guān)注點分離——Saga協(xié)調(diào)邏輯在Saga協(xié)調(diào)器中實現(xiàn)本地化。域?qū)ο蟾唵危⑶也恢浪鼈儏⑴c的Saga。
• 數(shù)據(jù)一致性——跨多個微服務(wù)保持?jǐn)?shù)​​據(jù)一致性，無需緊密耦合。
• 開發(fā)人員體驗——設(shè)計允許開發(fā)人員只關(guān)注Saga參與者的業(yè)務(wù)邏輯，并簡化Saga協(xié)調(diào)器上有狀態(tài)工作流的實現(xiàn)。

可以執(zhí)行此類實現(xiàn)的幾個潛在用例：

(1)訂單管理系統(tǒng)

• 電子商務(wù)
• 送餐
• 機(jī)票預(yù)訂
• 酒店/出租車預(yù)訂

(2)結(jié)算交易。

指南和建議

如果組織正在設(shè)計和構(gòu)建編排器驅(qū)動的Saga以支持分布式和長時間運(yùn)行的事務(wù)，則建議遵循以下準(zhǔn)則：

• 協(xié)調(diào)器應(yīng)該只負(fù)責(zé)管理事務(wù)和狀態(tài)，此處不應(yīng)添加任何業(yè)務(wù)邏輯。而業(yè)務(wù)邏輯應(yīng)該在各個服務(wù)參與者中定義。
• 進(jìn)出協(xié)調(diào)器的所有事件和命令都應(yīng)承載事務(wù)數(shù)據(jù)，而不是引用數(shù)據(jù)。
• 使用異步樣式消息在服務(wù)之間進(jìn)行通信。
• 如果使用消息代理(如Kafka)，則實施冪等性和狀態(tài)檢查以提高彈性。
• 適用于在CQRS和Event Sourcing架構(gòu)中設(shè)計命令端(寫入模型)。

原文標(biāo)題：Modeling Saga as a State Machine，作者：Rohit Singh

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】