Une introduction à Apache Kafka et à la communication sur les microservices

Lorsque nous parlons de microservices, l'une des premières choses qui me vient à l'esprit est de savoir comment interagir avec toutes ces minuscules API et travailleurs à l'intérieur de l'architecture système. Pour cette discussion, nous avons essentiellement deux types de communication interservices: synchrone (requêtes http / tcp) et asynchrone. Cet article vise à se concentrer sur la deuxième option en utilisant Apache Kafka comme courtier de messages entre les services.

Cas d'utilisation

Supposons que nous ayons un scénario très simple: un service chargé de créer de nouveaux comptes dans un système bancaire qui doit communiquer avec un autre service qui est responsable d'envoyer un e-mail de confirmation à l'utilisateur, après la création.

Dans un système monolithique, nous aurions probablement toute cette logique dans la même base de code, de manière synchrone. Mais dans le monde brillant des microservices, nous avons découplé ces responsabilités dans deux projets différents et nous devons maintenant faire savoir au service de messagerie qu'un courrier électronique de confirmation doit être envoyé.

Solution

Voici l'appel de notre magnifique Apache Kafka. Mais qu'est-ce que Kafka? Depuis leur site:

Kafka ™ est utilisé pour créer des pipelines de données en temps réel et des applications de streaming. Il est évolutif horizontalement, tolérant aux pannes, très rapide et fonctionne en production dans des milliers d'entreprises.

Kafka convient parfaitement à de nombreux cas d'utilisation, principalement pour le suivi de l'activité du site Web, l'agrégation de journaux, les mesures opérationnelles, le traitement des flux et, dans ce post, pour la messagerie.

Cette plateforme nous offre un moyen élégant de créer un pipeline de données où nous pouvons connecter les producteurs (New Account Service) qui créeront de nouveaux enregistrements dans le pipeline de données et les consommateurs (Email Service) qui seront à l'écoute de nouveaux enregistrements.

Si vous venez d'un monde SGBDR, vous pouvez imaginer qu'un sujet est une table, un producteur est quelqu'un qui insérera de nouvelles données dans cette table et le consommateur est une application qui interrogera votre base de données pour trouver de nouvelles entrées.

La principale différence avec l'approche ci-dessus est que lorsque nous utilisons une solution de file d'attente de messages, nous n'avons pas besoin de continuer à mettre en commun une base de données pour vérifier si nous avons de nouvelles données, nous écouterons toujours certains sujets particuliers afin de déclencher une action. .

Veuillez vérifier l'horrible diagramme ci-dessous que j'ai fait en 5 secondes pour illustrer ce que j'écris:

Si vous visitez la page Apache Kafka, vous pouvez trouver un exemple très utile pour vous salir les mains et simuler ce flux en utilisant uniquement votre terminal. C'est facile et amusant.

Conclusion

Il existe d'autres plates-formes qui travaillent sur ce type de solution, comme ActiveMQ et RabbitMQ, mais Kafka semble fonctionner et évoluer mieux. Quoi qu'il en soit, chaque projet est une histoire différente et vous devez évaluer l'option la plus raisonnable pour votre cas :-)

Il s'agit d'une introduction de haut niveau à Apache Kafka, si vous voulez approfondir un peu ce sujet et découvrir ce que Kafka peut faire d'autre pour vous (streams, par exemple), veuillez vérifier quelques références ci-dessous: