微服务共享对象答案

【问题标题】：Microservices shared objects微服务共享对象
【发布时间】：2017-09-07 09:28:29
【问题描述】：

目前我们正在从我们的单体构建一个面向微服务的应用程序。

我们面临的问题是如何在服务之间发送和接收对象，同时保持服务独立。

问题：假设我们有一个 EventService 和一个 NotificationService。 EventService 生成一个事件，将其序列化（json/java？）并在 ActiveMQ 主题上发布序列化对象。监听特定主题的 NotificationService 接收序列化对象并必须对其进行反序列化，因此需要知道 Event-Class。

解决两个服务共享 Event-Class 问题的好方法是什么？我应该引入一个只包含 Event-Class 的新项目吗？我在这里看到的问题是这可能导致两种情况：

共享项目变得臃肿，并且包含的类比包括它在内的每个服务都需要更多。
我将为每两个共享某种类型对象的服务创建一个额外的项目，这会导致随着服务数量的增加而产生巨大的开销。

【问题讨论】：

“微服务宗教”表示没有依赖关系，因此一方可以在较新版本中生成例如更多字段（以及此引导文本格式序列化）。就我个人而言，你的想法很好，我可以将第三个项目命名为“Protocols”或“ProtocolXyz”（这违反了 ms 的宗教信仰）。问题：两个ms都将由独立小组开发？（“两个披萨队”）巨石并不完全是邪恶的
您可以在微服务之间共享一个主要包含 POJO 的 API，这将有助于进出 ActiveMQ 主题的序列化/反序列化过程
每个服务对 JSON 内容的含义都有自己的解释。因此，他们将拥有自己的相关对象。如果JSON（即Event）的内容在服务之间具有相似的含义，那么我会建议从设计层面来看耦合太紧了。
感谢您的回答，我们还没有建立不同的团队，因为我们的应用程序过于单一。我认为 API 方法会导致我上面描述的类似问题。 @jr593 在考虑解决方案时我也想到了这一点，但我越深入这个方向，我就越能看到另一个巨石出现。

标签： java shared-libraries messaging microservices dry

【解决方案1】：

遵循这个经验法则：

对于企业应用程序和复杂对象，创建第三个项目（API 项目），并将其作为依赖项在您的服务之间共享。

对于简单和自我描述对象，在您的每一项服务中使用相同对象的“副本”；请注意，这很强大，因为 POJO 不需要相同；

我刚刚分享了示例代码here

【讨论】：