ala*_*udi 9 architecture event-driven-design microservices
我努力理解如何使用可以支持同步请求的事件源来设计一个由事件驱动的后端。据我所知，要利用事件溯源，您必须开发系统来对事件做出反应，以便在必要时可以重播它们以重新创建您的状态。为此，这意味着我们正在尝试将事件触发器和事件处理程序解耦。
如果我们假设一个客户端发送请求更新某些数据的情况，我们如何在使用事件驱动系统时适应这种同步请求/响应模型？您会说以下步骤是以事件驱动方式处理请求的正确方法吗：
在 API 网关或网络边缘的某些服务接收网络请求，并发出表示此请求的事件。此时API网关会挂起等待。
发出的事件由事件存储捕获并记录
具有处理更新的业务逻辑的服务在订阅事件存储时捕获事件。如果它能够处理更新，则会产生成功事件，如果无法处理则产生错误事件。
API 网关接收它正在等待的成功或错误事件之一，并最终将响应发送回浏览器。
我认为以上对分离关注点做了很多工作，但我怀疑这是否是通过接受来自外部客户端的请求的系统启用事件源的方式。
Bra*_*rby 15
你混淆了几个术语和想法，保持分开很重要。一旦你在脑海中将它们分开，一切都应该清楚了。
事件溯源和事件驱动架构是两个不同的概念。事件溯源意味着您将所有更改保存在 Event Store 中，并获取该实体的当前状态，您可以将所有事件相加。这个概念涉及状态的存储，而不是请求的处理。我认为您在这个问题中指的是事件驱动架构。将这些想法分开的必要性很快就会变得清晰。
在事件驱动架构中，您需要将两个想法分开。有来自 UI 或外部系统的请求，要求对数据进行一些更改；这是一条消息或请求。消息处理程序（在 CQRS 中通常称为命令）处理请求并将其作为无效拒绝或对系统中的实体进行适当的更改。然后，对这些实体的更改将作为事件存储在事件存储中。Event Store 中的事件应该只包含更改的数据，而不是实体的所有属性。如果命令更改了多个实体，则多个事件将写入事件存储。
系统可以拥有事件存储的侦听器（或订阅者），并且可以启动其他业务逻辑以响应实体的变化。这些更改以最终一致的方式异步运行。
考虑到所有这些，我们可以讨论事件驱动架构如何处理同步和异步事件。请记住，EDA 是为异步处理和最终一致性而设计的，因此使其同步需要一些额外的工作。
使用上面的 4 个步骤，我们得到了这个
第 1 步：不更改您的描述逻辑。网关接收请求（不是事件）并等待。
第二步：有些开发者喜欢存储传入的请求用于模式分析等，但没有必要成功处理请求。
在最终一致的架构中，业务逻辑将对传入的请求进行一些基本验证，如果看起来不错，则发回操作成功的确认。请求将被放入队列并在方便时处理。如果遇到错误，稍后会通知用户。
但是由于您的系统是同步的，API（您称为“API 网关”）将直接调用负责处理业务逻辑的服务——命令。
第 3 步：请求由命令处理，验证请求并对实体进行任何必要的更改。为所有实体更改创建事件（每个实体一个事件）。
第 4 步：该命令向 API 同步返回成功或失败值，API 将其返回给调用方。请注意，这应该是 async/await 调用，而不是来自 API 的阻塞调用。对于 API 和用户来说，它看起来仍然是一个同步过程。