Events 如何在微服务体系结构中共享事件代码

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

我看到了可能的替代方案：

• 仅在触发事件的微服务中声明事件代码。让消费者微服务直接访问触发事件的微服务中声明的代码。在本例中，事件声明一次，但它在微服务之间创建了源代码依赖关系。。。这很糟糕

• 创建包含所有应用程序的所有事件代码的源文件（在所有MicroService之外）。此源文件由所有MicroService共享。在这种情况下，每个事件声明一次，但它为所有微服务创建了一个全局依赖项，这违反了单一责任原则。。。这很糟糕

你如何解决这个问题

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

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

在微服务体系结构中，我们希望能够独立地部署服务实例。要求所有服务一起关闭以协调消息模式中的更改，这有点忽略了要点。这反过来意味着我们需要为生产者和消费者对信息的理解不一致的情况设计合理的行为

实际上，这意味着

• 我们从不引入新的必填字段，只引入可选字段（带有记录的默认值）
• 忽略未识别的字段（但已转发）
• 可选字段的使用者知道在缺少预期字段时使用默认值
• 当无法满足这些约束时，您将引入一条新消息

如果您有消息契约，那么您就不会局限于共享同一运行时平台的微服务实现（因为同一契约的两个不同实现是等效的）

推荐阅读：

• ，特别是第2.6节，该节描述了公共合同的演变
• ，特别是“基于基本类型的版本控制”

---

微服务如何在您的体系结构上进行通信？你不能使用一些共享信息的消息总线吗？每个微服务都可以通过时间戳或其他唯一的相关信息与触发事件代码的队列通信，从而消除源代码依赖关系。是的，这正是我的问题。我用兔子。发布者和消费者微服务都需要知道事件代码（和有效负载），以便发布第一个事件并解码第二个事件。我认为，如果你想拥有一个真正有效的微服务体系结构，你应该拥有一个无共享体系结构，这意味着无论你现在拥有什么，都是处理它的最佳方式。我看不出您试图解决的问题。“创建一个包含所有应用程序的所有事件代码的源文件（在所有微服务之外）”——这是。微服务的松散耦合经常受到强调，因此对这样一个明显的矛盾感到担忧是很自然的。但当然，微服务必须作为一个系统进行通信。当事件定义它们之间的接口时，可以在公共源文件或库中共享这些公共接口定义。注意：每个微服务不必使用此事件文件/库的相同版本，因此它不会影响事件的演变。