Axon 框架：微服务应该共享事件吗？答案

【问题标题】：Axon Framework: Should microservices share events?Axon 框架：微服务应该共享事件吗？
【发布时间】：2018-06-02 06:00:04
【问题描述】：

我们正在将单体架构迁移到更分布式的架构，因此我们决定使用 AxonFramework。

在 Axon 中，由于消息是一等公民，因此您可以将它们建模为 POJO。

现在我想知道，既然一个事件可以由一个服务分派并监听任何其他事件，我们应该如何处理事件分发。

我的第一个冲动是将它们作为 JAR 文件打包到一个单独的项目中，但这违反了微服务的规则，即它们不应共享实现。

欢迎提出任何建议。

【问题讨论】：

标签： axon

【解决方案1】：

拥有某种形式的“通用”模块肯定并不少见，尽管我个人会将该“通用”模块单独用于特定应用程序。

我通常会说您应该将您的命令/事件/查询视为您的应用程序的 API。因此，与其他项目共享事件结构可能是有益的，但不是实际的 POJO 本身。例如，您可以考虑在此用例中使用 ProtoBuf，在 ProtoBuf 中为您的事件描述了一个模式。

要考虑的另一件事是不要公开您的整个“事件 API”。通常，您会遇到一些非常细粒度的事件，这些事件是您环境中的其他（微）服务不感兴趣的。然而，总会有几个“非常重要的事件”，不同的说法是“里程碑事件”，其他人肯定是有兴趣。在某些情况下，这些里程碑事件不是您的领域的直接 POJO 跟踪，而是多个事件的累积。

因此，拥有一个服务来累积这些并发布另一个事件以通知其他服务的情况并不少见。累积这些细粒度的内部事件并发布里程碑事件作为对这些事件的响应通常更适合作为微服务架构中的事件 API。

所以这里有几个想法，希望它们能给你一些见解。我想对你的问题给出一个明确的解决方案，但这样的答案总是隐藏在“视情况而定”之后。

【讨论】：

【解决方案2】：

你是对的，“官方”规则是不共享模型。所以如果你有分布式开发团队，我会坚持下去。

但是，当我有解耦但由同一团队或高交互团队开发的组件时，我倾向于不严格遵循......

【讨论】：

那么在高度解耦和分布式的开发团队之间共享事件的解决方案是什么？
不要通过 lib 共享代码，而是使用 open-api 等代码生成器根据共享定义生成多孔事件。