1

我想使用事件来传达我的服务。我将（内部）发布我所有的域事件并允许任何其他服务订阅它们。但是这种方法将这些服务结合在一起。我不再被允许更改我的事件。这甚至比本地耦合更糟糕，因为我不再了解我的消费者。这将开发/重构的能力限制在不可接受的范围内。我正在考虑对我的事件进行版本控制，以解决大多数问题。但是如何订阅版本化事件呢？引入将所有事件版本分组的通用接口，然后将侦听器中的事件向下转换为已接受的事件，这听起来并不是一个重要的解决方案。我还考虑将所有支持的事件版本发布到总线。根据定义，每个订阅者将只处理一个版本。我不希望我的域参与此事务，因此我需要构建一种基础设施侦听器，它将捕获的事件转换为其他版本。我在互联网上找不到任何关于该主题的内容，这让我不由自主地思考我是否完全错了:)

更新：经过深思熟虑，我不再想发布我的领域事件。我认为将内部服务机制暴露给外部世界是不可取的。它还可能违反某些域数据访问限制。我认为，要走的路是将我的领域事件映射到更多的corase集成事件。但我可能仍然需要对它们进行测试的方法:)

UPDATE2：经过一些咨询后，一个想法出现了。假设我们坚持集成事件的概念。此类事件可以被视为类型和事件 ID。所以外部监听器只关注事件类型。如果事件发生，那么侦听器将被提供事件 ID。这使侦听器能够从给定版本的流/总线/wtf 中获取真实事件。$eventsStore->get($eventGuid, $eventType, 'v27')例如（PHP 语法）

4

1 回答 1

2

我将（内部）发布我所有的域事件并允许任何其他服务订阅它们。

这是均匀驱动架构中的常见模式。我假设您在事件代理上发布事件，例如 Apache Kafka，并且消费者订阅事件代理上的主题。

我不再被允许更改我的事件。这甚至比本地耦合更糟糕，因为我不再了解我的消费者。这将开发/重构的能力限制到了不可接受的程度。我正在考虑对我的事件进行版本控制，以解决大部分问题。

不，已发布的合约应该进行版本控制，并且不能向其中添加向后兼容的更改。如果您需要不向后兼容的更改，则必须引入已发布合约的新版本- 只要有消费者，就保留旧版本。这与基于 REST 的接口没有什么不同——你必须履行你的合同。

/v1/orders使用 REST，您可以同时使用这两者/v2/orders。使用事件驱动架构，您可以使用两个主题，例如orders-v1和orders-v2- 这两个主题包含遵循模式的数据，例如Avro。

使用事件驱动架构，其中服务是解耦的（中间有一个代理），如果您添加一个较小的转换器，您实际上可以逐步淘汰旧的生产者，例如消费orders-v2并将事件转换为旧格式并发布它们on orders-v1- 所以两者v1都v2还在发布。

构建事件驱动的微服务是一本关于这方面的好书。

于 2020-09-01T15:26:47.783 回答