etcd - Aperçu

table des matières

etcd

etcd est un projet open source développé à l'aide de Golang initié par l'équipe CoreOS en juin 2013. Basé sur l'algorithme de cohérence fort de Raft, son objectif est de créer une base de données clé / valeur distribuée hautement disponible et fortement cohérente. , Focus sur le partage de configuration (configuration partagée) et la découverte de services (découverte de services). etcd est actuellement mis à jour vers la version v3 et a été utilisé dans des projets tels que CoreOS, Kubernetes, Cloud Foundry, etc.

Un magasin de valeurs-clés distribué et fiable pour les données les plus critiques d'un système distribué

• Site officiel: https://etcd.io/
• Github ： https: //github.com/etcd-io/etcd

En tant que projet inspiré de ZooKeeper, etcd, en plus d'avoir des fonctions similaires, il se concentre sur les quatre points suivants:

1. Simple : facile à déployer et à utiliser. Fournissez l'API REST et gRPC.
2. Sécurité : prend en charge la certification de sécurité SSL en option.
3. Rapide : chaque instance prend en charge 10 000 opérations d'écriture par seconde.
4. Fiabilité : l'utilisation de l'algorithme Raft garantit une forte cohérence des données distribuées.

Le scénario d'application classique d'etcd est de stocker des métadonnées dans le système de contrôle, donc etcd ne remplace pas d'autres NoSQL, et encore moins le stockage principal des données d'application, etcd devrait essayer de stocker uniquement les informations de configuration des services dans le système.

etcd fournit les fonctionnalités suivantes:

• Fournir une interface pour le stockage et l'accès aux données : un protocole de cohérence fort garantit que par la pluralité de nœuds dans les données du cluster, etc. Utilisé pour stocker des méta-informations et partager la configuration.
• Fournir un mécanisme de surveillance : le client peut surveiller une clé ou certains changements clés pour surveiller et pousser les changements.
• Fournir un mécanisme d'expiration et de renouvellement de clé : le client implémente le renouvellement via une actualisation régulière, qui est utilisée pour la surveillance du cluster et la découverte d'enregistrement de service
• Fournit un support atomique CAS (Compare And Swap) et CAD (Compare And Delete) : utilisé pour les verrous distribués et les élections de leader.

etcd contre ZooKeeper contre Consul

Les trois produits Etcd, Zookeeper et Consul sont souvent utilisés par nous pour la sélection. Les fonctionnalités fournies par etcd et ZooKeeper sont très similaires. Ils sont à la fois communs et cohérents de stockage de méta-informations. Tous deux fournissent un mécanisme Watch pour la notification et la distribution des modifications. Ils sont tous utilisés par les systèmes distribués comme stockage d'informations partagées, et leurs positions dans l'écosystème logiciel sont presque les mêmes, ce qui peut se remplacer.

ZooKeeper est hébergé par la Fondation Apache, développé en Java et fournit des interfaces RPC. Il a d'abord été incubé dans le projet Hadoop et largement utilisé dans les systèmes distribués tels que Hadoop, Solr, Kafka et Mesos. Et etcd est une étoile montante, se concentrant principalement sur des dimensions telles que le protocole de cohérence, la facilité d'utilisation, l'exploitation et la maintenance, et la sécurité. En revanche, ZooKeeper présente les inconvénients de «complexité», de «liaison de langage» et de «développement lent». Voici les comparaisons entre les deux:

• Protocole de conformité : etcd utilise le protocole Raft, Zookeeper utilise le protocole ZAB (protocole de type PAXOS), le premier est plus facile à comprendre et facilite la mise en œuvre de l'ingénierie;
• Stockage de données : etcd prend en charge le modèle de données de contrôle d'accès concurrentiel multi-version (MVCC) et prend en charge l'interrogation des paires clé-valeur de la version précédente.
• Fonctionnement et entretien : etcd est facile à utiliser et à entretenir, tandis que Zookeeper est difficile à utiliser et à entretenir;
• Sécurité : etcd prend en charge le protocole HTTPS, mais Zookeeper fait défaut à cet égard;
• API : etcd fournit des API HTTP + JSON et gRPC, multi-plateforme et multi-langage, Zookeeper doit utiliser son client;

