微服務中的交易

Question

我已經閱讀了一些關於微服務架構的文章，但沒有人會談論交易的話題。他們都說這很難做到。也許有人可以描述如何處理這個？

但不是來自域端，而是來自技術端。假設我們有業務案例，我們需要調用兩個不同的服務，並且他們都對數據庫進行了一些更改。但是如果在第二個錯誤發生時如何回滾？

誰知道這個問題的一些圖書館或設計模式？

Answer 1

最好的設計是有獨立的服務：每個服務只是在自己的事務中完成它的工作，而你的工作流程預計單一服務會出現故障。

如果只有在所有服務都被錯誤地調用的情況下才需要提交，那麼應該創建一個更高級別的服務來在外部事務中執行這些調用。

Answer 2

我可能不是這方面的最終專家，但我相信你正在走向分佈式交易。爲了讓它們運行，所有的應用程序服務組件都需要一個公共的共享事務ID，並且必須確保每個組件都被告知有關事務的狀態。它是異步的，所以你需要大量的編程技巧。提到或討論

下面是分佈式事務：

https://en.wikipedia.org/wiki/Distributed_transaction

http://contino.co.uk/microservices-not-a-free-lunch/

http://martinfowler.com/articles/microservices.html

這似乎人們儘量避免它，因爲它是困難的。也許這就是爲什麼你沒有發現很多。

希望這有助於向前邁進了一步:-)以前的答案頂部

Answer 3

大廈，分佈式事務的解決方案。在我看來，你不想建立自己的跟蹤全局事務狀態的機制，而是想使用某種產品 - 有幾種產品。我已經寫了關於解決這一問題的Java應用服務器冗長的博客文章：

http://blog.maxant.co.uk/pebble/2015/08/04/1438716480000.html

Answer 4

兩階段提交可以option.Coordinator發送提交請求消息cohorts.Cohorts發回ok.After然後協調員發送提交消息給隊列。如果任何失敗使協調器向隊列發送回退消息。

Answer 5

它來到我的腦海裏讀取這個問題後的第一胎就是要創建的每個添加 API與刪除 API和，可以說，一個額外的布爾標誌delFlag。

布爾標誌delFlag;

對於POST，它將爲0.對於DELETE，它將爲1。

現在您維護一個交易管理器，它是所有微服務的超級服務。 在此服務中維護所有服務和API的調用隊列。當服務失敗時，獲取調用api並調用該服務的刪除方法，並撤消您所做的任何操作。

PS-只是一個原始的想法。糾正我，如果你認爲它是錯誤的。

Answer 6

您可以使用工作流引擎（如JBPM，Activiti）編排邏輯並處理事務故障或其中的補償事務，以實現數據完整性。這是你在SOA架構中使用ESB，BPMN和Web服務的類似案例