如何在微服务架构中共享事件代码

时间:2019-03-08 09:53:32

标签: events design-patterns architecture domain-driven-design microservices

我正在研究“类似于微服务”的体系结构。每个微服务都可以向RabbitMQ触发一些事件。事件由事件代码标识。目前,触发的事件代码是在微服务内部声明的硬编码const字符串,该字符串会触发该事件。 我的问题是,每个要订阅此事件的微服务都必须复制此事件代码字符串。这很容易出错,尤其是在重命名事件代码时,因为预订此事件代码的所有微服务都需要相应地进行更改……这是非常糟糕的。

我看到了可能的替代方法:

  • 仅在触发事件的微服务中声明事件代码。让使用者微服务直接访问触发事件的微服务中声明的代码。在这种情况下,该事件仅被声明一次,但是会在微服务之间创建源代码依赖关系……这很糟糕。

  • 创建一个源文件(在所有微服务之外),其中包含所有应用程序的所有事件代码。此源文件由所有微服务共享。在这种情况下,每个事件仅声明一次,但会为所有微服务创建一个全局依赖关系,这违反了单一责任原则……这很糟糕。

您如何解决这个问题?

1 个答案:

答案 0 :(得分:1)

  

目前,触发的事件代码是在微服务内部声明的硬编码const字符串,该字符串会触发该事件。我的问题是,每个要订阅此事件的微服务都必须复制此事件代码字符串。这很容易出错,尤其是在重命名事件代码时,因为预订此事件代码的所有微服务都需要相应地进行更改……这是非常糟糕的。

事件是消息。我们用来管理消息演化的所有约束条件也都适用于事件。

在微服务架构中,我们希望能够彼此独立地部署服务实例。要求所有服务一起关闭以协调消息架构类型的更改会遗漏问题。反过来,这意味着我们需要针对生产者和消费者对消息的理解不一致的情况设计合理的行为。

实际上,这意味着类似

  • 我们从不引入新的必填字段,仅引入可选字段(具有记录的默认值)。
  • 无法识别的字段将被忽略(但会转发)
  • 可选字段的消费者知道使用默认值,以便在缺少期望字段时使用。
  • 如果无法满足这些约束条件,那么您将引入一条 new 消息。

如果您拥有消息合同,那么您就不会局限于共享同一运行时平台的微服务实现(因为同一合同的两个不同实现是等效的)。

推荐阅读:

相关问题