EDA中基于事件源的微服务通信

Question

我一直在读关于微服务和事件来源的文章，以及它是如何将服务从另一个服务中分离出来的。有两个概念我不清楚。首先，如果在微服务体系结构中，每个服务都可以独立开发，我们如何解释服务间的通信依赖？

例如，如果服务A和服务B需要通信，那么A需要将一个事件发送到一个中央总线，而B需要监听该事件并根据该事件采取行动，但这似乎会产生很多依赖关系。现在，如果我正在开发服务B，我需要知道服务A可以生成的所有事件。此外，如果服务A添加了任何新事件，那么服务B也需要更改以处理该新事件。所有这些似乎都造成了一个依赖的噩梦，并且似乎您无法真正地“独立”开发每个服务。

其次，请求/响应类型的场景是如何在API网关或流程管理器级别处理的？如果顶层请求触发了一组级联或相互依赖的事件，在向调用方返回响应之前需要处理这些事件，那么这种场景是否很适合微服务？

Answer 1

首先，如果在微服务体系结构中，每个服务都可以独立开发，我们如何解释服务间的通信依赖？

消息-通过集中于服务之间交换的消息来打破服务之间的直接耦合，并集中于模式的前后兼容的更改策略（以便旧的服务可以从新的服务中读取消息）。

Greg Young在他的《事件版本控制》一书中写到了这些想法。

如果顶层请求触发了一组级联或相互依赖的事件，在向调用方返回响应之前需要处理这些事件，那么这种场景是否很适合微服务？

实际上，只要您将过时的数据纳入到您的设计中，这是很好的。

从根本上说,对查询的响应需要时间传送到客户端；除非您在数据传输过程中锁定所有Writer，否则系统的“真相”很有可能在数据包传输过程中发生了变化。

因此，您不指定查询描述“现在”的状态，而是指定查询描述过去某个时间的状态。因此，如果您向服务a发送一个查询请求，结果包括来自服务B的数据，那么查询结果将包括a在某个特定时间缓存的B数据副本。

因此A对B的查询是异步的，而对于发送给A的请求是异步的。如果更新的数据及时从B到达，以回答查询，那就太好了--你回答的是一些新鲜的陈旧的数据。

是的，可能会发生这样的情况：C向B写入一个更改，得到一个确认，然后查询a。并返回一个不包括已写入和确认的更改的响应。

所以您在解决方案中加入了这样的内容：没有通用时钟。

对于第一个问题，作为服务B的开发人员，我需要知道服务a可以激发的所有事件，并且如果添加了新的事件，我将有一个持续的依赖关系。

不是所有事件。您需要一种通用格式（如avro或json或协议缓冲区），以便事件表示可以反序列化，并且您需要使用者能够识别它所关心的事件，但是使用者不识别的事件可以通过一个默认处理程序。

Answer 2

事件源不是事件驱动的体系结构。理论上，您可以在不使用事件进行集成的生态系统中拥有一个内部事件源的有界上下文/微服务。您还可以通过事件进行非事件源BC的集成。

事件驱动是异步微服务集成的一种。同步集成也是可能的。我不知道这是否是您在问题中隐含地对比基于事件的集成的原因，但您必须管理的依赖关系在这两种情况下是非常相似的。

所以，我想不出任何依赖的恶梦，至少不会比子系统a依赖于子系统B的情况更糟。

现在，如果我正在开发服务B，我需要知道服务A可以生成的所有事件

不，你只订阅你感兴趣的。

此外，如果服务A添加了任何新事件，那么服务B也需要更改以处理该新事件。

再说一遍，如果你对它不感兴趣的话。

所有这些似乎都造成了一个依赖的噩梦，并且似乎您无法真正地“独立”开发每个服务。

一旦一个服务依赖于另一个服务，您显然无法独立地开发每一个服务。您可能过度理解了通过事件的松散耦合所允许的那种“独立性”。