Qu'est-ce que la découverte de services dans les microservices ?

Qu'est-ce que la découverte de services ? Pourquoi en avez-vous besoin ?

Aux débuts d'Internet, les utilisateurs devaient saisir une longue chaîne d'adresses IP pour accéder à un service en ligne. Bien que les adresses IP ne soient pas longues, en tant que chaîne de chiffres sans signification, il était difficile de se souvenir de l'adresse spécifique d'un service particulier. Cela a conduit à l'invention du système de noms de domaine (DNS). Chaque service en ligne enregistrait un nom de domaine auprès d'un fournisseur de noms de domaine, puis établissait un lien entre le nom de domaine et une adresse IP spécifique via le DNS (Domain Name System). Ainsi, les utilisateurs pouvaient simplement saisir un nom de domaine mémorable et accéder au service en ligne sur une adresse IP spécifique, ce qui constituait la première forme de découverte de services.

Lorsque le nombre de services au sein d'une entreprise atteint une certaine taille (par exemple, en se divisant en microservices), le problème des adresses IP difficiles à mémoriser se pose également, ce qui nécessite un système de découverte de services. Les services au sein de l'entreprise s'enregistrent auprès de ce système, et les autres services qui souhaitent y accéder recherchent l'adresse IP correspondante dans le système, évitant ainsi à un service de devoir "mémoriser" une adresse IP complexe et variable.

Les changements d'adresse IP peuvent dérouter les visiteurs.

En introduisant le DNS comme mécanisme de découverte de services, les changements d'adresse IP peuvent désormais être gérés de manière flexible.

Introduction aux systèmes de découverte de services courants

En tant que système de découverte de services, il doit satisfaire au moins quatre fonctions :

1. API pour l'enregistrement
2. API pour la requête
3. Haute disponibilité : après tout, le système de découverte de services est le nerf de l'ensemble du système et ne peut pas être paralysé ou tomber en panne
4. Écosystème : comme nous le savons tous, les programmeurs sont paresseux et préfèrent avoir une bibliothèque qui peut interagir facilement avec les API

Examinons quelques systèmes de découverte de services open-source populaires sur le marché :

Consul

Consul est un système de découverte de services développé par Hashicorp, une entreprise open-source de premier plan. En tant que logiciel bien établi dont la première version a été publiée le 17 avril 2014, Consul possède l'un des écosystèmes les plus riches et même des développeurs tiers qui développent un SDK Haskell pour lui. La plupart des SDK de Consul ne sont que des wrappers pour son API HTTP, donc il n'y a pas beaucoup de travail de développement.

Consul prend en charge l'enregistrement et la requête de services via l'API HTTP. Il prend en charge le long polling HTTP pour une transmission de données en temps réel lors des requêtes, évitant ainsi le polling. De plus, Consul permet de rechercher l'instance du service correspondant via le DNS.

Le déploiement de Consul est intéressant car chaque instance de Consul est appelée un agent, qui peut être soit un client, soit un serveur. Du côté client, Consul maintient un état côté client ; du côté serveur, Consul prend en charge le déploiement distribué via l'algorithme de consensus Raft, pour atteindre une haute disponibilité.

Eureka

Eureka est un projet open-source de Netflix, qui est également assez ancien (il existe des traces de commits datant de 2012). Cependant, le projet n'a pas été maintenu depuis un an. De nombreux utilisateurs ont migré vers Nacos, qui sera mentionné ci-dessous.

Eureka prend en charge l'interaction via l'API HTTP et le SDK Java. Beaucoup des utilisateurs d'Eureka ont été attirés par des projets de l'écosystème Java tels que Spring Cloud. La conception de haute disponibilité d'Eureka, si vous souhaitez la décrire en termes de CAP (le théorème CAP stipule qu'un système distribué ne peut fournir que deux des trois propriétés simultanément : Cohérence, Disponibilité et Tolérance aux partitions), est AP, ce qui permet aux clients de voir des données expirées en cas de partitionnement du réseau, évitant ainsi des catastrophes secondaires dues à des problèmes de réseau.

