Bienvenido a nuestro sitio, en este lugar encontrarás la resolución a lo que estabas buscando.
Solución:
Para responder rápidamente, diría que depende de sus necesidades.
Sí, el bus de eventos puede ser una buena manera de manejar de forma nativa la comunicación entre los vértices de microservicios utilizando un paradigma asíncrono y sin bloqueo.
Pero en algunos casos podrías necesitar:
- para manejar algunos patrones comunes de empresas como mecanismos de reproducción, persistencia de mensajes, lectura transaccional
- ser capaz de procesar algún tipo de mensajes en un orden cronológico
- para manejar la comunicación entre múltiples tipos de microservicios que no están todos escritos con el mismo marco/kit de herramientas o incluso lenguaje de programación
- para manejar la confiabilidad, la resiliencia y la recuperación de fallas cuando todos sus consumidores/microservicios/vertices mueren
- para manejar escalabilidad horizontal dinámica y monitoreo de sus consumidores/microservicios/verticles
En esos casos, preferiría elegir Apache Kafka sobre el bus de eventos nativo o un antiguo sistema compatible con JMS fascinado.
No está prohibido usar eventbus y kafka en la misma arquitectura de microservicios de acuerdo con sus necesidades reales. Por ejemplo, podría tener un grupo de consumidores de kafka leyendo un tema de kafka para manejar el escalado, el monitoreo, la recuperación de fallas y el mecanismo de respuesta y luego manejar la comunicación entre sus sub-verticles a través del eventbus.
Aclararé un poco la parte de escalabilidad y monitoreo y explicaré por qué creo que es más simple manejar eso con Kafka sobre el bus de eventos nativo y el modo de clúster con vert.x: Kafka nos permite saber en tiempo real (a través de métricas JMX y el describe mando):
- el “retraso” de un tema que corresponde al número de mensajes no leídos
- el número de consumidores de cada grupo que están escuchando un tema
- el número de particiones de un tema afectado de cada consumidor
- métricas de E/S
Entonces, es posible usar una solución de ElasticStack o Prometheus+Grafana para monitorear esas métricas y usarlas para manejar una escalabilidad dinámica (cuando sabe que es necesario aumentar temporalmente la cantidad de consumidores, por ejemplo, según la métrica de retraso y la cantidad de particiones y las métricas de cpu/ram/swap de sus hosts).
Para responder a la segunda pregunta, vert.x o SpringBoot, mi respuesta no será muy objetiva, pero votaría por vert.x por su desempeño en JVM y especialmente por su simplicidad. Estoy un poco cansado de Spring Factory y sus grandes capas de abstracción que ocultan muchos problemas bajo una montaña de anotaciones que desencadenan una montaña de AOP.
Además, en el mundo de los microservicios de Java, existen otras alternativas a SpringBoot como las diferentes implementaciones de Microprofile (proyecto thorntail, por ejemplo).
El bus de eventos no es persistente. Debe utilizarlo para comunicaciones rápidas de un extremo a otro y, de manera más general, para enviar eventos en los que sabe que lata Suéltelos si tiene algún accidente.
Las secuencias de Kafka son persistentes y debe enviar eventos allí porque desea que otras aplicaciones (posiblemente distintas de Vert.x) las consuman o porque desea asegurarse de que estos eventos no se pierdan en caso de falla.
Un reactivo (léase “escalable y tolerante a fallas”) La aplicación Vert.x generalmente usa una combinación del bus de eventos y algunos sistemas de mensajería replicables como AMQP / Kafka / etc.
Sobre la pregunta:
¿Puedo reemplazar los microservicios Spring Boot con verticles basados en vert.x?
Sí, definitivamente, aunque los 2 tienen diferentes modelos de programación.
Si desea un enfoque más progresivo y usa Spring para estructurar su aplicación mientras usa Vert.x para la eficiencia de recursos sobre su E/S y procesamiento de eventos, puede combinarlos, consulte https://github.com/vert-x3/vertx -examples/tree/master/spring-examples para ejemplos.
Eres capaz de secundar nuestra tarea poniendo un comentario o dejando una valoración te damos las gracias.