L'objectif de Consul est plus spécifique. Etcd et ZooKeeper fournissent des capacités de stockage distribuées et cohérentes. Des scénarios métier spécifiques doivent être implémentés par les utilisateurs eux-mêmes, tels que la découverte de services et les changements de configuration. D'un autre côté, Consul considère la découverte de services et les changements de configuration comme ses principaux objectifs, et inclut également le stockage des clés / valeurs. Dans l'écosystème logiciel, plus les composants sont abstraits, plus le champ d'application est large, mais en même temps, il doit y avoir des lacunes pour répondre aux besoins de scénarios commerciaux spécifiques.

Scénarios d'application d'etcd

Inscription et découverte de service

La découverte de services est l'un des problèmes les plus courants dans les systèmes distribués, à savoir: "Comment les processus ou les services d'un même cluster distribué peuvent-ils se trouver et établir une connexion?" En bref, les processus ou services du cluster doivent être découverts par d'autres, et ils doivent également être découverts par eux-mêmes, et ils peuvent être trouvés et connectés par les noms de chacun.

Pour résoudre le problème de la découverte de services, les trois piliers suivants sont nécessaires, dont aucun n'est indispensable:

1. Un répertoire de stockage de services fortement cohérent et hautement disponible (Service Registry) : etcd basé sur l'algorithme Raft est né d'un tel répertoire de stockage de services fortement cohérent et hautement disponible.
2. Un mécanisme d'enregistrement des services et de surveillance de l'état de santé des services : les utilisateurs peuvent enregistrer des services dans etcd, définir la clé TTL pour les services enregistrés, et conserver régulièrement le rythme cardiaque du service pour obtenir l'effet de surveillance de l'état de santé.
3. Un mécanisme de recherche et de connexion des services : les services enregistrés sous le thème spécifié par etcd se trouvent également sous le thème correspondant. Afin d'assurer la connectivité, nous pouvons déployer un mode proxy etcd sur chaque machine de service, afin que nous puissions nous assurer que les services qui peuvent accéder au cluster etcd peuvent être connectés les uns aux autres.

• Ajout dynamique de services dans l'architecture des microservices: l'architecture des microservices, c'est-à-dire que plusieurs microservices travaillent ensemble pour former une architecture puissante. Dans l'architecture des microservices, comment ajouter dynamiquement des services de manière transparente est le premier problème à résoudre. Grâce au mécanisme de découverte de service, un catalogue d'un certain nom de service est enregistré dans etcd et les adresses IP des nœuds de service disponibles sont stockées dans le catalogue. Lors du processus d'utilisation du service, recherchez simplement le nœud de service disponible dans le catalogue de services pour l'utiliser.

• Le redémarrage en cas d'échec de l'instance dans la plate-forme PaaS est transparent : les applications de la plate-forme PaaS sont généralement multi-instance, et le client peut accéder de manière transparente à ces multiples instances via le nom de domaine (domaine), et l'équilibrage de charge peut également être réalisé. Cependant, une certaine instance de l'application peut échouer et redémarrer à tout moment, puis la configuration de résolution de nom de domaine doit être mise à jour dynamiquement. Ce problème de configuration dynamique peut être facilement résolu grâce à la fonction de découverte de service d'etcd.

Actualités publier et s'abonner

Dans un système distribué, la publication et l'abonnement de messages constituent une méthode de communication efficace entre les composants (services). C'est-à-dire: créer un centre de partage de configuration, où le producteur du message (producteur) publie des messages et le consommateur du message (consommateur) s'abonne au sujet qui lui tient à cœur (sujet), une fois que le sujet aura un message publié, il en informera l'abonné en temps réel (Abonné). De cette manière, une gestion centralisée et une mise à jour dynamique de la configuration du système distribué peuvent être réalisées.

• Les informations de configuration utilisées par l'application sont stockées dans etcd pour une gestion centralisée (centre de partage de configuration) : l'application obtient activement des informations de configuration d'etcd au démarrage, et en même temps, enregistre un Watcher sur etcd et attend (l'abonnement est terminé). Lorsque la configuration est mise à jour, etcd informera les abonnés en temps réel pour atteindre l'objectif d'obtenir les dernières informations de configuration.

• Dans le service de recherche distribuée, les méta-informations indexées et l'état des nœuds des machines du cluster de serveurs sont stockés dans etcd pour que chaque client s'abonne : l'utilisation de la fonction clé TTL d'etcd peut garantir que l'état de la machine est mis à jour en temps réel.

