Qu'est-ce que la découverte de services et pourquoi en avez-vous besoin?
Pour autant que je sache, la "découverte de service" signifie un moyen pour un client de découvrir un serveur (ou un groupe de serveurs) auquel il veut se connecter.
J'ai créé des applications Web qui communiquent avec d'autres processus principaux à l'aide de protocoles comme HTTP et AMQP. Dans ceux-ci, chaque client a un fichier de configuration qui contient un nom d'hôte ou toute information dont il a besoin pour se connecter au serveur, qui est défini au moment du déploiement à l'aide d'un outil de configuration comme Ansible. C'est simple et semble assez bien fonctionner.
La découverte de services est-elle une alternative à la simple mise en place d'informations sur le serveur dans le fichier de configuration d'un client? Si oui, pourquoi est-ce mieux? Sinon, quel problème résout-il?
Commençons par examiner ce qu'est la découverte de services - voici une bonne explication: https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ (ce lien devrait clarifier à peu près la question posée)
Et voici un exemple d'utilisation dans la pratique: Supposons que vous ayez le service B utilisé par le service A. Le service B (comme la plupart des services dans SOA ) est en fait un cluster d'applications de type B. Le service A nécessite d'utiliser l'un des nœuds du cluster B, mais le cluster de nœuds B est dynamique . c'est-à-dire que les nœuds B sont créés et terminés, en fonction de la charge sur le service B global. Maintenant, nous aimerions que le service A communique avec un nœud B actif chaque fois qu'il a besoin d'utiliser le service B. Pour ce faire, nous utiliserons l'outil de découverte de services pour nous fournir à un instant donné , une adresse de l'un des nœuds B actifs.
Donc, essayer de répondre à vos questions ci-dessus, mettre les informations du serveur de point de terminaison (en particulier l'adresse du point de terminaison) en tant que configuration statique dans un fichier de configuration qui est lu au démarrage du service A, ne vous donnera pas le la dynamique que vous souhaitez lorsque les points de terminaison du service B peuvent constamment changer.
L'architecture du serveur cloud change la façon dont nous construisons les applications Web que nous passons de grands monolithes simples à les diviser en services de plus en plus petits déployables individuellement appelés microservices forment ensemble la grande application.
Prenons le scénario lorsqu'un service souhaite communiquer avec un autre service, disons que le service A doit communiquer avec le service B. Le Service-A doit connaître l'adresse IP et le numéro de port du Service-B. La solution la plus simple au problème consiste à gérer un fichier de configuration contenant l'adresse IP et le port vers Service-B dans Service-A. Il y a plusieurs inconvénients à cette approche
Considérez la situation suivante: -
- Lorsque le nombre de micro-services dans l'application augmente
- Il est difficile à gérer dans un fichier de configuration
- Il est sujet aux erreurs lorsqu'une mauvaise gestion se produit
- Il n'a pas la flexibilité de changer l'adresse IP ou le port ultérieurement
- Il ne peut pas utiliser la capacité du cloud pour évoluer ou se réduire dynamiquement en fonction des besoins.
Cette approche simple est trop statique et fige le cloud Ainsi vient la nouvelle solution
Solution alternative: découverte du service
La découverte de services aide à résoudre le problème ci-dessus en fournissant un moyen
- Pour enregistrer un service, c'est-à-dire lorsqu'un nouveau service devient en ligne, il s'enregistre auprès du service de découverte de service avec son IP et son port
- Aide les services à trouver d'autres services, c'est-à-dire aide Service-A à trouver Service-B
- Vérification de santé pour vérifier la santé de l'instance et la supprimer lorsqu'elle ne va pas bien.
- Pour vous désinscrire lorsqu'un service devient hors ligne.
Ainsi, il aide à utiliser toutes les capacités du cloud pour évoluer et se rétrécir dynamiquement en fonction des besoins et également rendre l'architecture lâchement couplée les unes aux autres
Je dois admettre que la méthode que vous avez dite est faisable, mais s'il y a tant de services, la complexité que vous devez gérer augmentera et la configuration manuelle de la liste de services est également très sujette aux erreurs.
La découverte de services n'est pas un moyen simple de placer la liste des services à appeler dans la configuration du client, mais d'enregistrer la liste des instances de tous les services eux-mêmes.
vous pouvez simplement comprendre que nous avons un service d'enregistrement qui peut gérer automatiquement la liste des instances de service auxquelles accéder. Lorsque vous ajoutez un service ou fermez le service, le service d'enregistrement met automatiquement à jour votre liste de services. Lorsque vous l'appelez, vous obtiendrez la dernière liste de services du centre d'inscription à appeler. Afin de ne pas affecter les performances, vous pouvez également mettre en cache la liste des services sur le client
Si vous avez 2 microservices, disons A et B et que vous voulez que A communique avec B, A utilisera une méthode (outil) de découverte de service pour trouver B dans une architecture de microservice.
Non seulement les communications client-serveur, mais aussi 2 microservices qui peuvent fonctionner sur le même serveur.
Le problème qu'il résout est que 2 microservices fonctionnant sur 2 nœuds différents dans un cluster peuvent se découvrir mutuellement, sans découverte de service, cela n'aurait pas été possible.
Vous pouvez voir comment kurbernetes prend en charge la découverte de services, par exemple via DNS en utilisant coreDNS. https://kubernetes.io/docs/concepts/services-networking/service/