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