• Système de collecte de journal distribué : Le travail de base de ce système est de journaux distribués à frais virés sur des machines différentes. Les collecteurs allouent généralement des unités de tâches de collecte en fonction des applications ou des sujets, de sorte que vous pouvez créer un répertoire nommé d'après l'application ou le thème sur etcd, et stocker toutes les adresses IP de la machine liées à cette application ou à ce thème dans le répertoire sous la forme de sous-répertoires , Et puis configurez un observateur récursif etcd pour surveiller de manière récursive les modifications de toutes les informations dans le répertoire de l'application ou du thème. De cette manière, lorsque l'IP de la machine (message) change, le collecteur peut être averti en temps réel pour ajuster l'allocation des tâches.

• Les informations dans le système doivent être obtenues de manière dynamique et automatique et une intervention manuelle pour modifier le contenu de la demande d'informations : généralement l'interface est exposée, comme l'interface JMX, pour obtenir des informations d'exécution. Après l'introduction d'etcd, il n'est pas nécessaire d'implémenter un ensemble de solutions par vous-même, tant que les informations sont stockées dans le répertoire etcd spécifié, ces répertoires d'etcd sont accessibles de l'extérieur via l'interface HTTP.

Notification et coordination distribuées

La notification et la coordination des systèmes distribués sont quelque peu similaires à la publication et à l'abonnement de messages. Les deux utilisent le mécanisme Watcher dans etcd, et réalisent la notification et la coordination entre différents systèmes dans un environnement distribué via le mécanisme d'enregistrement et de notification asynchrone, afin de réaliser le traitement en temps réel des modifications de données. La différence est que le premier sert le système distribué lui-même, tandis que le second sert le niveau d'application supérieur.

L'implémentation est généralement comme ceci: différents systèmes enregistrent le même répertoire sur etcd, et définissez Watcher pour observer les changements du répertoire (si vous avez besoin de changer de sous-répertoires, vous pouvez définir le mode récursif), quand un système met à jour etcd , Ensuite, le système avec Watcher sera informé et le traitera en conséquence.

• Détection de pulsations à faible couplage via etcd : Le système de détection et le système détecté sont associés à un répertoire sur etcd au lieu de directement, ce qui peut réduire considérablement le couplage du système.

• Planification complète du système via etcd : Un système se compose de deux parties: une console et un système push. La responsabilité de la console est de contrôler le système push pour effectuer le travail push correspondant. Certaines opérations effectuées par l'administrateur sur la console modifient en fait le statut de certains nœuds de répertoire sur etcd, et etcd notifiera ces modifications aux clients du système push enregistrés auprès de Watcher, et le système push effectuera alors les tâches push correspondantes.

• Rapports de travail complets via etcd : la plupart des systèmes de distribution de tâches similaires, une fois les sous-tâches démarrées, enregistrez un répertoire de travail temporaire dans etcd et rapportez leur progression régulièrement (écrivez la progression dans ce répertoire temporaire), de sorte que la gestion des tâches La personne peut connaître la progression de la tâche en temps réel.

Serrure distribuée

Étant donné qu'etcd utilise l'algorithme Raft pour garantir une forte cohérence des données, la valeur stockée dans le cluster pour une opération donnée doit être globalement cohérente, il est donc facile à utiliser pour implémenter des verrous distribués. Il existe deux façons d'utiliser le service de verrouillage, l'une consiste à maintenir une utilisation exclusive et l'autre à contrôler la synchronisation.

1. Gardez exclusif : c'est-à-dire un verrou exclusif, et un seul utilisateur qui acquiert le verrou peut enfin l'obtenir. À cette fin, etcd fournit un ensemble d'API qui implémentent l'opération atomique de verrouillage distribué CAS (Compare And Swap). En définissant la valeur prevExist, vous pouvez vous assurer que lorsque plusieurs nœuds créent un répertoire en même temps, un seul réussit. L'utilisateur qui a été créé avec succès peut être considéré comme ayant obtenu le verrou.

2. Contrôle de la synchronisation : c'est-à-dire des verrous de synchronisation . Tous les utilisateurs qui souhaitent obtenir des verrous seront planifiés pour l'exécution, mais l'ordre d'obtention des verrous est également globalement unique et détermine l'ordre d'exécution. etcd fournit également un ensemble d'API (création automatique de clés ordonnées) à cet effet. Lors de la création d'une valeur pour un répertoire, elle est spécifiée comme une action POST, de sorte qu'etcd génère automatiquement une clé de valeur maximale actuelle dans le répertoire et stocke cette nouvelle valeur ( Numéro client). Dans le même temps, vous pouvez utiliser l'API pour répertorier toutes les valeurs de clé dans le répertoire actuel dans l'ordre. À ce stade, la valeur de ces clés est la séquence temporelle du client, et la valeur stockée dans ces clés peut être le nombre représentant le client.

