2．分布式事務解決方案：servicecomb-pack

補償方式

在講servicecomb-pack之前先了解兩個概念： 不完美補償（saga）和完美補償（tcc）。

1．saga：不完美補償，一般在系統中我們會專門為業務邏輯對應寫一個補償邏輯，如果業務邏輯執行失敗，就會去執行這個補償邏輯，我們稱這個補償邏輯為反向操作，這個反向操作同樣會留下操作痕跡，例如：在銀行系統中，客戶去ATM取錢，銀行會先對用戶賬戶進行扣款操作，如果本次取錢不成功，銀行系統會發出一筆沖正操作，將之前扣除的款項打回用戶賬戶，這個沖正操作在交易記錄里面是開源查詢到的。

2．tcc：完美補償，cancel階段會徹底清楚之前的業務邏輯操作，用戶是感知不到的。例如：在一個交易平臺去發起交易，首先在try階段不會直接去扣除賬戶余額，而且去檢查用戶的額度并刷新額度，然后在confirm階段才去真正操作賬戶。如果出現異常，那么在cancel階段就需要去執行業務邏輯來取消try階段產生的后果，釋放在try階段被占用的額度。整個過程只有等confirm執行完畢，交易才算完成。

servicecomb-pack

servicecomb-pack出自于華為微服務框架servicecomb，是一個開源的分布式事務最終一致性解決方案，該項目已交由Apache軟件基金會孵化，目前已經在apache畢業了。0.3.0版本之前叫servicecomb-saga，現版本已經改名為servicecomb-pack。

servicecomb-pack架構主要包含兩個組件：alpha和Omega；

? lalpha：alpha其實就是一個server端，需要用戶自行編譯運行，它的作用就是上述中的分布式事務協調器，主要作用是和Omega客戶端進行通訊，接收omega發過來的事務事件，然后進行持久化存儲事務以及修改協調子事務的狀態，從而保證全局事務中的所有子事務狀態都一致，即要么全執行完成，要么全執行失敗。

? lomega：Omega端其實可以看成是一個微服務中內嵌的agent，主要作用是監控本地子事務的執行情況并向alpha-server端發送子事務執行事件以及傳遞全局事務ID，并在異常情況下會根據alpha下發的操作事件進行相應的補償操作。

從上圖中我們大致可以了解整個servicecomb-pack是如何運轉的，但是有一個疑問點，alpha-server端是怎么知道多個Omega發送過來的子事務是屬于同一個全局事務的呢？其實在分布式事務開始點會生成一個全局事務ID，然后在調用子事務所處的服務時，會把這個全局事務ID傳遞給子事務，然后alpha端會會把這個全局事務ID和Omega傳遞過來的子事務事件綁定并持久化到數據庫中，這樣就會形成一個完整的事務調用鏈，我們通過這個全局事務ID就可以完整的追蹤到整個分布式事務的執行情況。

Omega會以切面編程的方式向應用程序注入相關的處理模塊，幫助我們構建分布式事務調用的上下文。 Omega在事務處理初始階段處理事務的相關準備的操作，在事務執行完畢做一些清理的操作，例如創建分布式事務起始事件，以及相關的子事件，根據事務的執行的成功或者失敗生產相關的事務終止或者失敗事件。這樣帶來的好處是用戶的代碼只需要添加幾個annotation來描述分布式事務執行范圍，以及與本地的事務處理恢復的相關函數信息，Omega就能通過切面注入的代碼能夠追蹤與本地事務的執行情況。 Omega會將本地事務執行的情況以事件的方式通知給Alpha。 由于單個Omega不可能知曉一個分布式事務下其他參與服務的執行情況，這樣就需要Alpha扮演一個十分重要的協調者的角色。Alpha將收集到的分布式事務事件信息整理匯總，通過分析這些事件之間的關系可以了解到分布式事務的執行情況，Alpha通過向Omega下發相關的執行指令由Omega執行相關提交或恢復操作，實現分布式事務的最終一致性。

在了解的Pack實現的部分細節之后，我們可以從下圖進一步了解ServiceComb Pack架構下，Alpha與Omega內部各模塊之間的關系圖。^[i]

整個架構分為三個部分，一個是Alpha協調器，另外一個就是注入到微服務實例中的Omega，以及Alpha與Omega之間的交互協議，目前ServiceComb Pack支持Saga以及TCC兩種分布式事務協調協議實現。

Omega包含了與分析用戶分布式事務邏輯相關的 事務注解模塊（Transaction Annotation） 以及 事務攔截器（Transaction Interceptor）； 分布式事務執行相關的事務上下文（Transaction Context），事務回調（Transaction Callback） ，事務執行器（Transaction Executor）；以及負責與Alpha進行通訊的事務傳輸（Transaction Transport）模塊。

? 事務注解模塊是分布式事務的用戶界面，用戶將這些標注添加到自己的業務代碼之上用以描述與分布式事務相關的信息，這樣Omega就可以按照分布式事務的協調要求進行相關的處理。如果大家擴展自己的分布式事務，也可以通過定義自己的事務標注來實現。

? 事務攔截器這個模塊我們可以借助AOP手段，在用戶標注的代碼基礎上添加相關的攔截代碼，獲取到與分布式事務以及本地事務執行相關的信息，并借助事務傳輸模塊與Alpha進行通訊傳遞事件。

? 事務上下文為Omega內部提供了一個傳遞事務調用信息的一個手段，借助前面提到的全局事務ID以及本地事務ID的對應關系，Alpha可以很容易檢索到與一個分布式事務相關的所有本地事務事件信息。

? 事務執行器主要是為了處理事務調用超時設計的模塊。由于Alpha與Omega之間的連接有可能不可靠，Alpha端很難判斷Omega本地事務執行超時是由Alpha與Omega直接的網絡引起的還是Omega自身調用的問題，因此設計了事務執行器來監控Omega的本地的執行情況，簡化Omega的超時操作。目前Omega的缺省實現是直接調用事務方法，由Alpha的后臺服務通過掃描事件表的方式來確定事務執行時間是否超時。

? 事務回調在Omega與Alpha建立連接的時候就會向Alpha進行注冊，當Alpha需要進行相關的協調操作的時候，會直接調用Omega注冊的回調方法進行通信。由于微服務實例在云化場景啟停會很頻繁，我們不能假設Alpha一直能找到原有注冊上的事務回調，因此我們建議微服務實例是無狀態的，這樣Alpha只需要根據服務名就能找到對應的Omega進行通信。

? 事務傳輸模塊負責Omega與Alpha之間的通訊，在具體的實現過程中，Pack通過定義相關的Grpc描述接口文件定義了TCC以及Saga的事務交互方法，同時也定義了與交互相關的事件。^[ii]