关于事件驱动拓扑中的中介者
About the Mediator in Event-Driven Topology
我正在阅读这篇名为 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），还是有另一个侦听器在某处等待异步响应？
关于如何从架构的角度实现这一点有什么想法吗？
在我看来，他们只是没有绘制从事件处理器返回的事件，也许是因为它们可能不是具体的事件（比如某种回调）或者因为它们可能不是 normal 事件（可能只返回到中介并且对任何其他订阅者不可见的事件），具体取决于您使用什么作为中介。这部分似乎表明了类似的东西：
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) 我看到了回复通道的概念：
...when the service method returns a non-null value, the endpoint will attempt to send the reply message to an appropriate reply channel.
目标是发送一条或多条消息进行异步处理，然后在结果返回时发送其他消息。我认为在模式层面上这些结果如何返回并不重要（函数回调、'response' 事件、网络 API 调用等等）——这将取决于你的特定基础设施。
对我来说，这听起来有点像 Saga 模式 (link)。这样，Saga（或 Mediator）知道完成某些任务所需的步骤并维护有关该任务进度的某些状态。
它触发要处理的命令并侦听响应。当收到响应（事件）时，它会更新其状态，然后使用其状态来确定接下来需要触发哪些命令。
这一直持续到 A) 流程完成，或 B) 流程中的一个步骤失败（在这种情况下，它可能会反转方向并开始向 'undo' 先前的操作发出补偿命令）。
使用您引用的 post 中的下图，saga/mediator 的 "thoughts" 可能沿着...
- 重定位事件，因此触发更改地址命令并等待。
- 收到地址更改事件。现在我已经更改了地址，但我还没有重新计算报价或更新声明，所以我将把它们发送出去（它们不冲突，所以都发送它们）并等待。
- 收到 ClaimsUpdated 事件。在继续之前还需要重新计算，所以请继续等待。
- 收到 QuoteRecalced 事件。现在我已经更新了地址、重新计算了报价并更新了声明，我可以发送 Adjust Claims 命令，然后等待。
...等等。
您可能想要添加持久性（这样它可以在发生崩溃时从中断的地方继续）、幂等事件处理器（这样事件的重播不会引起问题）、and/or 超时（如果响应事件得到 missed/lost，就不会永远等待）。
我想你已经在图表上找到了答案：
初始事件步骤（红色）是关键。每个事件处理器都会产生一个事件，该事件进入事件队列，然后到达事件调解器。
该架构是事件驱动和异步的。单个事件队列处理事件调解器的路径。由于这是将事件放入事件调解器的唯一方法，显然，任何想要将事件发送到调解器的东西都需要使用此路径。
在某些时候，在某个事件发生后，事件调解器将声明操作成功完成，并且不会向事件处理器分派更多事件。
虽然，我必须说，你是对的，这在文章中没有明确说明。我想这会在他们正在预览的书中得到更好的阐明。
我正在阅读这篇名为 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），还是有另一个侦听器在某处等待异步响应？
关于如何从架构的角度实现这一点有什么想法吗？
在我看来，他们只是没有绘制从事件处理器返回的事件，也许是因为它们可能不是具体的事件（比如某种回调）或者因为它们可能不是 normal 事件（可能只返回到中介并且对任何其他订阅者不可见的事件），具体取决于您使用什么作为中介。这部分似乎表明了类似的东西：
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) 我看到了回复通道的概念：
...when the service method returns a non-null value, the endpoint will attempt to send the reply message to an appropriate reply channel.
目标是发送一条或多条消息进行异步处理，然后在结果返回时发送其他消息。我认为在模式层面上这些结果如何返回并不重要（函数回调、'response' 事件、网络 API 调用等等）——这将取决于你的特定基础设施。
对我来说，这听起来有点像 Saga 模式 (link)。这样，Saga（或 Mediator）知道完成某些任务所需的步骤并维护有关该任务进度的某些状态。
它触发要处理的命令并侦听响应。当收到响应（事件）时，它会更新其状态，然后使用其状态来确定接下来需要触发哪些命令。
这一直持续到 A) 流程完成，或 B) 流程中的一个步骤失败（在这种情况下，它可能会反转方向并开始向 'undo' 先前的操作发出补偿命令）。
使用您引用的 post 中的下图，saga/mediator 的 "thoughts" 可能沿着...
- 重定位事件，因此触发更改地址命令并等待。
- 收到地址更改事件。现在我已经更改了地址，但我还没有重新计算报价或更新声明，所以我将把它们发送出去（它们不冲突，所以都发送它们）并等待。
- 收到 ClaimsUpdated 事件。在继续之前还需要重新计算，所以请继续等待。
- 收到 QuoteRecalced 事件。现在我已经更新了地址、重新计算了报价并更新了声明，我可以发送 Adjust Claims 命令，然后等待。
...等等。
您可能想要添加持久性（这样它可以在发生崩溃时从中断的地方继续）、幂等事件处理器（这样事件的重播不会引起问题）、and/or 超时（如果响应事件得到 missed/lost，就不会永远等待）。
我想你已经在图表上找到了答案：
初始事件步骤（红色）是关键。每个事件处理器都会产生一个事件，该事件进入事件队列，然后到达事件调解器。
该架构是事件驱动和异步的。单个事件队列处理事件调解器的路径。由于这是将事件放入事件调解器的唯一方法，显然，任何想要将事件发送到调解器的东西都需要使用此路径。
在某些时候，在某个事件发生后，事件调解器将声明操作成功完成，并且不会向事件处理器分派更多事件。
虽然，我必须说，你是对的，这在文章中没有明确说明。我想这会在他们正在预览的书中得到更好的阐明。