使用事件溯源在 EDA 中进行微服务通信
Microservice Communication in EDA using Event Sourcing
我一直在阅读有关微服务和事件溯源以及它如何将服务彼此分离的信息。有两个概念我不清楚。首先，如果在微服务架构中，每个服务都可以独立开发，我们如何考虑服务间的通信依赖？
例如，如果服务 A 和服务 B 需要通信，A 需要将事件发送到 B 需要监听和执行的中央总线，但这似乎会产生很多依赖关系。现在，如果我正在开发服务 B，我需要知道服务 A 可以生成的所有事件。此外，如果服务 A 添加任何新事件，服务 B 也需要更改以处理该新事件。所有这一切似乎都造成了依赖性的噩梦，而且您似乎无法真正开发每项服务 'independently'.
其次，如何在 API 网关或流程管理器级别处理 request/response 类型的场景？如果顶级请求触发了一堆级联或相互依赖的事件，需要在将响应返回给调用者之前处理这些事件，这种情况是否适合微服务？
First, if in a microservices architecture, each service can be developed independently how do we account for inter-service communication dependencies ?
消息 - 通过专注于它们交换的消息打破服务之间的直接耦合，并专注于向前和向后兼容的模式的更改策略（以便旧服务可以从新服务读取消息） .
Greg Young 在他 event versioning 的书中写下了这些想法。
If the top level request fires off a bunch of cascading or interdependent events which need to be handled before returning a response to the caller, is this a scenario suited well for microservices ?
其实没关系，只要您将过时的数据合并到您的设计中即可。
从根本上说，对查询的响应需要时间才能到达客户端；除非您在数据传输过程中锁定所有写入程序，否则系统的 "truth" 很有可能在数据包传输过程中发生变化。
因此您没有指定查询描述状态 "now"，而是指定查询描述过去某个时间的状态。因此，如果您向服务 A 发送查询请求，并且结果包括来自服务 B 的数据，那么查询结果将包括 A 在某个特定时间缓存的 B 数据副本。
因此，A 为获取数据而对 B 的查询与发送给 A 的请求是异步的。如果更新的数据及时从 B 到达以回答查询，那太好了——你用更新鲜的陈旧数据来回答。
是的，C 向 B 写入更改，获得确认，然后查询 A... 并取回不包括已写入和确认的更改的响应。
所以你构建了没有通用时钟的解决方案。
On the first question though, it seems as a developer of Service B, i would need to know all of the events that can be fired from Service A, and I would have a continual dependency if there are new events added.
并非所有活动。您需要一种通用格式（如 avro，或 json，或协议缓冲区），以便可以反序列化事件表示，并且您需要消费者能够识别它确实关心的事件，但事件消费者不认识可以落入一个默认处理程序。
事件溯源不是事件驱动架构。从理论上讲，您可以在不使用事件进行集成的生态系统中有一个内部事件源 Bounded Context/microservice。您还可以通过事件集成非事件源 BC。
事件驱动是asynchronous microservice integration的一种。同步集成也是可能的。我不知道这是否是您在问题中隐式对比基于事件的集成的原因，但在这两种情况下您必须管理的依赖类型非常相似。
所以，没有我能想到的依赖噩梦，至少不超过当子系统 A 依赖于子系统 B 时通常拥有的东西。
Now, if I am developing Service B, i need to know all of the events
that Service A can generate
不，您只订阅了您感兴趣的内容。
Also, if service A adds any new event, Service B also needs to change
in order to handle that new event.
再说一次，如果您对此不感兴趣，请不要这样做。
All of this seems to create a dependency nightmare, and seems like you
cannot truly develop each service 'independently'.
一旦一项服务依赖于另一项服务，您显然无法独立开发每项服务。您可能过度解读了 "independence" 事件允许的松散耦合。
我一直在阅读有关微服务和事件溯源以及它如何将服务彼此分离的信息。有两个概念我不清楚。首先，如果在微服务架构中，每个服务都可以独立开发，我们如何考虑服务间的通信依赖？
例如，如果服务 A 和服务 B 需要通信，A 需要将事件发送到 B 需要监听和执行的中央总线，但这似乎会产生很多依赖关系。现在，如果我正在开发服务 B，我需要知道服务 A 可以生成的所有事件。此外，如果服务 A 添加任何新事件，服务 B 也需要更改以处理该新事件。所有这一切似乎都造成了依赖性的噩梦，而且您似乎无法真正开发每项服务 'independently'.
其次，如何在 API 网关或流程管理器级别处理 request/response 类型的场景？如果顶级请求触发了一堆级联或相互依赖的事件，需要在将响应返回给调用者之前处理这些事件，这种情况是否适合微服务？
First, if in a microservices architecture, each service can be developed independently how do we account for inter-service communication dependencies ?
消息 - 通过专注于它们交换的消息打破服务之间的直接耦合，并专注于向前和向后兼容的模式的更改策略（以便旧服务可以从新服务读取消息） .
Greg Young 在他 event versioning 的书中写下了这些想法。
If the top level request fires off a bunch of cascading or interdependent events which need to be handled before returning a response to the caller, is this a scenario suited well for microservices ?
其实没关系，只要您将过时的数据合并到您的设计中即可。
从根本上说，对查询的响应需要时间才能到达客户端；除非您在数据传输过程中锁定所有写入程序，否则系统的 "truth" 很有可能在数据包传输过程中发生变化。
因此您没有指定查询描述状态 "now"，而是指定查询描述过去某个时间的状态。因此，如果您向服务 A 发送查询请求，并且结果包括来自服务 B 的数据，那么查询结果将包括 A 在某个特定时间缓存的 B 数据副本。
因此，A 为获取数据而对 B 的查询与发送给 A 的请求是异步的。如果更新的数据及时从 B 到达以回答查询，那太好了——你用更新鲜的陈旧数据来回答。
是的，C 向 B 写入更改，获得确认，然后查询 A... 并取回不包括已写入和确认的更改的响应。
所以你构建了没有通用时钟的解决方案。
On the first question though, it seems as a developer of Service B, i would need to know all of the events that can be fired from Service A, and I would have a continual dependency if there are new events added.
并非所有活动。您需要一种通用格式（如 avro，或 json，或协议缓冲区），以便可以反序列化事件表示，并且您需要消费者能够识别它确实关心的事件，但事件消费者不认识可以落入一个默认处理程序。
事件溯源不是事件驱动架构。从理论上讲，您可以在不使用事件进行集成的生态系统中有一个内部事件源 Bounded Context/microservice。您还可以通过事件集成非事件源 BC。
事件驱动是asynchronous microservice integration的一种。同步集成也是可能的。我不知道这是否是您在问题中隐式对比基于事件的集成的原因，但在这两种情况下您必须管理的依赖类型非常相似。
所以，没有我能想到的依赖噩梦，至少不超过当子系统 A 依赖于子系统 B 时通常拥有的东西。
Now, if I am developing Service B, i need to know all of the events that Service A can generate
不，您只订阅了您感兴趣的内容。
Also, if service A adds any new event, Service B also needs to change in order to handle that new event.
再说一次，如果您对此不感兴趣，请不要这样做。
All of this seems to create a dependency nightmare, and seems like you cannot truly develop each service 'independently'.
一旦一项服务依赖于另一项服务，您显然无法独立开发每项服务。您可能过度解读了 "independence" 事件允许的松散耦合。