File d'attente distribuée

La file d'attente distribuée est similaire à l'utilisation du verrou de synchronisation distribué mentionné ci-dessus, à savoir: créer une file d'attente premier entré premier sorti et garantir l'ordre. Une autre implémentation plus intéressante consiste à s'assurer que la file d'attente atteint une certaine condition, puis à s'exécuter uniformément dans l'ordre. L'implémentation de cette méthode peut créer un autre nœud / queue / condition dans le répertoire / queue.

• La condition peut indiquer la taille de la file d'attente : par exemple, une grande tâche doit être exécutée lorsque de nombreuses petites tâches sont prêtes. Chaque fois qu'une petite tâche est prête, le numéro de condition est ajouté au nombre de 1, jusqu'à ce qu'il atteigne le nombre spécifié par la grande tâche, puis la file d'attente est exécutée. Dans la série de petites tâches, la grande tâche est enfin exécutée.
• La condition peut indiquer si une certaine tâche est dans la file d'attente : cette tâche peut être le premier programme d'exécution de toutes les tâches de tri, ou il peut s'agir d'un point de la topologie qui n'a pas de dépendances. En général, ces tâches doivent être exécutées avant que d'autres tâches de la file d'attente puissent être exécutées.
• La condition peut représenter un autre type de notification pour démarrer l'exécution de la tâche : elle peut être spécifiée par le programme de contrôle, et lorsque la condition change, la tâche de file d'attente commence à être exécutée.

Surveillance du cluster

La réalisation de la surveillance des clusters via etcd est très simple et en temps réel. Deux fonctions principales d'etcd sont appliquées:

1. Mécanisme d'observateur : lorsqu'un nœud disparaît ou change, Watcher le découvrira et en informera l'utilisateur la première fois.
2. Mécanisme clé TTL : par exemple, envoyez un battement de cœur toutes les 30 secondes pour que le nœud qui représente la survie de la machine continue d'exister, sinon le nœud disparaîtra.

De cette manière, l'état de santé de chaque nœud peut être détecté pour la première fois pour répondre aux exigences de surveillance du cluster.

Élection du chef

De plus, l'utilisation de verrous distribués peut facilement implémenter l'élection de leader pour plusieurs nœuds du cluster. Ce type de scénario est généralement constitué de calculs de CPU à long terme ou de machines utilisant des opérations d'E / S. Seul le calcul ou le traitement du leader choisi est requis une fois, et les résultats peuvent être copiés vers d'autres suiveurs. Évitant ainsi la duplication du travail et économisant les ressources informatiques.

Le scénario classique consiste à établir un index complet dans le système de recherche: si chaque machine effectue à nouveau la création d'index, non seulement cela prend du temps, mais la cohérence de la création d'index ne peut pas être garantie. En créant un nœud dans le mécanisme CAS d'etcd en même temps, la machine créée avec succès agit en tant que leader, effectue le calcul d'index, puis distribue les résultats du calcul à d'autres nœuds.

L'équilibrage de charge

Un équilibreur de charge souple peut être réalisé via etcd, ce qui se traduit par deux aspects:

1. L'accès aux informations stockées dans l'architecture distribuée d'etcd prend en charge l'équilibrage de charge : une fois etcd mis en cluster, chaque nœud central etcd peut gérer les demandes des utilisateurs. Par conséquent, bien qu'etcd stocke plus de métadonnées du système de contrôle, c'est également un bon choix de stocker les données de message avec une petite quantité de données et fréquemment consultées directement dans etcd, comme la table de code secondaire couramment utilisée dans les systèmes d'entreprise (dans le tableau Stockez le code dans etcd, stockez la signification spécifique du code dans etcd, le système métier appelle le processus de recherche de la table, vous devez rechercher la signification du code dans la table).
2. Utilisez etcd pour gérer une table de nœuds d'équilibrage de charge : etcd peut surveiller l'état de plusieurs nœuds dans un cluster. Lorsqu'une requête est envoyée, il peut la transmettre à plusieurs états survivants par interrogation. Semblable à KafkaMQ, ZooKeeper est utilisé pour maintenir l'équilibre de charge entre les producteurs et les consommateurs. Vous pouvez également utiliser etcd pour effectuer le travail de ZooKeeper.