[微服务 ]Saga 模式| 如何使用微服务实现业务事务 第一部分

最强大的事务类型之一称为两阶段提交，当第一个事务的提交取决于第二个事务的完成时，它是摘要。特别是当您必须同时更新多个实体时，例如确认订单和立即更新库存时，它非常有用。

但是，例如，当您使用微服务时，事情变得更加复杂。每个服务都是一个独立的系统，拥有自己的数据库，您不再可以利用本地两阶段提交的简单性来维护整个系统的一致性。

当你失去这种能力时，RDBMS成为一个非常糟糕的存储选择，因为你可以完成相同的“单实体原子事务”，但只需使用像Couchbase这样的NoSQL数据库就可以快几十倍。这就是为什么大多数使用微服务的公司也在使用NoSQL。

要举例说明此问题，请考虑以下电子商务系统的高级微服务架构：

在上面的示例中，人们不能只在一个ACID交易中下订单，向客户收费，更新库存，并将其发送到交货。要始终如一地执行此整个流程，您将需要创建分布式事务。

我们都知道实现分布式任务是多么困难，不幸的是，交易也不例外。处理瞬态状态，服务，隔离和回滚之间的最终一致性是在设计阶段应该考虑的场景。

幸运的是，我们已经为它提出了一些好的模式，因为我们已经实施分布式事务已有二十多年了。我今天要谈的那个叫做Saga模式。

传奇(Saga)模式

分布式事务最着名的模式之一称为Saga。关于它的第一篇论文发表于1987年，从那时起它就成了一种流行的解决方案。

Saga是一系列本地事务，其中每个事务在单个服务中更新数据。第一个事务由对应于系统操作的外部请求启动，然后每个后续步骤由前一个完成触发。

使用我们之前的电子商务示例，在一个非常高级的设计中，Saga实现如下所示：

有几种不同的方法来实现传奇交易，但最受欢迎的两种方式是：

1. 事件/Choreography(编舞)：当没有中央协调时，每个服务产生并监听其他服务的事件，并决定是否应该采取行动。

2. 命令 / Orchestration(编曲)：协调器服务负责集中saga的决策和排序业务逻辑。

让我们更深入地了解每个实现，以了解它们的工作原理。

事件/编舞

在事件/Choreography(编舞)方法中，第一个服务执行事务然后发布事件。该事件由一个或多个服务监听，这些服务执行本地事务并发布（或不发布）新事件。

当最后一个服务执行其本地事务并且不发布任何事件时，分布式事务结束，或者任何传奇(Saga)参与者都不会听到发布的事件。

让我们看看它在我们的电子商务示例中的样子：

1. 订单服务保存新订单，将状态设置为挂起并发布名为ORDER_CREATED_EVENT的事件。

2. 付款服务侦听ORDER_CREATED_EVENT，向客户收费并发布事件BILLED_ORDER_EVENT。

3. Stock Service监听BILLED_ORDER_EVENT，更新库存，准备订单中购买的产品并发布ORDER_PREPARED_EVENT。

4. Delivery Service侦听ORDER_PREPARED_EVENT，然后选择并交付产品。最后，它发布了ORDER_DELIVERED_EVENT

5. 最后，Order Service侦听ORDER_DELIVERED_EVENT并将订单状态设置为已结束。

在上面的情况中，如果需要跟踪订单的状态，订单服务可以简单地监听所有事件并更新其状态。

分布式事务中的回滚

回滚分布式事务并非免费。通常，您必须实施另一个操作/事务来补偿之前已完成的操作。

假设Stock Service在交易期间失败了。让我们看看回滚会是什么样子：

1. 库存服务生产PRODUCT_OUT_OF_STOCK_EVENT;

2. 订单服务和付款服务都会收听上一条消息：

• 付款服务退还客户。

• 订单服务将订单状态设置为失败。

请注意，为每个事务定义一个公共共享ID至关重要，因此每当您抛出一个事件时，所有侦听器都可以立即知道它所引用的事务。

Saga 事件/Choreography(编舞)设计的好处和缺点

事件/编排是实现Saga模式的自然方式;它简单，易于理解，不需要太多的努力来构建，并且所有参与者都是松散耦合的，因为他们没有彼此的直接知识。如果您的交易涉及2到4个步骤，那么它可能非常合适。

但是，如果您不断在事务中添加额外的步骤，这种方法很快就会变得混乱，因为很难跟踪哪些服务监听哪些事件。此外，它还可能在服务之间添加循环依赖，因为它们必须订阅彼此的事件。

最后，使用这种设计实现测试会很棘手。为了模拟事务行为，您应该运行所有服务。

在下一篇文章中，我将解释如何使用另一个名为Command / Orchestration的Saga实现解决Saga事件/编舞方法的大部分问题。

本文 :https://architect.pub/microservices-architecture-saga-pattern-how-use-microservices-implement-business-transactions-part
讨论：知识星球【首席架构师圈】或者加微信小号【ca_cto】或者加QQ群【792862318】
公众号	【jiagoushipro】 【架构师酒馆】 精彩图文详解架构方法论，架构实践，技术原理，技术趋势。 我们在等你，赶快扫描关注吧。
微信小号	【ca_cea】 50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化.
QQ群	【285069459】深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。 加QQ群，有珍贵的报告和干货资料分享。
视频号	【架构师酒馆】 1分钟快速了解架构相关的基本概念，模型，方法，经验。 每天1分钟，架构心中熟。
知识星球	【首席架构师圈】向大咖提问，近距离接触，或者获得私密资料分享。
喜马拉雅	【超级架构师】路上或者车上了解最新黑科技资讯，架构心得。	【智能时刻，架构君和你聊黑科技】
知识星球	认识更多朋友，职场和技术闲聊。	知识星球【职场和技术】
微博	【架构师酒馆】	智能时刻
哔哩哔哩	【架构师酒馆】
抖音	【cea_cio】架构师酒馆
快手	【cea_cio_cto】架构师酒馆
小红书	【cea_csa_cto】架构师酒馆
网站	CIO(首席信息官)	https://cio.ceo
网站	CIO,CTO和CDO	https://cioctocdo.com
网站	架构师实战分享	https://architect.pub
网站	程序员云开发分享	https://pgmr.cloud
官网	行天智能科技咨询公司	https://xingtian.ai
网站	开发者闲谈	https://blog.developer.chat
网站	首席隐私官内参	https://cpo.work
网站	首席安全官内参	https://cso.pub
网站	CIO内参	https://cio.cool
网站	CDO内参	https://cdo.fyi
网站	CXO内参	https://cxo.pub
网站	首席架构师社区	https://jiagoushi.pro

谢谢大家关注，转发，点赞和点在看。