依交易分解 - AWS 方案指引

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

依交易分解

在分散式系統中，應用程式通常必須呼叫多個微服務才能完成一次商業交易。為了避免延遲問題或兩階段遞交問題，您可以根據交易將微服務分組。如果您認為回應時間很重要，且不同的模組在封裝之後不會建立整體，則此模式是適當的。下表說明使用此模式的優點和缺點。

優點 缺點

  • 回應時間更快。

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

  • 改善可用性。

  • 多個模組可以封裝在一起，這可以建立整體。

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

  • 如果交易導向的微服務之間的商業網域數量和相依性很高，則交易導向的微服務可能會成長。

  • 同一業務網域可能會同時部署不一致的版本。

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

依交易分解整體

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