architecture - 同步关注的事件来源

Question

我努力了解如何使用支持同步请求的事件源设计由事件驱动的后端。据我了解，要利用事件源，您必须开发系统以对事件使用react，以便在必要时可以重播事件以重新创建状态。为此，这意味着我们正在尝试使事件触发器和事件处理程序脱钩。

如果假设客户端正在发送更新某些数据的请求，那么在使用事件驱动的系统时，我们如何适应这种同步的请求/响应模型？您是否可以说以下步骤是以事件驱动的方式处理请求的正确方法:

在API网关或网络边缘的某些服务处接收网络请求，并发出代表该请求的事件。此时，API网关将挂起并等待。

发出的事件由事件存储捕获并记录在表中

具有业务逻辑以处理更新的服务在订阅事件存储时捕获事件。如果能够处理更新，它将产生成功事件；如果无法处理更新，则将产生错误事件。

API网关正在接收其正在等待的成功或错误事件之一，最后将响应发送回浏览器。

我认为以上内容可以很好地分离关注点，但是我怀疑这是否可以通过接受外部客户端请求的系统启用事件源。

Answer 1

您正在混淆几个术语和构想，这对于保持彼此独立很重要。一旦将它们分开，所有一切都应该变得清晰起来。
事件源和事件驱动架构是两个不同的想法。事件来源意味着您将对实体的所有更改都保留在事件存储中，并且要获取该实体的当前状态，请将所有事件加起来。这个概念涉及状态的存储，而不是请求的处理。我认为您在这个问题中指的是事件驱动架构。将这些想法分开的需求将很快变得清晰起来。
在事件驱动的体系结构中，您需要分开两个想法。用户界面或外部系统发出了对数据进行一些更改的请求；这是一条消息或请求。消息处理程序(在CQRS中通常称为命令)处理请求，然后将其拒绝为无效请求，或者对系统中的实体进行适当的更改。然后，将这些实体的更改作为事件存储在事件存储中。事件存储中的事件应仅包含已更改的数据，而不应包含实体的所有属性。如果命令更改了多个实体，则将一个以上事件写入事件存储。
系统可以具有事件存储的监听器(或订阅者)，并且可以响应于实体中的更改而启动其他业务逻辑。这些更改以最终一致的方式异步运行。
考虑到所有这些，我们可以讨论事件驱动架构如何处理同步和异步事件。请记住，EDA是为异步处理和最终的一致性而设计的，因此使其同步是一项额外的工作。
使用上面的4个步骤，我们得到了
第1步:更改描述逻辑。网关接收到请求(不是事件)并等待。
步骤2:某些开发人员喜欢存储传入的请求以进行模式分析等，但不必成功处理该请求。
在最终一致的体系结构中，业务逻辑将对传入的请求进行一些基本验证，如果看起来不错，则发送回确认操作成功的确认。该请求将被放入队列中，并在方便时进行处理。如果遇到错误，则稍后会通知用户。
但是由于您的系统是同步的，所以API(您称为“API网关”)将直接调用负责处理业务逻辑的服务-命令。
步骤3:该请求由命令处理，验证请求并对实体进行必要的更改。为所有实体更改创建事件(每个实体一个事件)。
步骤4:该命令将成功或失败值同步返回给API，然后将其返回给调用方。请注意，这应该是异步/等待调用，而不是来自API的阻止调用。对于API和用户来说，它仍然看起来像是一个同步过程。