events - 关于事件驱动拓扑中的中介器

Question

我正在阅读这篇名为 Variations in event-driven architecture 的文章他们在其中演示了中介和代理拓扑。

根据文章，中介拓扑看起来有点像这样:

The event flow starts with the client sending an event to an event queue, which is used to transport the event to the mediator. The event mediator receives the initial event and orchestrates that event by sending additional asynchronous events to event channels to execute each step of the process. Event processors, which listen on the event channels, receive the event from the even mediator and execute specific business logic to process the event [...] It is important to note that the event mediator doesn't actually perform the business logic necessary to process the initial event, rather, it knows of the steps required to process the event [...] The event channels can be either message queues o message topics.

所以，我正在研究这个图，试图了解中介如何确定给定处理器何时完成了给定事件的处理，以便它可以协调流程的下一步。

文章说的不够清楚

For each initial event step, the event mediator creates a processing event, sends that processing event and waits for the processing event to be processed by the corresponding event processor. This process continues until all of the steps in the initial event have been processed.

现在，文章很清楚通信是异步的，并且事件消息将通过消息队列传播，但图中没有显示任何从事件处理器出来并返回到中介者的事件。

文章称中介器等待事件处理器完成，但在架构方面尚不清楚这应该如何发生。

它是异步的、基于队列的 RPC(例如 Rabbit RPC)，还是有另一个监听器在某处等待异步响应？

关于如何从架构的角度实现这一点的任何想法？

Answer 1

在我看来，他们只是没有绘制从事件处理器返回的事件，也许是因为它们可能不是特定的事件(例如某种回调)，或者因为它们可能不是正常事件(也许只是返回的事件)对中介者不可见，对任何其他订阅者不可见)，具体取决于您用作中介者的内容。这部分似乎表明了这样的事情:

The event mediator can be implemented in a variety of ways. Understand each implementation option to ensure that the solution you choose for the event mediator matches your needs.

The simplest and most common implementation of the event mediator is through open source integration hubs such as Spring Integration, Apache Camel, or Mule ESB. Event flows in these open source integration hubs are typically implemented through Java code or a DSL (domain-specific language). For more sophisticated mediation and orchestration, you can use BPEL (business process execution language) coupled with a BPEL engine such as the open source Apache ODE. BPEL is a standard XML-like language that describes the data and steps required for processing an initial event. For very large applications requiring much more sophisticated orchestration (including steps involving human interactions), you can implement the event mediator using a business process manager (BPM) such as jBPM.

Understanding your needs and matching them to the correct event mediator implementation is critical to the success of any event-driven architecture using this topology. Using an open source integration hub to do very complex business process management orchestration is a recipe for failure, just as is implementing a BPM solution to perform simple routing logic.

他们提到 Spring 作为一种可能的实现 - 我从未使用过它，但是查看文档( here )我看到了回复 channel 的概念:

...when the service method returns a non-null value, the endpoint will attempt to send the reply message to an appropriate reply channel.

目标是发送一条或多条消息以进行异步处理，然后在结果返回时发送其他消息。我认为在模式级别，这些结果如何返回并不重要(函数回调、“响应”事件、Web API 调用等等)——这将取决于您的特定基础设施。

对我来说，这听起来很像 Saga 模式( link )。在这种情况下，Saga(或 Mediator)知道完成某个任务所需的步骤，并维护有关该任务进度的一些状态。

它触发要处理的命令并监听响应。当响应(事件)进入时，它会更新其状态，然后使用其状态来确定接下来需要触发什么命令。

这一直持续到 A) 过程完成，或 B) 过程中的一个步骤失败(在这种情况下，它可能会反转方向并开始触发补偿命令以“撤消”先前的操作)。

使用您引用的帖子中的下图，传奇/调解人的“想法”可能与......

重定位事件，因此触发更改地址命令并等待。

收到了 AddressChanged 事件。现在我已经更改了地址，但我还没有重新计算报价或更新声明，所以我会将它们发送出去(它们不冲突，因此将它们都发送)并等待。

收到 ClaimsUpdated 事件。在继续之前仍然需要重新计算，所以继续等待。

接收到 QuoteRecalced 事件。现在我已经更新了地址、重新计算了报价并更新了 claim ，我可以发送调整 claim 命令，然后等待。

... 等等。

您可能想要添加持久性(这样它可以在发生崩溃时从中断的地方继续)、幂等事件处理器(因此事件重放不会导致问题)和/或超时(不会一直卡在等待中)如果响应事件丢失/丢失)。