前言
本例基於Atomikos提出的微服務分佈式事務的解決方案, 該方案建立在更加輕量級的HTTP協議之上, 原文如下
TCC for transaction management across microservices
根據Try Confirm Cancel補償模式, 有關於Spring Cloud的實戰如下
https://github.com/prontera/spring-cloud-rest-tcc
示例場景
一個簡單的TCC應用如下: 圖中藍色方框Booking Process代表訂票系統, 該系統分別對swiss和easyjet發起預留機票資源的請求
在步驟1.1對”swiss”發起Try預留請求. 服務提供方”swiss”將會等待Confirm操作, 如果超時那麼就將會被自動撤銷(Cancel)並釋放資源. 確認資源的入口就是URI R1的HTTP PUT請求.
在步驟1.2中, 使用URI R2對”easyjet”作出如第一點中一樣的預留資源操作
在步驟1.3中, Booking Process現在可以通過協調器(Coordinator)服務發起對上述兩個預留資源的確認(Confirm)操作. 並且, 資源協調服務會處理相關服務的確認或者補償操作.
如果在第3步之前有任何異常, 那麼所有預留資源將會被Cancel或者等待超時然後被自動撤銷. 如果是在第3步Confirm之後纔出現異常, 那麼所有的資源都不會受到影響. 在第3步中發生的異常都會由Coordinator服務處理, 包括因爲宕機或者是網絡抖動所引起的恢復重試. 對REST服務提供了事務保證.
角色
這套API由3個角色組成: 參與者角色, 協調者角色和應用程序.
- 參與者是特指那些實現了TCC柔性事務的應用程序, 就正如本示例中的”swiss”和”easyjet”
- 協調者角色是特指那些管理一組相關參與者的服務調用, 如Confirm, Cancel操作, 在本示例中是”Transaction Coordinator”
- 應用程序, 這裏我稱之爲請求方, 除了需要使用協調器外無其他要求, 如本示例中的”Booking Process”
TCC服務提供方: 參與者API
參與者職責
參與者負責管理特定的業務資源. 默認情況下業務預留資源在一定時間後會超時, 除非該預留資源被協調器所確認.
自動超時和撤回
每一個參與者的實現必須有自動Cancel超時資源的功能. 除非參與者接收到確認消息, 否則沒有資源是不會過期的.
資源操作的入口
每個參與者的實現必須返回一個用於調用Confirm的鏈接. 這些鏈接可以包含Confirm的URI, 自動過期時間等元數據. 下面是一個簡單例子
{
"participantLink":
{"uri":"http://www.example.com/part/123",
"expires":"2014-01-11T10:15:54Z"
}
}實際上例子中的JSON只是建議格式, 真實使用的時候完全取決於雙方的通信格式.
PUT to Confirm
在上述參與者返回的用於確認的鏈接中, 必須支持PUT方法以用於確認. 由於網絡抖動等情況, 該操作必須具備冪等性.
PUT /part/123 HTTP/1.1
Host: www.example.com
Accept: application/tcc注意請求頭中MIME類型, 暗示了客戶端的語義期望(可根據實際情況選擇是否實現該MediaType). Confirm操作通常由協調者調用.
儘管參與者提供的API有指定的MIME類型, 但是這個類型僅僅用於指明語義, 實際上並不需要request body與response body.
如果一切正常, 那麼參與者的響應如下
HTTP/1.1 204 No Content如果Confirm請求送達參與者後發現預留資源早就被Cancel或者已經超時被回滾, 那麼參與者的API必須返回404錯誤
HTTP/1.1 404 Not FoundDELETE to Cancel: 可選實現
每個參與者URI**或許**會有實現DELETE方法去顯式地接受撤銷請求. 由於網絡抖動等情況, 該操作必須具備冪等性.
DELETE /part/123 HTTP/1.1
Host: www.example.com
Accept: application/tcc如果補償成功則返回
HTTP/1.1 204 No Content因爲參與者有實現自動撤銷超時資源的職責, 那麼如果在顯式地調用Cancel的時候有其他錯誤發生, 那麼這些錯誤都可以被忽略而且不影響整體的分佈式事務
在內部事務已經超時或者已經被參與者自身補償之後, 那麼他可以直接返回404
HTTP/1.1 404 Not Found因爲DELETE請求是一個可選操作, 有些參與者可能沒有實現這個功能, 在這個情況下可以返回405
HTTP/1.1 405 Method Not AllowedGET方法故障診斷: 可選實現
參與方服務可以實現GET方法來用於故障的診斷. 但是這個超出了REST TCC的簡約協議的意圖, 所以這個功能就由實際情況來決定是否實現
協調器API: 面向請求方的開發者
協調器服務是由我們實現, 並交由請求方的開發人員使用. 因爲這裏從使用RESTful接口的設計角度來說明, 而不討論協調器的內部實現.
協調器職責
- 對所有參與者發起Confirm請求
- 無論是協調器發生的錯誤還是調用參與者所產生的錯誤, 協調器都必須有自動恢復重試功能, 尤其是在確認的階段.
- 能判斷有問題的Confirm操作的原因
- 方便地進行Cancel操作
PUT to Confirm
請求方對協調器發出PUT請求來確認當前的分佈式事務. 這些事務就是參與者之前返回給請求方的確認鏈接
PUT /coordinator/confirm HTTP/1.1
Host: www.taas.com
Content-Type: application/tcc+json
{
"participantLinks": [
{
"uri": "http://www.example.com/part1",
"expires": "2014-01-11T10:15:54Z"
},
{
"uri": "http://www.example.com/part2",
"expires": "2014-01-11T10:15:54+01:00"
}
]
}然後協調器會對參與者逐個發起Confirm請求, 如果一切順利那麼將會返回如下結果
HTTP/1.1 204 No Content如果發起Confirm請求的時間太晚, 那麼意味着所有被動方都已經進行了超時補償
HTTP/1.1 404 Not Found最最最糟糕的情況就是有些參與者確認了, 但是有些就沒有. 這種情況就應該要返回409, 這種情況在Atomikos中定義爲啓發式異常
HTTP/1.1 409 Conflict當然, 這種情況應該儘量地避免發生, 要求Confirm與Cancel實現冪等性, 出現差錯時協調器可多次對參與者重試以儘量降低啓發性異常發生的機率. 萬一409真的發生了, 則應該由請求方主動進行檢查或者由協調器返回給請求方詳細的執行信息, 例如對每個參與者發起故障診斷的GET請求, 記錄故障信息並進行人工干預.
PUT to Cancel
一個撤銷請求跟確認請求類似, 都是使用PUT請求, 唯一的區別是URI的不同
PUT /coordinator/cancel HTTP/1.1
Host: www.taas.com
Content-Type: application/tcc+json
{
"participantLinks": [
{
"uri": "http://www.example.com/part1",
"expires": "2014-01-11T10:15:54Z"
},
{
"uri": "http://www.example.com/part2",
"expires": "2014-01-11T10:15:54Z"
}
]
}唯一可預見的響應就是
HTTP/1.1 204 No Content因爲當預留資源沒有被確認時最後都會被釋放, 所以參與者返回其他錯誤也不會影響最終一致性