Communication entre deux microservices
Je crée un projet avec une architecture de microservices. Et j'ai créé deux microservices.
L'une d'elles est pour l'entité produit, l'autre pour l'entité facture. Ils ont leurs propres points de terminaison et sont connectés ensemble à la passerelle (j'utilise l'architecture jhipster microservices).
Les factures doivent avoir accès à la liste des produits. Je me demande comment je peux communiquer entre ces deux ms. J'ai trois approches en tête:
Envoyer une demande de bill-ms à la file d'attente - comme rabbitMQ, pour obtenir ces produits avec ces identifiants à partir de product-ms (je ne sais pas quel est le goulot d'étranglement de celui-ci)
Envoyez une demande à la passerelle pour le service produit et récupérez le produit à partir de là (la latence m'inquiète à cause de la taille des données et, de cette manière, je ne touche pas directement à la base de données, je dépend donc toujours de la passerelle)
Je peux dupliquer les référentiels, les services et les entités dans bill-ms (c'est une façon laide, et je pense que cela enfreint la règle de ms-architecture et que la maintenance est très difficile)
Si vous avez une autre approche, je vous remercie de la partager avec moi.
Modifier
- Maintenant, je sais ce qu’est le goulet d’étranglement: disons qu’il existe 3 instances de bill-ms et comment rabbitMQ décide-t-elle à quelle instance répondre? ou comment devrais-je dire au ruban " donnez-moi l'instance gratuite de bill-ms pour souscrire à la requête de rabbitMQ " pour un équilibrage de charge.
Je ne sais pas si je vais répondre correctement. J'apprends toujours moi-même .. Mais je peux vous dire comment j'ai mis en œuvre mes tentatives de microservices ..
Tout d'abord, j'ai commencé avec HTTP microservices basés sur la communication en utilisant ce blog . Cela fonctionne bien, mais le problème est que vous créez dépendances entre vos services. Service A doit être conscient d'un service B et doit l'appeler directement (via la découverte de service, etc. bien sûr). C’est ce que vous essayez généralement d’éviter lors du développement de microservices.
Une autre approche avec laquelle j'ai commencé récemment utilise un message bus. C'est en fait la troisième option que vous avez abordée dans votre question.
J'ai un service A, qui stocke des personnes (juste un exemple). Ce que fait le service lorsqu'il crée une nouvelle personne est le suivant: Il envoie une event sur un bus RabbitMQ: personCreatedEvent. S'il existe d'autres services intéressés par de tels événements, ils peuvent y souscrire. Ces services intéressés conservent les informations pertinentes qui les intéressent dans leurs propres magasins de données.
Avec cette dernière approche, il n’ya pas vraiment de dépendance entre vos services, car ils ne communiquent pas directement entre eux. Service A n'est pas au courant de service B, car B envoie simplement des événements à RabbitMQ au service intéressé par ces événements, et inversement.
Bien entendu, vous avez des duplications entre des banques de données sur le service. Mais cela peut aussi être rentable, par exemple. le service B n'a pas besoin d'utiliser le même schéma ou le même mécanisme de stockage de données que le service A. Il ne stocke que les informations pertinentes de la manière la mieux adaptée à ce service.
Avez-vous consulté http://stytex.de/blog/2016/03/25/jhipster3-microservice-tutorial/ Partie 2: section sur la communication interservices. Il vous guide à travers un exemple spécifique de la manière dont cela est réalisé.
Permettez-moi d’essayer d’ajouter quelques détails supplémentaires à ce scénario pour souligner ce qui peut ou non être qualifié d’événement dans le contexte de Product et Biiling. Billing-MS n'aurait besoin de parler à Product-Ms que dans le cas où une commande est passée. Passer une commande s’appliquerait principalement à un État membre distinct, disons Ordre-MS. Lorsqu'une commande est créée ou passée, elle contient des informations sur les produits en tant que postes individuels.
La création d'une commande peut être considérée comme un événement. Lorsque l'événement de création de commande se produit, il peut être poussé dans une file d'attente pour le service de facturation. La file d'attente doit être implémentée en tant que file d'attente de travail dans RabbitMQ. De cette manière, plusieurs instances de Billing-MS peuvent s'abonner à la même file d'attente, mais celle-ci sera traitée par un et un seul travailleur. RIBBON n’a aucun rôle à jouer dans l’enregistrement d’un service en tant que travailleur auprès de RabbitMQ. Chaque instance s’enregistre dans une file d’attente et RabbitMQ décide de RoundRobin quelle instance du service de facturation doit traiter cet événement.
Obtenir les détails des produits dans une commande pour la facturation doit être un appel pondéré de service à service via le ruban (si c'est ce que vous utilisez). Obtenir les détails d'un produit n'est pas vraiment un événement, mais passer une commande est la différence.
En outre, Gateway doit être utilisé pour exposer vos services Edge. Pour les appels de service à service, il ne serait pas idéal de passer par le service de passerelle.
Une option consiste à envoyer une demande à Bill Microservice en utilisant son nom enregistré dans le registre Eureka.