需要澄清微观服务

Question

我需要一些关于微观服务的澄清。1)据我所知，只有舞蹈需要事件源，而在编排中，我们使用发布/订阅模式。此外，我们还使用像RabbitMQ这样的程序来确保发布者和订阅者之间的通信。

2)业务流程不使用事件源。它使用观测器模式，并直接与观察者通信。因此，它不需要总线/消息代理(如RabbitMQ)。在编排过程中，我们使用中介模式来协调所有的过程。

对吗？

Answer 1

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

在微观服务编排中，采用了一种分散的方法，即有更多的自由，这样每个微服务都可以独立地执行它们的功能，它们是自我意识的，它不需要来自一个集中实体的任何指令。它更多地是一种异步方法，业务逻辑在微服务中传播，每个微服务都应该侦听其他服务事件，并自行决定是否执行某个操作。因此，编排方法依赖于消息代理(发布/订阅)在微服务之间进行通信，其中每个服务都应该观察系统中的事件并自主地对事件进行操作。

Answer 2

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

我认为这与实现细节有些混淆。

业务流程被称为这样，因为有一个中央流程管理器(有时被称为saga，错误地说是imho)，它指导(读编排)跨其他服务的操作。在这种模式中，流程管理器将操作定向到BC，但需要对以前的操作保持状态，以便撤消、回滚或采取任何必要的纠正或报告操作。如果外部绑定请求是通过web请求完成的，则可以在事件流、范式db中，甚至在隐式和内存中(例如，在逐个执行请求并在错误时取消先前请求的方法中)保持这种状态。请注意，编排人员可以使用同步的请求响应通信(比如发出web请求)。在这种情况下，协调器仍然保持状态，只是这种状态是隐式的(操作顺序)或-mem。但是，状态仍然存在，如果您想实现弹性(为了能够从异常或任何灾难性的故障中恢复)，您将再次需要将该状态保存在磁盘上，以便您能够恢复。

之所以称为编排，是因为执行操作的业务逻辑片段相互观察和响应。例如，当服务A做事情时，它会引发B观察到的事件来执行后续行动，等等，而不是让流程经理问A，然后再问B等等。编排可能需要也可能不需要坚持。这实际上取决于不同服务需要采取的纠正措施。

一个例子:作为一个实际的例子，假设在购买时你想要预订货物，接受付款，然后用快递服务显示一批货物，然后发送一封电子邮件给收件人。

在这两种情况下，操作的顺序都很重要(因为您希望能够在可能的情况下采取纠正措施)，所以我们决定在显示后与信使进行付款。

对于业务流程，我们有一个名为PM的流程管理器，流程可以：

当用户试图购买货物时调用

1. PM，调用Inventory服务以预订货物
2. 调用Courier integration服务以承运人

H 111调用Payments服务来收取付款H 213H 114向用户发送电子邮件，说明他们正在接收货物。H 215G 216

如果PM在4上注意到一个错误，他们只需要重试发送emai，然后报告。如果在付款过程中有错误，那么PM会直接打电话给Courier integration服务部门取消装运，然后打电话给Inventory取消货物的预订。

在编舞方面，所发生的事情是：

所有需要data

• Inventory的服务都会引发和观察OrderMade事件，这些服务处理OrderMade事件，引发OrderReserved

• CourierIntegration处理OrderReserved事件，引发ShipmentManifested

• Payments服务处理ShipmentManifested，成功时引发PaymentMade

• The电子邮件服务处理PaymentMade并发送notification.

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