vert.x事件总线可以代替Kafka的需要吗? [英] can vert.x event bus replace the need for Kafka?

问题描述

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

I am evaluating the vert.x framework to see if I can reduce the Kafka based communications between my microservices developed using spring boot.

问题是:我可以更换吗1.带有vert.x事件总线的Kafka和2.带有基于vert.x的Verticle的Spring Boot微服务

The question is: Can I replace 1. Kafka with vert.x event bus and 2. spring boot microservices with vert.x based verticles

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

Any pointers will be of great help.

谢谢.

推荐答案

要快速回答，我想这取决于您的需求.

To answer quickly, I would say it depends on your needs.

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

Yes, the eventbus can be a good way to handle natively communication between microservices verticles using an asynchronous and non-blocking paradigm.

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

But in some cases you could need:

• 处理一些常见的企业模式，例如重播机制，消息持久性，事务性阅读
• 能够按时间顺序处理某种消息
• 处理并非全部使用相同框架/工具包甚至编程语言编写的多种微服务之间的通信
• 处理可靠性，弹性和当您所有的消费者/微服务/垂直终端都死掉时，恢复故障
• 处理动态水平可伸缩性和监视消费者/微服务/垂直平台

在这种情况下，我宁愿选择Apache Kafka而不是本机eventbus或旧的，流行的JMS兼容系统.

In those cases I'd prefer to choose Apache Kafka over the native eventbus or an old fascioned JMS compliant system.

根据您的实际需求，不允许在同一微服务架构中同时使用eventbus和kafka.例如，您可以让一个kafka消费者小组阅读一个kafka主题，以处理扩展，监视，故障恢复和回复机制，然后通过事件总线处理子垂直面之间的通信.

It's not forbidden to use both eventbus and kafka in the same microservices architecture according to your real needs. For example, you could have one kafka consumers group reading a kafka topic to handle scaling, monitoring, failure recovery and reply mechanism and then handle communication between your sub-verticles through the eventbus.

我将在可伸缩性和监视部分进行一些说明，并解释为什么我认为使用vert.x在本地事件总线和集群模式下使用Kafka处理起来更简单:Kafka允许我们实时了解(通过JMX指标和 describe 命令):

I'll clarify a little bit for the scalability and monitoring part and explain why I think it's more simple to handle that with Kafka over the native eventbus and cluster mode with vert.x : Kafka allow us to know in real time (through JMX metrics and the describe command):

• 对应于主题的滞后"未读邮件的数量
• 每个组中正在收听某个主题的消费者数量
• 每个消费者影响的主题分区数
• i/o指标

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

So it's possible to use an ElasticStack or Prometheus+Grafana solution to monitor those metrics and use them to handle a dynamic scalability (when you know that there's a need to increase temporarily the number of consumers for example according to the lag metric and the number of partitions and the cpu/ram/swap metrics of your hosts).

要回答第二个问题vert.x或SpringBoot，我的回答不是很客观，但我会为vert.x的

To answer the second question vert.x or SpringBoot my answer will be not very objective but I'd vote for vert.x for its performances on the JVM and especially for its simplicity. I'm a little tired of the Spring factory and its big layers of abstraction that hides a lot of issues under a mountain of annotations triggering a mountain of AOP.

此外，在Java微服务世界中，SpringBoot还有其他选择，例如Microprofile的不同实现(例如thorntail项目).

Moreover, In the Java world of microservices, there's other alternatives to SpringBoot like the different implementations of Microprofile (thorntail project for example).

这篇关于vert.x事件总线可以代替Kafka的需要吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！