在上一篇文章中，我们看到了实现分布式事务的一些挑战，以及如何使用Event / Choreography方法实现Saga的模式。在本文中，我们将讨论如何通过使用另一种类型的Saga实现（称为Command或Orchestration）来解决一些问题，如复杂事务或事件的循环依赖性。
Saga的命令/编曲序列逻辑
在编曲方法中，我们定义了一项新服务，其唯一责任是告诉每个参与者该做什么以及何时做什么。 saga orchestrator以命令/回复方式与每个服务进行通信，告诉他们应该执行哪些操作。
让我们看一下使用我们之前的电子商务示例的样子：
- 订单服务保存挂起的定单并要求Order Saga Orchestrator（OSO）启动创建订单交易。
- OSO向付款服务发送执行付款命令，并回复付款已执行消息
- OSO向库存服务发送准备订单命令，并回复订单准备消息
- OSO向Delivery Service发送Deliver Order命令，并以Order Delivered消息回复
在上面的例子中，Order Saga Orchestrator知道执行“创建订单”事务所需的流程是什么。如果有任何失败，它还负责通过向每个参与者发送命令以撤消先前的操作来协调回滚。
为saga协调器建模的标准方法是状态机，其中每个转换对应于命令或消息。状态机是构建定义明确的行为的极好模式，因为它们易于实现，特别适合测试。
在Saga的命令/编曲中回滚
当你有一个协调器来协调所有事情时，回滚会容易得多：
使用Saga命令/编曲设计的好处和缺点
基于编排的传奇有各种好处：
避免服务之间的循环依赖，因为saga orchestrator调用saga参与者但参与者不调用orchestrator
- 集中分布式事务的编排
- 降低参与者的复杂性，因为他们只需要执行/回复命令。
- 更容易实施和测试
- 添加新步骤时，事务复杂性保持线性
- 回滚更容易管理
- 如果您有第二个愿意更改同一目标对象的事务，您可以轻松地将其保留在协调器上，直到第一个事务结束。
然而，这种方法仍然存在一些缺点，其中之一是在协调器中集中过多逻辑的风险，最终导致智能协调器告诉哑巴服务该做什么的架构。
Saga的Orchestration模式的另一个缺点是它会略微增加您的基础架构复杂性，因为您需要管理额外的服务。
Saga(传奇)模式提示
- 为每个事务创建唯一ID
为每个事务提供唯一标识符是可追溯性的常用技术，但它也有助于参与者以标准方式相互请求数据。例如，通过使用交易ID，交付服务可以询问库存服务在哪里提取产品，如果订单已付款，则可以使用支付服务仔细检查。
- 在命令中添加回复地址
不要将参与者设计为回复固定地址，而是考虑在消息中发送回复地址，这样您就可以让参与者回复多个协调者。
- 幂等运算
如果您使用队列进行服务之间的通信（如SQS，Kafka，RabbitMQ等），我个人建议您使您的操作具有幂等性。大多数队列可能会两次传递相同的消息。
它还可能会增加您的服务的容错能力。通常，客户端中的错误可能会触发/重放不需要的消息并弄乱您的数据库。
- 避免同步通信
随着事务的进行，不要忘记将每个要执行的操作所需的所有数据添加到消息中。整个目标是避免服务之间的同步调用只是为了请求更多的数据。即使其他服务处于脱机状态，它也可以使您的服务执行本地事务。
缺点是您的协调器会稍微复杂一些，因为您需要操纵每个步骤的请求/响应，因此请注意权衡。
