按交易分解 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

按交易分解

在分布式系统中,应用程序通常必须调用多个微服务才能完成一项业务事务。为避免延迟问题或两阶段提交问题,您可以根据事务对微服务进行分组。如果您认为响应时间很重要,并且不同的模块在打包后不会形成整体结构,则这种模式是合适的。下表说明了使用此模式的优势和劣势。

优点 劣势
  • 响应时间更短。

  • 您无需担心数据一致性。

  • 提高可用性。

  • 可以将多个模块打包在一起,这可以形成一个单体。

  • 多个功能是在单个微服务中实现的,而不是在单独的微服务中实现的,成本和复杂性因此而增加。

  • 如果业务域的数量和它们之间的依赖性很高,则面向事务的微服务可能增长。

  • 对于同一个业务领域,可能会同时部署不一致的版本。

在下图中,保险单体根据交易分解为多个微服务。

通过交易分解单体

在保险系统中,索赔申请通常在提交后标记给客户。这意味着,如果没有客户微服务,理赔服务就不可能存在。销售客户打包在一个微服务包中,业务交易需要与两者进行协调。