Cómo elegir una cola de mensajes

Estoy trabajando en un equipo que está desarrollando un servidor de correo: James. Este proyecto es una subparte del proyecto OpenPaaS, que involucra múltiples equipos.

En este servidor de correo necesitamos implementar una cola de correo distribuido. Una cola de correo es un componente obligatorio de los servidores SMTP. Permite desacoplar la recepción de mensajes de su procesamiento. La implementación actual se basa en un servidor ActiveMQ incorporado con una implementación JMS de décadas. ¡Había llegado el momento de un pequeño levantamiento!

Pero una cola de correo es un sistema complejo ... No solo debería ser una cola de trabajo eficiente, sino que también deberían implementarse muchas características adicionales:

  • Prioridad: es posible que desee dar una mayor prioridad al correo electrónico de su organización, en comparación con el correo no deseado
  • Retrasos: tal vez no desee enviar demasiados correos a la vez. Tal vez necesite esperar un poco antes de volver a enviar un correo electrónico a un servidor de correo remoto en caso de errores ...
  • Administración: los administradores del servidor de correo esperan inspeccionar el contenido de la cola de correo, eliminar los elementos que desean, entre otros ...

No pudimos implementarlo de una manera sencilla y de grado de producción sobre RabbitMQ. Por lo tanto, decidimos buscar soluciones alternativas y colas de mensajes.

Cada equipo de OpenPaaS utilizaba colas de mensajes, tuvimos que elegir el que mejor se adapta a las necesidades de las personas.

Definiendo requisitos

El primer paso fue aprender sobre los requisitos de cada equipo y luego resumirlos.

Para realizar esto, decidimos entrevistar a los líderes de cada equipo. Definimos una lista de temas para discutir:

  • características que implementan e implementarán sobre una cola de mensajes
  • limitaciones que encuentran actualmente
  • experiencia con esta tecnología de cola de mensajes

Excavamos bastante y discutimos algunos temas candentes:

  • al menos una vez Vs como máximo una vez
  • disponibilidad Vs consistencia
  • capacidades de gestión: tamaño de la cola, navegación, ...

Como conclusión, OpenPaaS está abstrayendo la tecnología de la cola de mensajes detrás de una API de mensajería. Esta API le permite a uno publicar / suscribirse a temas específicos, realizar transmisiones y compartir trabajo usando colas de trabajo.

OpenPaaS también usa la cola de mensajes para permitir que algunos servicios se comuniquen entre ellos. Esto incluye información:

  • del servidor de correo, James
  • del sistema de calendario, Sabre.
  • del servicio de contactos

La mayoría de nuestros casos de uso se basan en al menos una entrega, pero algunos de ellos se beneficiarían exactamente de una vez semántica. Tendemos a favorecer la coherencia, y queremos tantas capacidades de gestión como podamos.

Esto nos permite extraer los requisitos básicos:

  • necesitamos capacidades básicas de mensajería
  • necesitamos consistencia, al menos una semántica
  • como beneficio adicional, capacidades de gestión avanzadas

Pero también agregamos algunos criterios que no fueron sujetos a las entrevistas:

  • madurez del proyecto
  • comunidad
  • actuaciones, ...

Afortunadamente, después de realizar las entrevistas, no hubo contradicciones, ya que un equipo necesita disponibilidad y otro tiene consistencia. Esas entrevistas nos ayudaron mucho para excluir algunas implementaciones de nuestra elección final.

Lista corta

Hay tantas implementaciones de colas de mensajes que decidimos limitar el número de candidatos. Aquí está la lista de los seleccionados para el estudio:

  • RabbitMQ
  • Kafka
  • RocketMQ
  • Qpid
  • Artemisa
  • NSQ
  • ZeroMQ

Presentaré aquí los que más nos llamaron la atención:

RabbitMQ es la cola de mensajes que OpenPaaS utiliza actualmente, por lo que no sería necesaria la migración. Ofrece una comunidad buena y madura. Se han informado algunos problemas relacionados con la agrupación, incluida la pérdida de mensajes y la reconciliación manual en la partición. El punto negativo de esta solución es que no se ajusta a las funciones de administración avanzadas que necesita James. Lo seleccionamos para una mayor investigación, y la calidad de su documentación ha sido un factor decisivo.

Kafka es una plataforma de transmisión de vanguardia. Cumple con las características solicitadas. Como expone un registro distribuido, algunas características de una cola de correo son más fáciles de implementar. Su comunidad es fuerte y madura, y se cree que se agrupa como una preocupación principal. La repetición es un concepto central. Sin embargo, su arquitectura es compleja e involucra un quórum ZooKeeper. Lo seleccionamos también.

RocketMQ es un prometedor proyecto Apache recién nacido. Sin embargo, a pesar de las buenas actuaciones y un impresionante conjunto de características, la comunidad no es muy madura, principalmente centrada en la empresa Alibaba. El proyecto aún está en desarrollo. Así que consideramos que, a pesar de todas sus ventajas, elegirlo no sería una buena elección.

Artemis, es el HornetQ, donado a la fundación Apache, y adoptado por el proyecto ActiveMQ. Una cola de mensajes sólida como una roca, pero lamentablemente su agrupación es difícil. Algunas tecnologías antiguas (incluido XML!) Están involucradas. Por lo tanto, decidimos no investigar más.

NSQ es un sistema de mensajería descentralizado. Los patrones de mensajería que queremos son compatibles, pero solo un hack permite ganar * durabilidad *. La agrupación es un concepto ciudadano primario, pero a costa de las características. AMQP no es compatible, tampoco reproducir. Decidimos que no valía la pena pagar el costo de una migración.

Y luego agregamos para elegir

La guerra se estaba librando entre Kafka y RabbitMQ.

Ninguna de las tecnologías presentadas anteriormente permite satisfacer las necesidades de James de una manera satisfactoria, al tiempo que se ajusta a nuestros estándares de producción. Por lo tanto, decidimos excluir las características de James de la elección. Las capacidades avanzadas de la cola de correo se implementarán con una combinación de cola de mensajes / base de datos.

Nuestra estrategia se convirtió en explorar con un POC las limitaciones con respecto al uso de RabbitMQ.

  • Proporcionamos un POC de casos de uso de OpenPaaS sobre RabbitMQ
  • Llevamos a cabo experimentos en la parte superior de un cluster dockerized rabbitMQ: deteniendo nodos, produciendo y consumiendo en diferentes nodos, declarando intercambios y colas en diferentes nodos.
  • Probamos durabilidad, orden de producción / consumo.

Una reunión estratégica le dirá si nos gustaría realizar el traslado a Kafka.