我一直在阅读微服务和事件采购以及它如何将服务彼此分离。我不清楚有两个概念。首先，如果在微服务架构中，每个服务可以独立开发，我们如何解释服务间通信依赖性？
例如，如果服务A和服务B需要通信，A需要将事件发送到B需要监听并执行的中央总线，但这似乎会产生很多依赖性。现在，如果我正在开发服务B，我需要知道服务A可以生成的所有事件。此外，如果服务A添加任何新事件，服务B也需要更改以处理该新事件。所有这些似乎都会造成一种依赖性的噩梦，而且似乎无法真正“独立”地开发每项服务。
其次，如何在API网关或流程管理器级别处理请求/响应类型方案？如果顶级请求触发了一堆级联或相互依赖的事件，这些事件需要在将响应返回给调用者之前进行处理，那么这种情况是否适合微服务呢？
答案 0 :(得分：1)
事件采购不是事件驱动的架构。从理论上讲，您可以在不使用事件进行集成的生态系统中拥有内部事件源的有界上下文/微服务。您还可以通过事件进行非事件源BC集成。
事件驱动是asynchronous microservice integration的一种。同步集成也是可能的。我不知道你在问题中是否隐含地将基于事件的集成与之形成对比，但在两种情况下，你必须管理的依赖类型非常相似。
所以，我没有想到的依赖噩梦，至少不会超过子系统A依赖于子系统B时的典型情况。
现在，如果我正在开发服务B，我需要知道所有事件 服务A可以生成
不，你只订阅你感兴趣的那些。
此外，如果服务A添加任何新事件，服务B也需要更改 为了处理这个新事件。
同样，如果你对它不感兴趣，那就不行了。
所有这些似乎都会造成依赖性的噩梦，而且看起来像你 无法“独立”真正发展每项服务。
只要一项服务依赖另一项服务，您显然无法独立开发每项服务。您可能过度解释了通过事件允许松散耦合的“独立性”。
答案 1 :(得分：0)
首先，如果在微服务架构中，每个服务可以独立开发，我们如何解释服务间通信依赖性？
消息 - 您通过专注于它们交换的消息来打破服务之间的直接耦合，并专注于向前和向后兼容的架构的更改策略（以便旧服务可以从新服务中读取消息）。 / p>
Greg Young在他的event versioning一书中写到了这些想法。
如果顶级请求触发了一堆级联或相互依赖的事件，这些事件需要在将响应返回给调用者之前进行处理，这是否适合微服务？
实际上，只要您将陈旧数据合并到您的设计中，就没问题了。
从根本上说，对查询的响应需要一段时间才能到达客户端;除非你在数据传输过程中锁定所有作者，否则很有可能真正的＆＃34;真相＆＃34;当数据包在飞行中时，系统会发生变化。
所以你没有指定查询描述状态＆＃34;现在＆＃34;，而是查询描述了过去某个时间的状态。因此，如果您向服务A发送查询请求，并且结果包含来自服务B的数据，那么查询结果将包括A的某个特定时间的B数据的缓存副本。
因此，对于发送到A的请求，A对B获取数据的查询是异步的。如果刷新的数据及时从B到达以回答查询，那么很好 - 您可以回答一些更新的陈旧数据
是的，可能会发生C将更改写入B，获得确认，然后查询A ...并获取不包含已经写入和确认的更改的响应。
所以你建立了没有通用时钟的解决方案。
在第一个问题上，它似乎是服务B的开发者，我需要知道可以从服务A触发的所有事件，如果添加了新事件，我会持续依赖。< / p>
并非所有事件。您需要一个通用格式（如avro，或json或协议缓冲区），以便可以反序列化事件表示，并且您需要消费者能够识别它关注的事件，但消费者没有＆＃ 39; t识别可以通过单个默认处理程序。