Saga的实现模式——控制者（Saga implementation patterns – Controller）

之前的文章中我们介绍了观察者模式。在这个模式里，saga在整个业务中是一个被动的参与者，和大多数快餐店完成订单流程类似。但是并不是所有的快餐店都用这种方式，还有更多的更有效率的方式能够完成这种工作。

我们可以让我们的saga在整个业务过程中扮演一个主动的角色。saga直接控制整个流程，向特定的工作者发出command，等待回复，然后跳转到下一个步骤。这种方式在某个业务顺序确定的流程中可以工作得很好：

我们的saga有一个特定的顺序，在经过一定的时间，步骤之后，saga需要从前面的步骤获取相应的信息。为了实现一个订单，我们必须能够控制整个流程。在付款前我们不能运送货物，订单没有生成我们不能完成付款，等等。

和观察者saga不一样，控制者saga通过发布command或者根据反馈来引导整个工作流，决定是否进入下一步。如果一个步骤因失败或者接到一个错误信息反馈而返回，我们就可以进入一个其他的工作流中。我们可以使用修正操作（compensating actions）或者进入其他手动控制的流程里。

这里的关键是控制者saga发布command，而观察者saga收集事件。就像观察者saga一样，我们可以再次观察食品加工过程来看控制者saga在实际中对应的例子。

尽管我们的麦当劳例子中的每个步骤的执行都可以是并行的，没有任何的合作和相互依赖，但是我们当地的三明治店就使用了完全相反的方式。在这个商店中，整个流程就是一个单一的通道：

我们的客人通过下一个订单开始整个流程。在Which Wich，用一种很巧妙地方式实现下订单。客户选一个标有主要配料的纸袋。在这个纸袋上有一个配料表，客户勾选配料表来选择他们想要在三明治里面加什么。最后客户在纸袋上写上名字——这样加工三明治的人就知道他们的三明治要给谁，订单就完成了。

一条铁丝穿越了整家店，然后你的纸袋就挂在上，店员就会按照处流程顺序把你的纸袋顺着铁丝滑到下一个工作台。

铁丝并不是我们例子中的“非常”核心的控制者——我们并没有一个负责协调整个通道的员工。而整个协调过程就是整个队列的内在顺序。如果我们想要在真实世界餐厅里面找到我们想要的控制者角色，我们就需要举一家高端的有专门的人负责管理流程的快餐店的例子——但是我可不想让这个事实妨碍我们的例子。

这种方式有一些优点：

这方方式也有一些无法避免的缺点：

时间： 2024-10-03 22:25:36

Saga的实现模式——观察者（Saga implementation patterns – Observer）