La découverte de services est née lorsque les applications ont commencé à s'exécuter et à être accessibles en dehors d'une seule machine. L'architecture réseau actuelle est telle que chaque hôte possède une adresse IP indépendante et que la découverte de services obtient essentiellement l'adresse IP déployée par le service d'une manière ou d'une autre.
Le protocole DNS est le premier protocole à traduire un nom de réseau en adresse IP de réseau. Dans la sélection initiale de l'architecture, DNS+LVS+Nginx satisfait essentiellement à la découverte de tous les services RESTful. À l'heure actuelle, la liste d'adresses IP du service est généralement configurée dans nginx. ou LVS. Plus tard, les services RPC sont apparus et les services en ligne et hors ligne sont devenus plus fréquents. Les gens ont commencé à rechercher un produit de centre d'enregistrement capable de prendre en charge les dynamiques en ligne et hors ligne et de pousser les modifications de la liste IP.
L'industrie du logiciel Internet privilégie généralement les produits open source, car le code des produits open source est transparent, on peut participer à la co-construction, il existe une communauté de communication et d'apprentissage, et bien sûr, plus important encore, c'est gratuit. Les développeurs individuels ou les petites et moyennes entreprises choisissent souvent les produits open source comme premier choix.
1 Produits open source
1.1 Gardien de zoo
Le produit de registre de services classique (bien que son positionnement d'origine ne soit pas ici), est depuis longtemps le seul choix auquel les Chinois pensent lorsqu'ils mentionnent le registre de services RPC, qui est en grande partie le même que Dubbo en Chine en termes de popularité.
1.2 Consul et Eurêka
Tous deux sont apparus en 2014 :
- Consul est conçu pour inclure de nombreuses fonctions nécessaires à la gouvernance des services distribués et peut prendre en charge l'enregistrement des services, la vérification de l'état, la gestion de la configuration, Service Mesh, etc.
- Eureka est devenu populaire grâce au concept de microservices, et son intégration profonde avec l'écologie SpringCloud a également acquis un grand nombre d'utilisateurs
1.3 Naco
Fort de l'expérience d'Alibaba en matière de production de services à grande échelle, il tente d'offrir aux utilisateurs un nouveau choix sur le marché de l'enregistrement des services et de la gestion de la configuration.
Figure 1 Découverte du service :
1.4 Avantages des produits open source
Les développeurs peuvent lire le code source pour comprendre la conception fonctionnelle et la conception architecturale du produit, et en même temps tester les performances via un déploiement local, suivi d'articles de comparaison de divers produits.
Cependant, la comparaison actuelle des centres d'enregistrement reste souvent dans la comparaison de fonctions superficielles, sans discussion approfondie sur l'architecture ou les performances.
1.5 Points douloureux
Il s'agit du registre de services qui est souvent caché derrière le cadre de services en tant que produit pris en charge de manière silencieuse. Un excellent cadre de service prend souvent en charge plusieurs centres de configuration, mais le choix du centre d'enregistrement reste fortement lié au cadre de service. Une situation courante est qu'un cadre de service aura un centre d'enregistrement de service par défaut. Bien que cela évite aux utilisateurs d'avoir à choisir un modèle, les limites d'un centre d'enregistrement unique obligent les utilisateurs à déployer plusieurs ensembles de centres d'enregistrement complètement différents lorsqu'ils utilisent plusieurs cadres de services. La collaboration des données entre ces centres d'enregistrement est également une question.
Cet article présente en profondeur les principes de conception du registre Nacos sous différents angles et tente de résumer et d'expliquer les principaux points qui doivent être suivis et pris en compte dans la conception du produit du registre de services à partir de notre expérience et de nos recherches.
2 Modèle de données
Les données de base du centre d'inscription :
- Nom du service
- son adresse réseau correspondante
Lorsqu'un service enregistre plusieurs instances, nous devons filtrer les instances défectueuses ou répartir le trafic en fonction de certaines caractéristiques des instances. Nous devons donc stocker certains attributs tels que l'état de santé et le poids dans les instances. À mesure que l'échelle du service s'étend, il est progressivement nécessaire de définir certaines règles d'autorisation au niveau du service dans son ensemble et certains commutateurs efficaces pour toutes les instances, de sorte que certains attributs seront définis au niveau du service. Plus tard, nous avons constaté qu'une seule instance de service devait être divisée en plusieurs sous-ensembles. Par exemple, si un service est déployé dans plusieurs salles informatiques, il peut être nécessaire de configurer différentes instances de chaque salle informatique. Un autre niveau de données est défini entre le service et l'instance.
Par rapport
- Zookeeper ne conçoit pas de modèle de données pour la découverte de services. Ses données sont organisées dans un arbre KV plus abstrait, donc théoriquement toutes les données sémantiques peuvent être stockées
- Eureka ou Consul réalisent tous deux une expansion des données au niveau de l'instance, qui peut répondre à la plupart des scénarios, mais ne peut pas répondre au stockage de données de services à grande échelle et multi-environnements.
- Le modèle de données extrait par Nacos après des années d'expérience en production interne est un modèle d'instance de cluster de services à trois couches. Il satisfait essentiellement au stockage des données et à la gestion des services dans tous les scénarios.
Bien que le modèle de données de Nacos soit relativement complexe, il ne vous oblige pas à utiliser toutes les données qu'il contient. Dans la plupart des scénarios, vous pouvez choisir d'ignorer ces attributs de données. Pour le moment, il peut être réduit au même modèle de données que Eurêka et Consul.
Modèle de séparation des données
En tant que composant de service partagé, il doit être capable de garantir l'isolation et la sécurité des données lorsqu'il est utilisé par plusieurs utilisateurs ou parties professionnelles, ce qui est très courant dans des scénarios commerciaux légèrement plus importants. D'un autre côté, le registre de services prend souvent en charge le déploiement sur le cloud. À l'heure actuelle, le modèle de données du registre de services doit pouvoir s'adapter au modèle général sur le cloud.
Zookeeper, Consul et Eureka n'ont pas de modèle clair pour l'isolation des services au niveau open source. Nacos a réfléchi dès le début à la manière de permettre aux utilisateurs d'isoler les données dans plusieurs dimensions et en même temps de migrer en douceur vers le service correspondant sur Alibaba Cloud.produit commercial.
Figure 3 Modèle d'isolation logique des données à quatre couches du service :
Le compte utilisateur peut correspondre à une entreprise ou à un particulier indépendant. Généralement, ces données ne seront pas transmises de manière transparente au centre d'enregistrement du service. Un compte utilisateur peut créer plusieurs espaces de noms, et chaque espace de noms correspond à une instance client. Le cluster physique du registre correspondant à cet espace de noms peut être routé selon les règles, afin que la mise à niveau interne et la migration du registre puissent être contrôlées. n'en ont pas conscience, et en même temps, selon le niveau des utilisateurs, des clusters physiques avec différents niveaux de service sont proposés aux utilisateurs.
Plus bas se trouve un identifiant de service bidimensionnel composé d'un groupe de services et d'un nom de service, qui peut satisfaire l'isolation des services au niveau de l'interface.
Une autre nouvelle fonctionnalité introduite par Nacos 1.0.0 est : l'instance temporaire et l'instance persistante. La clé de la distinction définitionnelle entre les instances éphémères et persistantes réside dans la manière dont les contrôles de santé sont effectués. Les instances temporaires utilisent le mode de reporting côté client, tandis que les instances persistantes utilisent le mode de détection inverse côté serveur. Les instances temporaires doivent pouvoir supprimer automatiquement les instances défectueuses sans instances de stockage persistantes, de telles instances conviennent donc aux protocoles de type Gossip. L'instance persistante de droite utilise la méthode de vérification de l'état de détection côté serveur, car le client ne signalera pas le battement de cœur, il est donc naturellement impossible de supprimer automatiquement l'instance hors ligne.
Figure 4 Instance temporaire et instance persistante :
Pour les moyennes et grandes entreprises, les deux types de services sont disponibles :
- Certains composants de base, tels que les bases de données, les caches, etc., ne peuvent souvent pas signaler les battements de cœur. Lors de l'enregistrement de ce type de service, il doit être enregistré en tant qu'instance persistante.
- Pour les services professionnels de niveau supérieur, tels que les microservices ou les services Dubbo, le côté fournisseur du service prend en charge l'ajout d'une logique pour signaler les pulsations, et des méthodes d'enregistrement de service dynamiques peuvent être utilisées.
Nacos 2.0 utilise les paramètres persistants et non persistants, mais avec des ajustements. Les attributs persistants et non persistants dans Nacos 1.0 sont stockés et identifiés comme métadonnées d'une instance. Par conséquent, des instances persistantes et des instances non persistantes peuvent exister sous le même service. Mais en utilisation réelle, ce mode :
- Cela apportera une grande confusion et une grande complexité au personnel d'exploitation et de maintenance.
- Du point de vue de l'architecture du système, il existe certaines contradictions dans le scénario où un service possède des instances à la fois persistantes et non persistantes.
En conséquence, cette capacité n’est en fait pas largement utilisée. Afin de simplifier le modèle de données de service de Nacos, de réduire la complexité d'exploitation et de maintenance et d'améliorer la convivialité de Nacos, dans Nacos2.0 :
- Si les données persistantes sont extraites au niveau du service
- Il n'est plus permis à un service d'avoir des instances persistantes et des instances non persistantes en même temps, et les attributs persistants de l'instance héritent des attributs persistants du service.
3 Cohérence des données
Les systèmes distribués sont un sujet éternel. Du point de vue du niveau protocolaire, le choix de la cohérence n'a pas été rejoint par de nouveaux membres depuis longtemps. À l'heure actuelle, la base
Peut appartenir à deux :
- Cohérence d'écriture en un seul point du déploiement non homologue basé sur Leader
- Cohérence multi-écriture pour les déploiements peer-to-peer
Lors du choix d'un centre d'enregistrement de services, aucun protocole ne peut couvrir tous les scénarios, tels que :
- Lorsque le nœud de service enregistré n'envoie pas régulièrement de battements de cœur au centre d'enregistrement, le protocole de consensus fort semble être la seule option, car l'enregistrement de compensation des données ne peut pas être effectué via les battements de cœur et le premier enregistrement doit garantir que les données ne seront pas perdues.
- Et lorsque le client envoie régulièrement des battements de cœur pour signaler l'état de santé, le taux de réussite du premier enregistrement n'est pas très critique (bien sûr, il est également critique, mais relativement parlant, nous tolérons une petite quantité d'échecs d'écriture de données), car le suivi -up peut toujours passer Si le battement de cœur compense les données, le goulot d'étranglement en un seul point du protocole Paxos ne sera pas rentable. C'est pourquoi Eureka n'utilise pas le protocole Paxos mais utilise un mécanisme de renouvellement personnalisé.
Ces deux protocoles de cohérence des données ont leurs propres scénarios d'utilisation, et les différentes exigences d'enregistrement du service conduiront à l'utilisation de protocoles différents. Le comportement de Zookeeper sous le système Dubbo est en fait plus approprié pour utiliser le mécanisme Renew d'Eureka, car le service Dubbo s'enregistre auprès de Zookeeper en tant que nœud temporaire et doit régulièrement envoyer des battements de cœur à Zookeeper pour renouveler le nœud, et lorsque le service est hors ligne. , le Zookeeper Supprime les nœuds correspondants. Bien que Zookeeper utilise ZAB pour garantir une forte cohérence des données, sa salle informatique manque de capacités de reprise après sinistre et ne peut pas s'adapter à certains scénarios à grande échelle.
Nacos 1.0.0 prend officiellement en charge la coexistence de deux protocoles de cohérence, AP et CP, car il doit prendre en charge l'enregistrement de plusieurs types de services et dispose de fonctionnalités essentielles telles que la reprise après sinistre dans une salle informatique et l'expansion de cluster. 1.0.0 Restructuré la logique de lecture-écriture et de synchronisation des données et séparé le CRUD lié à l'entreprise de la logique de synchronisation de cohérence sous-jacente. Ensuite, résumez la lecture et l'écriture du métier (principalement l'écriture, car la lecture utilisera directement le cache de la couche métier) dans le type de données défini par Nacos, et appelez le service de cohérence pour la synchronisation des données. Lorsque vous décidez d'utiliser la cohérence CP ou AP, utilisez un proxy pour transmettre via des règles contrôlables.
Les implémentations actuelles du protocole de consensus sont la cohérence CP basée sur Raft simplifié et la cohérence AP basée sur le protocole auto-développé Distro. Inutile de dire que le protocole Raft est écrit sur la base du Leader et que son CP n'est pas strict, mais il peut garantir la moitié de la cohérence observée et la probabilité de perte de données est faible. Le protocole Distro fait référence au ConfigServer interne et à l'open source Eureka, et obtient fondamentalement la même chose sans utiliser de stockage tiers. L'objectif de Distro est d'optimiser la logique et d'ajuster les performances.
Figure 5 Protocole de cohérence Nacos :
Cet article est publié par OpenWrite, une plateforme multi-post pour les blogs !