Microservices Pourquoi utiliser RabbitMQ?
Je n'ai pas trouvé de message existant demandant cela, mais veuillez m'excuser si je l'ai manqué.
J'essaie de faire tourner la tête des microservices et je suis tombé sur des articles où RabbitMQ est utilisé. Je ne comprends pas pourquoi RabbitMQ est nécessaire. L'intention est-elle que les services utilisent une API Web pour communiquer avec le monde extérieur et RabbitMQ pour communiquer entre eux?
Dans l'architecture de microservices, vous avez deux façons de communiquer entre les microservices:
- Synchrone - c'est-à-dire que chaque service appelle directement l'autre microservice, ce qui entraîne une dépendance entre les services
- Asynchrone - vous disposez d'un concentrateur central (ou file d'attente de messages) où vous placez toutes les demandes entre les microservices et le service correspondant prend la demande, la traite et renvoie le résultat à l'appelant. C'est à cela que RabbitMQ (ou toute autre file d'attente de messages - MSMQ et Apache Kafka sont de bonnes alternatives) est utilisé. Dans ce cas, tous les microservices ne connaissent que l'existence du concentrateur.
microservices.io a de très beaux articles sur l'utilisation des microservices
Une file d'attente de messages fournit un protocole de communication asynchrone - Vous avez la possibilité d'envoyer un message d'un service à un autre sans avoir à savoir si un autre service peut manipulez-le immédiatement ou non. Les messages peuvent attendre que le service responsable soit prêt. Un service publiant un message n'a besoin de rien savoir sur le fonctionnement interne des services qui traiteront ce message. Cette façon de gérer les messages dissocie le producteur du consommateur.
Une file de messages gardera les processus de votre application séparés et indépendants les uns des autres; cette façon de gérer les messages pourrait créer un système qui est facile à entretenir et facile à mettre à l'échelle .
ici est une histoire expliquant comment Parkster (un service de stationnement numérique) décompose son système en plusieurs microservices en utilisant RabbitMQ.
Ce guide suivez un scénario où une application Web permet aux utilisateurs de télécharger des informations sur un site Web. Le site va gérer ces informations et générer un PDF et le renvoyer par e-mail à l'utilisateur. Gérer les informations, générer le PDF et envoyer l'e-mail sera dans ce exemple de cas prendre plusieurs secondes et c'est l'une des raisons pour lesquelles une file d'attente de messages sera utilisée.
Ici est une histoire sur comment et pourquoi CloudAMQP a utilisé les files d'attente de messages et RabbitMQ entre les microservices.
ici est une histoire sur l'utilisation de RabbitMQ dans une architecture de microservices basée sur des événements pour prendre en charge 100 millions d'utilisateurs par mois.
Et enfin un lien à Kontena, expliquant pourquoi ils ont choisi RabbitMQ pour leur architecture de microservice: "Parce que nous avions besoin d'une solution de messagerie stable, gérable et hautement disponible.".
Veuillez noter que je travaille pour l'entreprise derrière CloudAMQP.
La même question peut être pourquoi REST est nécessaire pour les microservices? Le concept de microservice n'est pas quelque chose de nouveau sous la lune. Une distribution à long terme du flux de travail a été utilisée pour l'ingénierie du backend et le traitement des demandes asynchrones, Microservice est le même composant dans un jvm séparé qui correspond à S (responsabilité unique) dans SOLID. Ce qui le rend micro SERVICE - c'est qu'il est équilibré. Et c'est tout! En particulier (!), Il peut être REST Service sur la base Spring Cloud/REST, qui est enregistré par Eureka, dispose d'une passerelle proxy et d'un équilibrage de charge sur Zuul et Ribbon. Mais ce n'est pas tout le monde des microservices! Soit dit en passant, le traitement distribué asynchrone est l'une des tâches pour lesquelles les microservices sont utilisés. Il y a longtemps, les services (composants) de la JVM séparée étaient intégrés sur n'importe quelle messagerie et le modèle est connu sous le nom d'ESB. Les microservices sont les mêmes sujets que le modèle. En raison de la mode pour Spring Cloud, REST semble être le seul moyen de microservices. Nan! L'architecture de microservices asynchrones basée sur les messages est prise en charge par Vertx https://dzone.com/articles/asynchronous-microservices-with-vertx , par exemple. Pourquoi ne pas utiliser RabbitMQ comme canal de message? Dans ce cas, l'équilibrage de charge peut être fourni en créant un cluster RabbitMQ. Par exemple: https://codeburst.io/using-rabbitmq-for-microservices-communication-on-docker-a43840401819 . Ainsi, le monde est beaucoup plus large.