没有共享事件库的微服务之间基于事件的通信？答案

【问题标题】：Event-Based Communications Between Microservices without a Shared Event Libary?没有共享事件库的微服务之间基于事件的通信？
【发布时间】：2020-02-23 20:51:40
【问题描述】：

我正在学习微服务。

一方面，文献建议对需要协作处理 saga 或对其他服务发布的事件采取行动的微服务使用异步事件发布。

另一方面，同样的文献建议不要使用共享库来定义公共事件，因为这会通过该事件库耦合微服务。

我在吃疯狂的药吗？如果这些微服务依赖于这些事件，它们难道不与它们耦合吗？如果是这样，在两个（甚至更多）不同的地方用相同的定义对完全相同的事件进行编码有什么好处？这不是完全违反了 DRY 原则吗？

我开始闻到以缩写 BS 开头的代码气味。有人能帮我喝下剩下的koolaid吗？还是我刚刚看到皇帝脱了衣服一秒钟？

【问题讨论】：

标签： domain-driven-design microservices cqrs event-sourcing

【解决方案1】：

如果是这样，在两个（甚至更多）不同的地方用相同的定义对完全相同的事件进行编码有什么好处？

可能有很多优势——微服务可以使用不同的语言来实现。或者使用相同的语言，但数据的内存表示不同，以满足特定需求。甚至是内存表示中的“相同”，但版本不同，因为它们处于不同的部署计划中。

在服务的实现之间分担准备消息传递库的工作本质上并没有错。但这应该是一种选择，而不是一种要求。特别是，如果共享实现受到阻碍，团队始终可以选择替换库。

同意消息将使用 UTF-8 编码的 JSON 文档的两个服务不应该被要求使用相同的解析器——解析器的选择是一个实现细节。耦合是针对模式（关于消息中字节语义的协议），而不是实现。

【讨论】：

使用相同的事件库不仅是为了节省劳动力，而且是为了提高正确性并消除错误，您提到的其中之一是：尝试通信的不同微服务之间的协议版本不匹配。当然，如果它是一个由 .NET 服务和 Java 服务组成的异构系统，那么一个库不能同时为两者定义事件结构。但是 .NET 服务可以共享一个，Java 服务也可以，这样会更好，即使库只是接口，将实现推迟到消费者。文档贬低了这一点。我叫 BS。
很高兴听到有人“保持真实”并说是的，Event 对象被序列化为 JSON。我不知道有多少项目在这种意识形态的重压下被压垮了。
感谢您抽出宝贵时间回答问题。我同意“在服务的实现之间分担准备消息传递库的工作本质上并没有错。”我只是不同意这样做的最佳理由只是为了节省劳动力。

【解决方案2】：

如果您将事件视为纯数据对象，则不需要库来处理它们 - 除了通用消息传递和序列化/反序列化代码。

微服务的重点是要有独立的开发周期，所以一旦你引入公共库，你就开始做一个“分布式单体”。此库中的任何更改都将导致重新部署所有微服务。

如果没有特定于事件的库，则唯一的依赖项是向它介绍来自另一个微服务的特定事件结构的知识。好吧，这是一个必要的邪恶。

【讨论】：

谢谢。我的反驳：是的，必须知道来自其他微服务的特定事件和事件的内容。鉴于此，我们可以通过将其提交到代码中来形式化该知识，或者将其保留为轶事；根据我对语音和文档损失的了解，这总是容易出错。我的另一点是，为什么不一次重新部署所有微服务呢？ CI 让这一切变得简单。是的，微服务孤立存在的虚构可能会有所帮助，但也可能很繁琐。专家知道什么时候应该改变规则。