Comment choisir une file de messages

Je travaille dans une équipe qui développe un serveur de messagerie: James. Ce projet fait partie du projet OpenPaaS et implique plusieurs équipes.

Dans ce serveur de messagerie, nous devons implémenter une file d'attente de messagerie distribuée. Une file d'attente de messagerie est un composant obligatoire des serveurs SMTP. Il permet de dissocier les messages reçus de leur traitement. L'implémentation actuelle repose sur un serveur ActiveMQ intégré avec une implémentation JMS vieille de plusieurs décennies. Le temps était venu de remonter un peu!

Mais une file d'attente de messagerie est un système complexe… Non seulement doit-il s'agir d'une file d'attente de travail efficace, mais également de nombreuses fonctionnalités supplémentaires doivent être implémentées:

  • Priorité: vous pouvez accorder une priorité plus élevée au courrier électronique de votre entreprise, par rapport au courrier indésirable.
  • Délais: vous ne voulez peut-être pas envoyer trop de mails à la fois. Peut-être devrez-vous attendre un peu avant de renvoyer un courrier électronique à un serveur de messagerie distant en cas d'erreur…
  • Gestion: les administrateurs de serveurs de messagerie s'attendent à inspecter le contenu de la file d'attente, à supprimer les éléments qu'ils souhaitent, entre autres…

Nous ne pouvions pas l'implémenter de manière simple et de qualité production en plus de RabbitMQ. Nous avons donc décidé de rechercher des solutions alternatives et des files d'attente de messages.

Chaque équipe OpenPaaS utilisant des files de messages, nous devions choisir celle qui répondait le mieux aux besoins des utilisateurs.

Définir les exigences

La première étape consistait à connaître les exigences de chaque équipe, puis à les résumer.

Afin de réaliser cela, nous avons décidé d'interviewer chaque chef d'équipe. Nous avons défini une liste de sujets à discuter:

  • fonctionnalités qu'ils implémentent, et implémenteront en plus d'une file d'attente de messages
  • limitations qu'ils rencontrent actuellement
  • expérience avec cette technologie de file d'attente de messages

Nous avons creusé assez loin et discuté de sujets d'actualité:

  • au moins une fois contre au plus une fois
  • disponibilité par rapport à la cohérence
  • capacités de gestion: taille de la file d'attente, navigation,…

En conclusion, OpenPaaS est en train de résumer la technologie de file d'attente de messages derrière une API de messagerie. Cette API permet de publier / s'abonner à des sujets spécifiques, d'effectuer des diffusions et de partager un travail à l'aide de files d'attente.

OpenPaaS utilise également la file de messages pour permettre à certains services de communiquer entre eux. Cela comprend des informations:

  • du serveur de messagerie, James
  • du système de calendrier, Saber.
  • du service de contacts

La plupart de nos cas d'utilisation reposent sur au moins une diffusion, mais certains d'entre eux bénéficieraient d'une sémantique unique. Nous avons tendance à privilégier la cohérence et voulons autant de capacités de gestion que possible.

Cela nous permet d'extraire les exigences de base:

  • nous avons besoin de capacités de messagerie de base
  • nous avons besoin de cohérence, au moins une sémantique
  • en bonus, des capacités de gestion avancées

Mais nous avons également ajouté des critères qui n'ont pas été soumis aux entretiens:

  • la maturité du projet
  • communauté
  • les performances, …

Heureusement, après avoir mené les entretiens, il n’ya eu aucune contradiction, par exemple une équipe a besoin de disponibilité et une autre de cohérence. Ces entretiens nous ont beaucoup aidés à exclure certaines implémentations de notre choix final.

Liste courte

Il y a tellement d'implémentations de files de messages que nous avons décidé de limiter le nombre de candidats. Voici la liste des personnes sélectionnées pour l'étude:

  • RabbitMQ
  • Kafka
  • RocketMQ
  • Qpid
  • Artemis
  • NSQ
  • ZeroMQ

Je vais présenter ici ceux qui ont le plus attiré notre attention:

RabbitMQ étant la file d'attente de messages actuellement utilisée par OpenPaaS, aucune migration n'est nécessaire. Il offre une communauté bonne et mature. Certains problèmes concernant le regroupement ont été signalés, notamment la perte de messages et la réconciliation manuelle après partition. Le point négatif de cette solution est qu’elle ne convient pas aux fonctions de gestion avancées requises par James. Nous l'avons choisi pour une enquête plus approfondie et la qualité de sa documentation a été un facteur décisif.

Kafka est une plateforme de streaming à la pointe de la technologie. Il remplit les fonctionnalités demandées. Comme il expose un journal distribué, certaines fonctionnalités d'une file d'attente de messagerie sont plus faciles à implémenter. Sa communauté est forte et mature, et on pense que le regroupement en tant que préoccupation principale. La relecture est un concept fondamental. Cependant, son architecture est complexe et implique un quorum ZooKeeper. Nous l'avons sélectionné aussi.

RocketMQ est un nouveau projet Apache prometteur. Cependant, malgré de bonnes performances et un ensemble de fonctionnalités impressionnant, la communauté n’est pas très mature, principalement autour de la société Alibaba. Le projet est encore en développement. Nous avons donc pensé, malgré tous les avantages, que le choix n’était pas judicieux.

Artemis, est le HornetQ, offert à la fondation Apache et adopté par le projet ActiveMQ. Une file de messages solide comme le roc, mais malheureusement, le regroupement est difficile. Certaines technologies anciennes (y compris XML!) Sont impliquées. Nous avons donc décidé de ne plus enquêter.

NSQ est un système de messagerie décentralisé. Les modèles de messagerie que nous voulons sont pris en charge, mais seul un piratage permet de gagner * en durabilité *. Le regroupement est un concept de premier citoyen, mais au détriment des fonctionnalités. AMQP n'est pas pris en charge, rejouez non plus. Nous avons décidé que cela ne valait pas la peine de payer le coût d'une migration.

Et puis on ajoute à choisir

La guerre faisait rage entre Kafka et RabbitMQ.

Aucune des technologies présentées ci-dessus ne permet de répondre de manière satisfaisante aux besoins de James, tout en respectant nos normes de production. Nous avons donc décidé d’exclure les fonctionnalités de James du choix. Les fonctionnalités avancées de la file de courrier seront implémentées avec une combinaison de file de messages / base de données.

Notre stratégie a ensuite consisté à explorer avec un POC les limitations concernant l’utilisation de RabbitMQ.

  • Nous avons fourni un cas d’utilisation OpenPaaS au-dessus de RabbitMQ.
  • Nous avons mené des expériences sur un cluster rabbitMQ dockerisé: arrêter des nœuds, produire et consommer sur différents nœuds, déclarer des échanges et des files d'attente sur différents nœuds.
  • Nous avons testé la durabilité, l'ordre de production / consommation.

Une réunion stratégique dira ensuite si nous souhaitons effectuer le déménagement à Kafka.