交易分解 - AWS 規定指引

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

交易分解

在分散式系統中，應用程式通常必須呼叫多個微服務來完成一項商業交易。為了避免延遲問題或兩階段提交問題，您可以根據交易對微服務進行分組。如果您認為響應時間很重要，並且您的不同模塊在打包後不會創建整體模塊，則此模式是適當的。下表說明使用此模式的優點和缺點。

優點 缺點

  • 更快的響應時間。

  • 您不需要擔心資料一致性。

  • 改善的可用性。

  • 多個模塊可以打包在一起，這可以創建一個整體。

  • 在單一微服務中實作多項功能，而不是單獨的微服務，這會增加成本和複雜性。

  • 如果業務網域和它們之間的相依性很高，則以交易為導向的微服務可能會增加。

  • 不一致的版本可能會同時針對相同的企業網域部署。

在下圖中，保險整體式會根據交易細分為多個微型服務。

通過交易分解巨石

在保險系統中，索賠請求通常會在提交後標記給客戶。這表示如果沒有客戶微服務，就無法存在索賠服務。銷售和客戶會在一個微服務套件中封裝在一起，而商業交易需要與兩者協調。