Redis, Kafka o RabbitMQ: ¿Cuál es mejor como intermediario de mensajes de microservicios?

Cuando los microservicios utilizan comunicación asincrónica, normalmente se utiliza un intermediario de mensajes. El intermediario de mensajes garantiza que la comunicación entre diferentes microservicios sea confiable y estable, que los mensajes se gestionen y supervisen dentro del sistema y que no se pierdan.

Hay muchos intermediarios de mensajes disponibles para los desarrolladores, que varían en tamaño y capacidades de datos. Esta publicación de blog comparará los tres intermediarios de mensajes más populares: RabbitMQ, Kafka y Redis.

Empecemos por comprender la comunicación de microservicios.

Existen dos tipos comunes de comunicación entre microservicios: síncrona y asíncrona.

En la comunicación síncrona, la persona que llama espera una respuesta antes de enviar el siguiente mensaje, que funciona como un protocolo REST a través de HTTP. Por el contrario, en la comunicación asincrónica, los mensajes se envían sin esperar respuesta. Esto se aplica a los sistemas distribuidos, que a menudo requieren intermediarios de mensajes para gestionar los mensajes.

El tipo de comunicación que elijas debe tener en cuenta diferentes parámetros como cómo está estructurado el microservicio, la infraestructura adecuada, la latencia, la escala, las dependencias y el propósito de la comunicación. Configurar la comunicación asincrónica puede ser más complejo y requerir agregar más componentes a la pila, pero los beneficios de utilizar la comunicación asincrónica en microservicios superan con creces las desventajas.

En primer lugar, por definición, la comunicación asincrónica no es bloqueante; en segundo lugar, la comunicación asincrónica admite una mejor escalabilidad que las operaciones sincrónicas; en tercer lugar, en caso de una falla del microservicio, el mecanismo de comunicación asincrónica proporciona una variedad de técnicas de recuperación; y, en general, un mejor manejo de los errores relacionados con fallas.

Además, cuando se utiliza un proxy en lugar del protocolo REST, los servicios que reciben la comunicación en realidad no necesitan conocerse entre sí. Incluso se pueden introducir nuevos servicios después de que los antiguos hayan estado funcionando durante mucho tiempo, es decir, se pueden desacoplar mejor los servicios.

Finalmente, al elegir ejecutar de forma asincrónica, mejorará su capacidad para crear descubrimiento, monitoreo, equilibrio de carga e incluso aplicadores de políticas centralizados en el futuro. Esto aportará flexibilidad, escalabilidad y más funcionalidad a su código y a las compilaciones de su sistema.

La comunicación asincrónica normalmente se gestiona a través de un intermediario de mensajes. Existen algunos otros métodos, como el aysncio, pero son más raros y limitados.

Al elegir un proxy para realizar operaciones asincrónicas, considere lo siguiente:

Uno a uno

Uno a muchos

Nosotros Se investigaron los mejores y más recientes servicios para encontrar los proveedores más sólidos en estas tres categorías.

RabbitMQ (AMQP)

Tamaño: Dependiendo de la configuración y los recursos, se ejecuta a alrededor de 50 000 mensajes por segundo.

Persistencia: Admite mensajes tanto persistentes como transitorios.

Consumidores uno a uno y uno a muchos: ambos compatibles.

Lanzado en 2007, RabbitMQ es uno de los primeros intermediarios de mensajes de propósito general creados. Es de código abierto e implementa el Protocolo avanzado de cola de mensajes (AMQP) para entregar mensajes punto a punto y publicar submétodos. Está diseñado para admitir una lógica de enrutamiento compleja.

Existen servicios administrados que le permiten usarlo como SaaS, pero no forma parte de la pila de proveedores de nube locales importantes. RabbitMQ admite todos los lenguajes principales, incluidos Python, Java, .NET, PHP, Ruby, JavaScript, Go, Swift y más.

En el modo persistente, puedes encontrar algunos problemas de rendimiento.

kafka

Tamaño: Hasta un millón de mensajes por segundo.

Durabilidad: Sí.

Consumidores uno a uno versus uno a muchos: solo existe uno a muchos (lo que parece extraño al principio, ¿verdad?).

Kafka se utiliza para administrar SaaS en Azure, AWS y Confluent, todos creadores y principales contribuyentes al proyecto Kafka. Kafka admite todos los lenguajes principales, incluidos Python, Java, C++, Clojure, .NET, PHP, Ruby, JavaScript, Go, Swift y más. Kafka admite todos los lenguajes principales, incluidos Pyon, Java, C, Clojure, .NET, PHP, Ruby, JavaScript, Go, Swift y más.

Redis

Tamaño: Hasta un millón de mensajes por segundo.

Durabilidad: Básicamente ninguna, es un almacén de datos en memoria.

Consumidor uno a uno y consumidor uno a muchos: ambos.

Redis es un poco diferente de otros intermediarios de mensajes. En esencia, Redis es un almacén de datos en memoria que se puede utilizar como almacén de valores clave o agente de mensajes de alto rendimiento. Otra diferencia es que Redis no tiene persistencia y, en cambio, vuelca la memoria en una base de datos en disco. También es ideal para el procesamiento de datos en tiempo real.

Al principio, Redis no era uno a uno ni uno a muchos. Sin embargo, desde la introducción de pub-sub en Redis 5.0, la funcionalidad se ha mejorado y uno a muchos se ha convertido en una opción real.

Presentamos algunas características de RabbitMQ, Kafka y Redis. Los tres animales pertenecen a su propia categoría, pero como se mencionó anteriormente, operan de maneras muy diferentes. Este es el intermediario de mensajes correcto que recomendamos según su caso de uso.

Mensajes de corta duración: Redis

La base de datos en memoria de Redis casi siempre es adecuada para casos de uso en los que los mensajes son de corta duración y no requieren persistencia. Debido a que Redis proporciona un servicio muy rápido y capacidades en memoria, es ideal para mensajes de corta duración donde la durabilidad no es importante y se pueden tolerar algunas pérdidas. Con el lanzamiento de Redis Streaming en 5.0, también se está convirtiendo en un candidato para casos de uso de uno a muchos en los que su uso es absolutamente necesario debido a limitaciones y a la antigua funcionalidad pub-sub.

Big Data: Kafka

Kafka es una cola distribuida de alto rendimiento que se puede utilizar para almacenar grandes cantidades de datos durante largos períodos de tiempo. Kafka es ideal para casos de uso de uno a varios que requieren durabilidad.

Enrutamiento complejo: RabbitMQ

RabbitMQ es un broker antiguo pero maduro con muchas funciones para admitir enrutamiento complejo. Incluso puede admitir comunicaciones enrutadas complejas cuando la velocidad requerida no es alta (más de decenas de miles de mensajes por segundo).

Considere su pila de software

Por supuesto, lo último que debe considerar es su pila de software actual. Si busca un proceso de integración relativamente simple y no desea mantener proxies adicionales en la pila, es posible que prefiera utilizar proxies que ya sean compatibles con la pila.

Por ejemplo, si usa Celery para colas de tareas en un sistema además de RabbitMQ, podrá usarlo con RabbitMQ o Redis, pero no con Kafka, que no es compatible con Kafka y requiere algunos reescribiendo.

¡Continuamos evolucionando y creciendo usando la plataforma usando todo lo anterior y más! Es importante recordar que cada herramienta tiene sus propias ventajas y desventajas, la clave es entenderlas y elegir la herramienta adecuada según el trabajo y el momento, situación y requerimientos específicos.