需要对微服务进行澄清

Question

我需要对微服务进行一些说明。 1）据我了解，只有编舞需要事件源，在编舞中，我们使用发布/订阅模式。此外，我们使用像RabbitMQ这样的程序来确保发布者和订阅者之间的通信。

2）编排不使用事件源。它使用观察者模式并直接与观察者通信。因此，它不需要总线/消息代理（例如RabbitMQ）。为了协调业务流程中的所有流程，我们使用调解器模式。

对吗？

Answer 1

在微服务编排中，遵循集中化的方法在编排器的帮助下执行决策和控制。协调器必须直接与相应的服务进行通信，等待响应，并根据响应做出决定，因此它是紧密耦合的。它更多地是与业务逻辑同步的方法，主要是在协调器中，并且它拥有针对业务逻辑进行排序的所有权。编排方法通常遵循请求/响应类型模式，其中服务之间存在点对点连接。

在微服务编排中，采用了一种分散式方法，该方法具有更大的自由度，每个微服务都可以独立执行其功能，具有自我意识，并且不需要中央实体的任何指令。它更多是一种异步方法，业务逻辑分布在微服务上，每个微服务都应侦听其他服务事件，并自行决定是否执行某项操作。因此，编排方法依赖消息代理（发布/订阅）在微服务之间进行通信，从而每个服务都应观察系统中的事件并自主处理事件。

Answer 2

TLDR：编排是不需要持久化流程状态的流程，编排需要将流程的状态保持在某个位置。

我认为您在实现细节上有些困惑。

业务流程之所以这样称呼，是因为有一个中央流程管理器（有时称为saga，错误地恕我直言），它指导（读取协调）其他服务之间的操作。在这种模式下，流程管理器将操作定向到BC，但需要保持先前操作的状态，以便撤消，回滚或采取任何认为必要的纠正或报告操作。如果通过Web请求完成了无用请求，则该状态可以保存在事件流，标准形式的db中，甚至可以隐式保存在内存中（例如，一种方法一个接一个地执行请求并在错误时撤消前一个请求的方法）。例如。请注意，协调器可能会使用同步的请求-响应通信（例如发出Web请求）。在那种情况下，协调器仍然保持一个状态，只是该状态是隐式的（操作顺序）或内存中的状态。但是状态仍然存在，并且如果要实现弹性（能够从异常或任何灾难性故障中恢复），则再次需要将该状态持久保存在磁盘上，以便可以恢复。

之所以称为编排，是因为进行这些操作的业务逻辑部分相互观察并作出响应。因此，例如，当服务A做某事时，它会引发一个事件，B会观察到该事件以采取后续行动，依此类推，以此类推，而不是让流程管理器先问A再问B，等等。或可能不需要坚持。这实际上取决于不同服务需要采取的纠正措施。

---

一个例子：作为一个实际例子，假设您要购买商品时保留商品，付款，然后使用快递服务来显示货件，然后向收件人发送电子邮件。

在这两种情况下，操作的顺序都很重要（因为您希望尽可能采取纠正措施），因此我们决定在快递员出具后决定付款。

通过编排，我们将有一个名为PM的流程管理器，该流程将执行以下操作：

当用户尝试进行购买时，会调用
1. PM
2. 致电Inventory服务预订商品
3. 致电Courier integration服务以向承运人证明货运
4. 致电Payments服务进行付款
5. 向用户发送电子邮件，告知他们正在收货。

如果PM在4上发现错误，则唯一的纠正措施是重试发送emai，然后报告。如果付款过程中出现错误，则项目经理将直接致电Courier integration服务取消货运，然后致电Inventory取消预订商品。

在编排过程中，会发生以下情况：

1. 所有需要数据的服务都会引发并观察OrderMade事件
2. Inventory处理OrderMade事件并引发OrderReserved
3. CourierIntegration处理OrderReserved事件并引发ShipmentManifested
4. Payments服务处理ShipmentManifested，成功则产生PaymentMade
5. 电子邮件服务处理PaymentMade并发送通知。

回滚与上述过程相反。如果Payments服务引发错误，则Courier Integration将处理该错误并引发ShipmentCancelled事件，而该事件又由Inventory处理以引发OrderUnreserved，该事件依次由电子邮件服务处理以发送通知。