Nacos

Nacos est un système de découverte de services développé par Alibaba, dont le nom provient de l'agrégation des premières lettres de Naming and Configuration Service. Depuis la sortie de la version 0.1.0 le 20 juillet 2018, Nacos a maintenant évolué jusqu'à la version 2.1.

Comme beaucoup de projets open-source d'Alibaba, Nacos est très populaire parmi les développeurs Java en Chine, et sa popularité est même bien supérieure à celle d'Eureka.

Il prend en charge l'enregistrement et la requête de services via l'API HTTP et des SDK tels que Java/Go/Python/NodeJS/C#. Actuellement, les développeurs de Nacos travaillent également sur de nouvelles API basées sur gRPC. Pour l'API HTTP, Nacos ne prend actuellement en charge que le polling pour une liste de services. Ainsi, Nacos préfère officiellement l'approche SDK, qui est une approche de polling + push basée sur UDP avec une meilleure performance en temps réel. Nacos travaille également sur de nouvelles API basées sur gRPC, qui introduiront des capacités de push côté serveur, un grand avantage pour les systèmes qui n'ont pas accès au SDK.

La haute disponibilité de Nacos est en partie due aux capacités de persistance fournies dans le SDK client, et en partie due à la cohérence du côté serveur via les protocoles Raft et Distro.

Méthodes d'interfaçage courantes et leurs avantages et inconvénients

En laissant de côté les protocoles privés, les méthodes d'interfaçage de la découverte de services peuvent être divisées en trois catégories :

1. Polling HTTP
2. DNS
3. Long polling HTTP ou streaming serveur gRPC

Le polling HTTP est simple à mettre en œuvre mais n'est pas en temps réel.

La surcharge de performance du DNS est minimale. Le DNS n'est pas non plus en temps réel en raison du cache DNS, et a l'avantage d'être un ensemble de normes largement acceptées et indépendantes de l'implémentation. Cependant, il y a deux côtés à la médaille, ce qui signifie que le système de découverte de services ne peut pas ajouter de champs supplémentaires à la réponse DNS, sauf si le champ Additional dans la réponse DNS est utilisé, mais cela nécessiterait un traitement spécial par le client.

Le long polling HTTP ou le streaming serveur gRPC est le plus en temps réel des trois. Comme ils sont tous deux basés sur HTTP, la réponse peut être facilement personnalisée. L'inconvénient est qu'ils sont relativement difficiles à mettre en œuvre côté client.

Comment APISIX s'interfacet avec les systèmes de découverte de services

En tant que passerelle cloud-native, APISIX prend en charge la récupération des nœuds en amont à partir du système de découverte de services et est conçu pour prendre en charge l'interfaçage avec le système de découverte de services à la fois sur le plan de données et le plan de contrôle.

Plan de données

APISIX prend en charge l'intégration avec DNS, Eureka, Consul (mode KV), Nacos et K8s sur le plan de données.

Lors de l'interfaçage avec les services DNS, APISIX utilisera les enregistrements SRV ou A/AAAA du DNS pour obtenir le nœud en amont spécifique d'un service. Lorsqu'une requête est faite pour accéder à l'amont, il essaiera d'abord de le récupérer à partir du cache DNS. Sinon, il lancera une requête DNS pour obtenir l'adresse IP spécifique à l'intérieur de l'enregistrement correspondant.

Quant aux autres types de découverte de services, ils sont synchronisés en arrière-plan. Lorsqu'une requête est faite pour accéder à l'amont, la partie des données correspondant au nom du service est récupérée à partir des données actuellement synchronisées. Pour K8s et Consul KV, nous pouvons obtenir l'adresse IP modifiée en temps réel de cette manière, car ils prennent en charge le long polling HTTP. Pour Eureka et Nacos, nous ne faisons actuellement que du polling pour les données.

Plan de contrôle

