在之前的系列文章中聊過分散式事務的一種實現方案,即通過在叢集中暴露actor服務來實現分散式事務的本地原子化。但是actor服務本身有其特殊性,場景上並不通用。所以今天來講講分散式事務實現方案之saga模式,並在文後附上程式碼供各位讀者參考,評論。
目錄:
一、通過Dapr實現一個簡單的基於.net的微服務電商系統
二、通過Dapr實現一個簡單的基於.net的微服務電商系統(二)——通訊框架講解
三、通過Dapr實現一個簡單的基於.net的微服務電商系統(三)——一步一步教你如何擼Dapr
四、通過Dapr實現一個簡單的基於.net的微服務電商系統(四)——一步一步教你如何擼Dapr之訂閱釋出
五、通過Dapr實現一個簡單的基於.net的微服務電商系統(五)——一步一步教你如何擼Dapr之狀態管理
六、通過Dapr實現一個簡單的基於.net的微服務電商系統(六)——一步一步教你如何擼Dapr之Actor服務
七、通過Dapr實現一個簡單的基於.net的微服務電商系統(七)——一步一步教你如何擼Dapr之服務限流
八、通過Dapr實現一個簡單的基於.net的微服務電商系統(八)——一步一步教你如何擼Dapr之鏈路追蹤
九、通過Dapr實現一個簡單的基於.net的微服務電商系統(九)——一步一步教你如何擼Dapr之OAuth2授權 && 百度版Oauth2
十、通過Dapr實現一個簡單的基於.net的微服務電商系統(十)——一步一步教你如何擼Dapr之繫結
十一、通過Dapr實現一個簡單的基於.net的微服務電商系統(十一)——一步一步教你如何擼Dapr之自動擴/縮容
十二、通過Dapr實現一個簡單的基於.net的微服務電商系統(十二)——istio+dapr構建多執行時服務網格
十三、通過Dapr實現一個簡單的基於.net的微服務電商系統(十三)——istio+dapr構建多執行時服務網格之生產環境部署
十四、通過Dapr實現一個簡單的基於.net的微服務電商系統(十四)——開發環境容器除錯小技巧
十五、通過Dapr實現一個簡單的基於.net的微服務電商系統(十五)——集中式介面文件實現
十六、通過Dapr實現一個簡單的基於.net的微服務電商系統(十六)——dapr+sentinel中介軟體實現服務保護
十七、通過Dapr實現一個簡單的基於.net的微服務電商系統(十七)——服務保護之動態配置與熱過載
十八、通過Dapr實現一個簡單的基於.net的微服務電商系統(十八)——服務保護之多級快取
十九、通過Dapr實現一個簡單的基於.net的微服務電商系統(十九)——分散式事務之Saga模式
附錄:(如果你覺得對你有用,請給個star)
一、電商Demo地址
一、什麼是Saga
在領域驅動設計中,由於領域邊界的存在,以往的分層設計中業務會按照其固有的領域知識被切分到不同的限界中,並且引入了領域事件這一概念來降低單個業務的複雜度,通過非耦合的事件驅動來完成複雜的業務。但是事件驅動帶來了一些新的問題,由於以往一個原子性極強的邏輯被拆散到了一個一個小的領域中,原子性事務資料的強一致性無法被保證。為了解決這個問題,一般會採用事務補償的方式來確保最終一致。
當我們採用多個本地事務組合去進行業務處理時,由於業務其本身的複雜性,往往需要在多個事務中協調。而事件協調器(saga)就是一個專門降低其複雜度的設計,開發人員原則上只需要將事件和補償按照一定順序註冊到協調處理器中,原則上協調器會按照註冊的事件依次執行,若出現事件執行失敗時,也會按照補償列表進行相應的回滾。
去年曾經在一篇文章裡聊過Saga,連結在此。相比去年的那個小DEMO。我在此基礎上基於Dapr的狀態管理完成了另外一個開源專案Oxygen-Saga,地址:https://github.com/sd797994/Oxygen-Saga。當然這個專案既可以引入到dapr的環境中完成Saga事務,本身也可以獨立的基於rabbitmq+redis來完成非Dapr環境下的Saga事務。今天主要講解一下如何在Dapr環境下引入Saga來實現一個分散式事務。
首先我們還是看看目前的一個訂單下單邏輯,可以看到基於Actor服務,我們的請求是在訂單服務裡直連商品服務Actor完成庫存減扣的,並通過Actor的週期性持久化機制完成事務落庫,所以實際上是把分散式事務的複雜性通過Actor遮蔽掉了,並沒有涉及到真正的分散式事務。
從程式碼層面也可以看到,整個事務其實是在同一個方法裡以同步呼叫Actor的方式完成的。
#region 私有遠端服務包裝器方法 async Task<List<OrderGoodsSnapshot>> GetGoodsListByIds(IEnumerable<Guid> input) { return (await goodsQueryService.GetGoodsListByIds(new GetGoodsListByIdsDto(input))).GetData<List<OrderGoodsSnapshot>>(); } async Task<bool> DeductionGoodsStock(CreateOrderDeductionGoodsStockDto input) { var data = input.CopyTo<CreateOrderDeductionGoodsStockDto, DeductionStockDto>(); data.ActorId = input.GoodsId.ToString(); return (await goodsActorService.DeductionGoodsStock(data)).GetData<bool>(); } async Task<bool> UnDeductionGoodsStock(CreateOrderDeductionGoodsStockDto input) { var data = input.CopyTo<CreateOrderDeductionGoodsStockDto, DeductionStockDto>(); data.ActorId = input.GoodsId.ToString(); return (await goodsActorService.UnDeductionGoodsStock(data)).GetData<bool>(); } #endregion
public async Task<ApiResult> CreateOrder(OrderCreateDto input) { var mockUser = (await accountQueryService.GetMockAccount()).GetData<CurrentUser>(); //申明一個建立訂單領域服務例項,將遠端rpc呼叫作為匿名函式傳遞進去 var createOrderService = new CreateOrderService(GetGoodsListByIds, DeductionGoodsStock, UnDeductionGoodsStock); return await ApiResult.Ok("訂單建立成功!").RunAsync(async () => { var order = await createOrderService.CreateOrder(mockUser.Id, mockUser.UserName, mockUser.Address, mockUser.Tel, input.Items.CopyTo<OrderCreateDto.OrderCreateItemDto, OrderItem>().ToList());//通過訂單服務建立訂單 repository.Add(order); if (await new CheckOrderCanCreateSpecification(repository).IsSatisfiedBy(order)) await unitofWork.CommitAsync(); await eventBus.SendEvent(EventTopicDictionary.Order.CreateOrderSucc, new OperateOrderSuccessEvent(order, mockUser.UserName));//傳送訂單建立成功事件 }, //失敗回滾 createOrderService.UnCreateOrder); }
而在Saga方案裡就變得不一樣了,我們需要藉助Saga的流程管理器在多個例項中流轉我們的事務,通過事件訂閱和釋出來最終完成一個分散式事務。具體的呼叫流程如下:
可以看到整個流程完全依賴於SagaManger來提供對應的呼叫策略,而作為開發人員只需要為每個策略提供對應的委託函式,對應的具體流程如下:
一、首先是訂單服務和商品服務在系統初始化時需要註冊對應的配置檔案到本地Saga管理器,並且需要提供對應的流程處理委託(包括業務事件委託+補償事件委託+異常處理委託)。
二、在客戶發起一個訂單時,只需要建立一個Saga流程例項,剩下的就交給Saga,它會自動幫我們流轉整個業務邏輯而無需人工插手。
二、talk is cheap, show me the code
首先我們需要為整個訂單建立流程設計一組Topic:
接著我們建立一個Saga配置註冊這組topic進去,流程比較簡單,第一步是扣除庫存,下一步是建立訂單,補償事件只有一個就是庫存回滾:
再然後我們需要建立這些Topic對應的事件處理器:
訂單服務:
商品服務:
接著我們在各自的服務裡去實現它們:
商品服務:
訂單服務:
然後我們在訂單用例裡建立一個Action用於啟動saga流程(注意是第二個方法):
最後我們在商品和訂單服務中引入saga元件並註冊事件和異常回撥委託(註冊程式碼相似,此處僅展示其中一個服務的):
接著我們修改m站的建立訂單介面,修改為新的Saga流程介面,然後編譯整個專案,啟動並測試一下:
可以看到整個流程被順利的通過Saga管理器流轉完畢。接著我們嘗試注入一個故障,看看能否正常的被異常訂閱器捕獲到:
編譯後再測試一下,我們可以看到事件異常訂閱器裡已經成功捕獲到了這個異常:
接著我們在建立訂單注入一個異常,讓商品庫存進行回滾操作,這裡由於下單後異常商品補償所以在介面上是體現不出來的(當然在真實的業務場景中一般是下單5秒等待後查詢訂單建立情況,或傳送一條站內信告知下單失敗),這裡我們通過列印控制檯來演示:
接著我們執行並下單,追蹤商品服務的日誌:
可以看到由於訂單建立失敗,saga觸發了補償事件併成功執行了補償。好了,關於saga的演示就到這裡,可嘗試拉取最新的商城原始碼執行即可看到效果。