微服務中的事務

Question

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

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

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

Answer 1

我可能不是這方面的終極專家，但我相信你正在走向分布式交易 。 為了讓它們運行，所有應用程序服務組件都需要一個共同的共享事務ID，並且您必須確保每個組件都被告知事務的狀態。 它是異步的，因此您需要大量的編程技能。

以下是提到或討論的分布式交易：

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

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

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

似乎人們試圖避免它，因為它很難。 也許這就是為什么你找不到多少。

希望這有助於向前邁進一步:-)

Answer 2

最好的設計是提供隔離服務：每個服務只在自己的事務中完成工作，而您的工作流程預計單個服務會出現故障。

如果您確實只需要在沒有錯誤的情況下調用所有服務時提交，那么您應該創建一個更高級別的服務來在外部事務中執行這些調用。

Answer 3

在閱讀完這個問題之后，我想到的第一個原始內容是使用delete api創建每個add api，比方說，一個額外的布爾標志delFlag。

boolean flag delFlag;

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

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

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

Answer 4

在之前的答案的基礎上，分布式事務是解決方案。 在我看來，你不想建立自己的機制來跟蹤全局事務狀態，而是想要使用某種產品 - 有幾種產品。 我寫了一篇關於用Java應用服務器解決這個問題的博文：

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

Answer 5

兩階段提交可以是option.Coordinator發送提交請求消息給cohorts.Cohorts發回ok.After協調器發送提交消息到同類群組。如果任何故障happpens協調器發送回滾消息給同類群組。

Answer 6

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