vert.x 事件总线可以取代对 Kafka 的需求吗？

Question

我正在评估 vert.x 框架，看看我是否可以减少使用 spring boot 开发的微服务之间基于 Kafka 的通信。

问题是：我可以用 vert.x 事件总线替换 1. Kafka 和 2. 带有基于 vert.x 的 verticles 的 spring boot 微服务吗？

任何指针都会有很大帮助。

提前致谢。

Answer 1

为了快速回答，我会说这取决于您的需求。

是的，事件总线可以是使用异步和非阻塞范式处理微服务顶点之间本地通信的好方法。

但在某些情况下，您可能需要：

• 处理一些常见的企业模式，如重放机制、消息持久性、事务读取
• 能够按时间顺序处理某种消息
• 处理多种微服务之间的通信，这些微服务并非都是用相同的框架/工具包甚至编程语言编写的
• 当您的所有消费者/微服务/顶点都死亡时处理可靠性、弹性和故障恢复
• 处理消费者/微服务/垂直的动态水平可扩展性和监控
• 能够使用部署在多数据中心和多区域的单个集群

在这些情况下，我更愿意选择 Apache Kafka 而不是本机 eventbus 或旧的 fascioned JMS 兼容系统。

不禁止在同一个微服务架构中根据自己的实际需要同时使用eventbus和kafka。例如，您可以让一个 kafka 消费者组读取 kafka 主题来处理扩展、监控、故障恢复和回复机制，然后通过 eventbus 处理子垂直之间的通信。

我将澄清可扩展性和监控部分，并解释为什么我认为通过原生事件总线和 vert.x 集群模式使用 Kafka 处理它更简单：Kafka 允许我们实时了解（通过 JMX 指标）和describe命令）：

• 与未读消息数量相对应的主题的“滞后”
• 正在收听主题的每个组的消费者数量
• 每个消费者影响的主题的分区数
• 输入/输出指标

因此，可以使用 ElasticStack 或 Prometheus+Grafana 解决方案来监控这些指标并使用它们来处理动态可扩展性（当您知道需要临时增加消费者数量时，例如根据滞后指标和分区和主机的 cpu/ram/swap 指标）。

要回答 vert.x 或 SpringBoot 的第二个问题，我的回答不是很客观，但我会投票支持 vert.x，因为它在 JVM 上的表现，尤其是它的简单性。我有点厌倦了 Spring 工厂及其庞大的抽象层，这些抽象层将大量问题隐藏在引发大量 AOP 的大量注释下。

此外，在微服务的 Java 世界中，还有其他 SpringBoot 替代方案，例如Microprofile 的不同实现（例如thorntail 项目）。

Answer 2

事件总线不是持久的。您应该使用它来进行快速的 verticle 到 verticle 通信，更一般地，用于在您知道发生崩溃时可能会丢失事件的情况下分派事件。

Kafka 流是持久性的，您应该在那里发送事件，因为您希望其他（可能是非 Vert.x）应用程序使用它们，和/或因为您希望确保这些事件在发生故障时不会丢失。

反应式（读作“可扩展且容错”）Vert.x 应用程序通常结合使用事件总线和一些可复制消息系统（如 AMQP/Kafka 等）。