同步关注的事件来源 [英] Event sourcing for synchronous concerns
问题描述
我努力了解如何设计可以使用支持同步请求的事件源进行事件驱动的后端.据我了解，要利用事件源，您必须开发系统以对事件做出反应，以便在必要时可以重播事件以重新创建状态.为此，这意味着我们正在尝试使事件触发器和事件处理程序脱钩.
I struggling to understand how I can design a backend that is event driven using event sourcing that can support synchronous requests. From what I understand, to take advantage of event sourcing, you must develop the system to react to events so that you can replay them if necessary to recreate your state. To do so, this means that we are trying to decouple event triggers and event handlers.
如果我们假设客户端发送请求更新某些数据的情况，那么在使用事件驱动系统时，我们如何适应这种同步请求/响应模型?您是否可以说以下步骤是以事件驱动的方式处理请求的正确方法:
If we assume a case in which a client is sending a request to update some data, how can we accomodate this synchronous request/response model while using event driven systems? Would you say the below steps are the correct way to handle requests in an event driven manner:
-
在API网关或网络边缘的某些服务处接收网络请求，并发出代表该请求的事件.此时，API网关将挂起并等待.
Receive network request at API gateway, or some service at edge of network, and emit an event that represents this request. The API gateway at this point will hang and wait.
发出的事件被事件存储捕获并记录
The emitted event is captured by the event store and is logged
具有业务逻辑以处理更新的服务在订阅事件存储时捕获事件.如果能够处理更新，它将产生成功事件；如果无法处理更新，则将产生错误事件.
A service with the business logic to handle the update captures the event as it is subscribed to the event store. It produces a success event if it was able to handle the update or an error event if it was unable to do so.
API网关正在接收它正在等待的成功或错误事件之一，最后将响应发送回浏览器.
the API gateway is receives either one of success or error events it was waiting for and finally sends back the response to the browser.
我认为上述方法可以极大地分离关注点，但是我怀疑这是否可以通过接受外部客户端请求的系统启用事件来源.
I think the above does a great deal to separate concerns but I'm skeptic if this is the way of enabling event sourcing with a system that accepts requests from an external client.
推荐答案
您正在混淆几个术语和构想，这对于保持分隔很重要.一旦将它们分开，一切都应该变得清晰起来.
You’re mixing up several terms and ideas, which are important to keep separate. Once you’ve separated those in your head, all should become clear.
事件源和事件驱动架构是两个不同的想法.事件来源意味着您将对实体的所有更改都保留在事件存储中，并且要获取该实体的当前状态，请将所有事件加起来.这个概念涉及状态的存储，而不是请求的处理.我认为您在这个问题中指的是事件驱动架构.将这些想法分开的需求很快就会变得很清楚.
Event Sourcing and Event Driven Architecture are two different ideas. Event Sourcing means you keep all changes to an entity in an Event Store and to get the current state of that entity you add up all the events. This concept relates to storage of state, not processing of requests. An Event Driven Architecture is what I think you’re referring to in this question. The need to keep these ideas separate will become clear in a moment.
在事件驱动的体系结构中，您需要分开两个想法.用户界面或外部系统发出了对数据进行一些更改的请求；这是一条消息或请求.消息处理程序(在CQRS中通常称为命令)处理请求，然后将其拒绝为无效请求，或者对系统中的实体进行适当的更改.然后，将这些实体的更改作为事件存储在事件存储中.事件存储中的事件应仅包含已更改的数据，而不应包含实体的所有属性.如果该命令更改了多个实体，则将一个以上事件写入事件存储.
In an Event Driven Architecture there are two ideas you need to keep separate. There’s the request coming in from a UI or external system to make some change to the data; this is a message or request. The message handler (usually called a command in CQRS) processes the request and either rejects it as invalid or makes appropriate changes to the entities in the system. The changes to those entities are then store as Events in the Event Store. The events in the Event Store should only contain the data that changed, not all the properties of the entity. If more than one entity is changed by the command, more than one event will be written to the event store.
系统可以具有事件存储的侦听器(或订阅者)，并且可以响应于实体中的更改而启动其他业务逻辑.这些更改将以最终一致的方式异步运行.
The system can have listeners (or subscribers) to the event store and other business logic can be launched in response to a change in an entity. These changes are run async in an eventually consistent manner.
考虑到所有这些，我们可以讨论事件驱动架构如何处理同步和异步事件.请记住，EDA是为异步处理和最终的一致性而设计的，因此使其同步是额外的工作.
With all this in mind, we can talk about how an Event Driven Architecture handles both synchronous and async events. Keep in mind that EDA is designed for asynchronous processing and eventual consistency so making it synchronous is a bit of extra work.
使用上面的4个步骤，我们得到了
Using your 4 steps above we get this
第1步:更改描述逻辑.网关接收到请求(不是事件)并等待.
Step 1: No changes to the logic of your description. The gateway receives the request (not an event) and waits.
第2步:一些开发人员喜欢存储传入的请求以进行模式分析等，但不必成功处理该请求.
Step 2: Some developers like to store the incoming requests for pattern analysis and such, but it is not necessary to successfully process the request.
在最终一致的体系结构中，业务逻辑将对传入请求进行一些基本验证，如果看起来不错，则发送回确认操作成功的确认.该请求将被放入队列中，并在方便时进行处理.如果遇到错误，则会在以后通知用户.
In an eventually consistent architecture the business logic would do some basic validation of the incoming request and if it looks good send back a confirmation that the operation was successful. The request would be put on a queue and handled when convenient. If errors are encountered, the user is notified later.
但是，由于您的系统是同步的，因此API(您称为"API网关")将直接调用负责处理业务逻辑的服务-命令.
But since your system is synchronous, the API (what you called the 'API Gateway') would directly call the service responsible for handling the business logic – the command.
第3步:通过命令处理请求，验证请求并对实体进行必要的更改.为所有实体更改创建事件(每个实体一个事件).
Step 3: The request is handled by the command, validating the request and making any necessary changes to entities. Events are created for all entity changes (one event per entity).
第4步:该命令将成功或失败值同步返回给API，然后将其返回给调用方.请注意，这应该是异步/等待调用，而不是来自API的阻止调用.对于API和用户来说，它仍然看起来像一个同步过程.
Step 4: The command returns a success or failure value synchronously to the API, which returns it to the caller. Note that this should be an async/await call, not a blocking call from the API. To the API and the user it still looks like a synchronous process.
这篇关于同步关注的事件来源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