APISIX prend également en charge la découverte de services sur le plan de contrôle. Nous travaillons sur apisix-seed, qui synchronisera les données du système de découverte de services vers etcd afin que le plan de données puisse synchroniser les derniers nœuds en amont à partir d'etcd.

Nous avons maintenant implémenté la prise en charge de Nacos et Zookeeper sur le plan de contrôle. Comme la prise en charge de la découverte de services sur le plan de contrôle est implémentée via le SDK officiel, elle présente des avantages qui ne sont pas disponibles avec la méthode HTTP normale. Par exemple, dans l'implémentation de Nacos dans apisix-seed, nous prenons en charge le push basé sur UDP, donc les données sont plus efficaces en temps que le polling HTTP.

Avantages du support de la découverte de services par APISIX

En intégrant directement la découverte de services sur la passerelle, vous pouvez grandement simplifier la charge de travail pour mettre vos services en ligne. Configurez APISIX pour interagir avec votre système de découverte de services, puis laissez APISIX faire le reste pour vous. Par exemple, si votre entreprise utilise Nacos comme système de découverte de services, il vous suffit de configurer APISIX pour activer la découverte de services Nacos, puis de simplement configurer le nom du service en amont d'APISIX, et APISIX récupérera automatiquement le nœud IP spécifique correspondant à cet amont.

C'est un avantage qui peut considérablement réduire la quantité de travail nécessaire lors de la migration d'une passerelle, par exemple, de Spring Cloud Gateway à APISIX. Si la Spring Cloud Gateway est utilisée pour appliquer Eureka ou Nacos pour la découverte de services, la transition vers le nouveau système peut être effectuée en activant simplement la prise en charge d'Eureka ou de Nacos dans APISIX.

Huan Bei Loan a une grande expérience dans ce domaine, et le remplacement de la Spring Cloud Gateway vise à améliorer davantage la stabilité, la supervision, la précision et l'efficacité.

Pour citer le texte original de Huan Bei Loan :

En tant qu'entreprise, le coût reste le principe à considérer. Dans la phase de croissance rapide, il peut être nécessaire de stimuler la croissance de l'entreprise aussi rapidement que possible. Cependant, dans l'environnement actuel, la priorité est certainement le coût dans le budget. Dans ce cas, l'efficacité et le coût ne peuvent être préservés que d'une manière ou d'une autre. Donc, avec des coûts limités, les entreprises parleront moins d'avancement technologique. Dans le processus de sélection, le personnel technique considérera moins l'impact que la technologie choisie aura sur l'équipe, le bénéfice qu'elle apportera aux opérations et à l'architecture existantes, etc., mais plus du point de vue du coût.

De plus, APISIX prend en charge la configuration simultanée de plusieurs découvertes de services. De nombreuses entreprises, pour des raisons historiques, peuvent avoir plusieurs systèmes de découverte de services. Par exemple, pour autant que je sache, certaines entreprises auront à la fois l'ancienne découverte de services Eureka et la nouvelle découverte de services Nacos. APISIX doit simplement activer à la fois Eureka et Nacos pour faire face à cette situation.

Si vous configurez actuellement des nœuds en amont directement sur APISIX, vous pouvez également envisager de déployer un système de découverte de services séparé et de faire en sorte que le système de découverte de services stocke la configuration spécifique des nœuds. L'avantage de déplacer la configuration des nœuds en amont, d'APISIX, vers un système de découverte de services dédié est que le client peut faire l'enregistrement du service lui-même, et le système de découverte de services dédié fournit souvent des fonctionnalités supplémentaires telles que des vérifications de santé plus riches.

À l'avenir, nous prendrons également en charge l'intégration de divers composants d'enregistrement et de découverte de services sur le contrôleur APISIX Ingress pour faciliter l'utilisation par les utilisateurs. À ce moment-là, les utilisateurs pourront non seulement spécifier les points de terminaison du service K8s comme nœuds en amont sur le contrôleur APISIX Ingress, mais aussi intégrer les nœuds obtenus par découverte de services.