vert.x 事件总线能否取代对 Kafka 的需求？
Posted
技术标签:
【中文标题】vert.x 事件总线能否取代对 Kafka 的需求？【英文标题】：can vert.x event bus replace the need for Kafka? 【发布时间】：2019-05-19 14:25:27 【问题描述】：我正在评估 vert.x 框架，看看我是否可以减少使用 Spring Boot 开发的微服务之间基于 Kafka 的通信。
问题是： 我可以更换吗 1. 带有 vert.x 事件总线的 Kafka 和 2. 带有基于vert.x的verticles的spring boot微服务
任何指针都会有很大帮助。
提前致谢。
【问题讨论】：
【参考方案1】：要快速回答，我会说这取决于您的需求。
是的，事件总线是一种使用异步和非阻塞范式处理微服务 Verticle 之间本地通信的好方法。
但在某些情况下您可能需要：
处理一些常见的企业模式，如重放机制、消息持久性、事务读取 能够按时间顺序处理某种消息 处理并非全部使用相同框架/工具包甚至编程语言编写的多种微服务之间的通信 处理可靠性、弹性和 当您的所有消费者/微服务/verticles 死亡时故障恢复 处理消费者/微服务/垂直的动态水平可扩展性和监控 能够使用部署在多数据中心和多区域中的单个集群在这些情况下，我更愿意选择 Apache Kafka，而不是原生事件总线或旧的、令人着迷的 JMS 兼容系统。
不禁止根据自己的实际需求在同一个微服务架构中同时使用 eventbus 和 kafka。例如，您可以让一个 kafka 消费者组读取一个 kafka 主题来处理扩展、监控、故障恢复和回复机制，然后通过事件总线处理您的子 Verticle 之间的通信。
我将稍微澄清一下可扩展性和监控部分，并解释为什么我认为使用 Kafka 通过原生事件总线和使用 vert.x 的集群模式来处理它更简单：Kafka 允许我们实时了解（ through JMX metrics 和 describe 命令）：
因此，可以使用 ElasticStack 或 Prometheus+Grafana 解决方案来监控这些指标并使用它们来处理动态可扩展性（当您知道需要临时增加消费者数量时，例如根据滞后指标和分区数和主机的 cpu/ram/swap 指标）。
要回答第二个问题 vert.x 或 SpringBoot，我的回答不是很客观，但我会投票支持 vert.x，因为它的performances on the JVM，尤其是它的简单性。我有点厌倦了 Spring 工厂和它的大抽象层，这些抽象层隐藏了很多问题，在大量注释下触发了 AOP。
此外，在微服务的 Java 世界中，SpringBoot 还有其他替代方案，例如 Microprofile 的不同实现（例如thorntail project）。
【讨论】：
【参考方案2】：事件总线不是持久的。您应该将它用于快速的垂直到垂直通信，更一般地用于调度事件，您知道如果发生崩溃，您可以释放它们。
Kafka 流是持久的，您应该在那里发送事件，因为您希望其他（可能是非 Vert.x）应用程序使用它们，和/或因为您希望确保这些事件不会丢失，以防万一失败。
反应式（阅读“可扩展和容错”）Vert.x 应用程序通常使用事件总线和一些可复制的消息传递系统（如 AMQP / Kafka / 等）的组合。 p>
【讨论】：
【参考方案3】：关于问题：
我可以用基于 vert.x 的 Verticle 替换 Spring Boot 微服务吗？
是的，当然，虽然两者有不同的编程模型。
如果您想要一种更先进的方法并使用 Spring 来构建应用程序，同时使用 Vert.x 来提高 I/O 和事件处理的资源效率，那么您可以混合使用它们，请参阅 https://github.com/vert-x3/vertx-examples/tree/master/spring-examples 示例。
【讨论】：
在我的 POV 中使用 Spring 在 Verticle 中破坏了 micro 服务的整个想法【参考方案4】：看看 Quarkus 框架：在研讨会部分，您会发现 Vert.x 和 Apache Kafka 结合在一起！
【讨论】：
你能详细说明一下吗，quarkus 是否提供事件总线 @letsdebugtheissue quarkus 提供 vert.x 并使其更容易与 GraalVM 一起使用，所以是的，它通过提供 vert.x 来提供事件总线。它还提供了扩展，使与 Kafka 的集成更容易（当您使用 kafka 时，大多数时候您将不再需要 eventbus）以上是关于vert.x 事件总线能否取代对 Kafka 的需求？的主要内容，如果未能解决你的问题，请参考以下文章