zetcd résout comment supprimer la dépendance des applications à ZooKeeper

Les systèmes distribués s'appuient généralement sur un système d'arbitrage pour fonctionner ensemble. Généralement, ces systèmes utilisent l'arbitrage pour garantir la transmission précise des informations afin d'éviter la division du cerveau. De tels systèmes sacrifient la polyvalence en échange d’une grande liberté de conception, une pratique clairement illustrée par la prolifération des implémentations. Il existe de nombreux systèmes de ce type, tels que : chubby, ZooKeeper, etcd et consul, etc. Bien que les concepts et les protocoles de ces systèmes soient différents, ils fournissent tous un arbitrage distribué similaire basé sur des valeurs-clés. Dans le cadre du plan visant à faire d'etcd le composant de base le plus important des systèmes distribués, l'équipe etcd a développé un nouvel agent, zetcd, qui permet au cluster etcd de consommer les demandes de service ZooKeeper sans aucune modification.

ZooKeeper a été la première implémentation open source d'un logiciel d'arbitrage, ce qui l'a amené à devenir le backend préféré de nombreux systèmes distribués. En théorie, ces systèmes devraient être compatibles avec etcd, mais pour des raisons historiques, ce n'est pas le cas ; les clusters etcd ne peuvent pas remplacer ZooKeeper, et leurs modèles de données et protocoles clients sont incompatibles avec les applications ZooKeeper et vice versa. Si le système est déjà en production, il n’y a guère d’incitation à le connecter à un nouveau backend et à introduire une nouvelle complexité.

Heureusement, l'API etcd v3 se prépare à implémenter la prise en charge de la simulation pour le modèle de données ZooKeeper via un proxy standard zetcd est un nouveau projet open source développé par l'équipe etcd. Aujourd'hui, la première version bêta de zetcd, v0.0.1, est disponible. publié L'objectif est de gérer et de déployer le système zetcd dans les systèmes de production.

zetcd est déployé devant le cluster etcd, desservant un port client ZooKeeper simulé, permettant aux applications ZooKeeper d'appeler nativement etcd dans la couche supérieure. De manière générale, zetcd accepte les demandes des clients ZooKeeper, les convertit en modèle de données et en API d'etcd, transmet les demandes à etcd, puis transmet les informations de retour d'une manière que le client peut comprendre. Les performances de zetcd sont comparables à celles de ZooKeeper et simplifient la complexité de gestion et de fonctionnement entre le cluster ZooKeeper et etcd. Cet article révélera comment utiliser zetcd, son fonctionnement et les tests de performances.

Ce dont zetcd a besoin pour fonctionner, c'est d'un compilateur go, d'un code source obtenu sur Internet et d'un système capable d'exécuter etcd. L'exemple suivant montre comment obtenir le code source de zetcd et exécuter la commande ZooKeeper sur zetcd. Étant donné que etcd et zetcd sont construits sur la base de la branche de développement, il n'est pas recommandé de le faire dans un environnement de production. Ceci est juste un exemple simple pour expliquer comment l'utiliser.

Tout d'abord, récupérez les codes sources etcd et zetcd et compilez-les en codes binaires :

go get github.com/coreos/etcd/cmd/etcd 
go get github.com/coreos/zetcd/cmd/zetcd

Deuxièmement, exécutez etcd et connectez zetcd au serveur client etcd :

#etcd uses localhost:2379 by default 
etcd & 
zetcd -zkaddr localhost:2181 -endpoints localhost:2379 &

Essayez Zetd en ajoutant un abonnement et en créant une clé :

go install github.com/coreos/zetcd/cmd/zkctl 
zkctl watch / & 
zkctl create /abc "foo"

Conceptuellement, l'exemple ci-dessus complète l'ajout d'une couche de zetcd à une seule instance d'etcd.

En profondeur, zetcd traduira le modèle de données de ZooKeeper en une API etcd adaptée. Pour les recherches de clés, zetcd convertit le répertoire hiérarchique ZooKeeper en espace de clés binaire plat d'etcd. Pour gérer les métadonnées, lors de l'écriture sur le backend etcd, zetcd utilise des transactions au niveau de la mémoire pour mettre à jour de manière sécurisée et atomique les informations vers les informations du nœud ZooKeeper.

ZooKeeper répertorie les clés dans un format de répertoire (getChildren), tandis que etcd répertorie les clés dans un format d'intervalle (Range). La figure suivante explique comment zetcd encode les clés sous etcd pour prendre en charge efficacement le listage sous forme de répertoire. Toutes les clés zetcd dans etcd ont un préfixe qui inclut le nom complet du répertoire (par exemple : "/" et "/abc" représentent respectivement des profondeurs de 0 et 1). Pour lister un répertoire, zetcd émet une requête de plage préfixée (par exemple, ["/zk/key/002/abc/", "/zk/key/002/abc0") pour lister les répertoires qui satisfont à la profondeur et au chemin du répertoire. . Toutes les clés sous /abc/. La limite de profondeur ne s'applique qu'au répertoire lui-même ; si zetcd utilise uniquement le chemin mais pas la profondeur, etcd renverra toutes les clés de ce répertoire, et zetcd ignorera le résultat, sinon seules les clés de ce répertoire seront renvoyées.

Chaque clé ZooKeeper transporte certaines métadonnées dans le ZNode, à savoir l'ajustement de la clé, la version et les autorisations, etc. Bien qu'etcd ait également des métadonnées pour chaque clé, c'est beaucoup plus simple que ZNode. Par exemple, parce qu'il n'y a pas de répertoire, il n'y a pas de subversion, parce qu'etcd utilise un mécanisme d'authentification basé sur les rôles, il n'y a pas d'ACL et parce que l'horloge réelle. est hors de portée, il n'y a pas d'horodatage. Ces métadonnées supplémentaires seront mappées aux clés correspondantes pour décrire un ZNode complet. Lors de la modification des métadonnées, zetcd utilise des transactions logicielles au niveau de la mémoire pour mettre à jour automatiquement un sous-ensemble de clés, garantissant ainsi que les ZNodes peuvent rester cohérents sans mécanismes de verrouillage coûteux.

De plus, zetcd peut effectuer une vérification dynamique avec un serveur ZooKeeper autorisé. À titre de comparaison, zetcd peut se connecter à la fois à etcd et à un serveur ZooKeeper externe. Lorsque le client lance une requête vers zetcd dans ce mode, la requête sera transmise à la fois à zeetcd et au serveur ZooKeeper. Si les données répondues par les deux serveurs sont incohérentes, zetcd signalera un avertissement pour cette réponse.

由于数据的转换以及额外的网络开销，也许很容易觉得这样的模拟不切实际。尽管对于ZooKeeper或者etcd集群来说，zetcd有额外的花销，但是它仍然有一个优势，即某些etcd应用安装完毕后仍然需要ZooKeeper来协调的场景。例如，早期用户报告称在zetcd里通过etcd的TLS加密流量比一个类似的经典ZooKeeper配置更简单。在这些场景中，支持同一种ZooKeeper协议所带来的简单可靠性比性能更重要一些。 跟etcd性能工具的接口及报告形式类似，zetcd命令行工具zkboom可以用来判断一个zetcd的性能基准是否满足要求。其它ZooKeeper性能工具应该也可以用在zetcd；zkboom为用户提供了便利，我们不妨试试用它来做下创建key的测试：

go get github.com/coreos/zetcd/cmd/zkboom 
zkboom --conns=50 --total=10000 --endpoints=localhost:2181 create

zetcd应当可以为小负载提供充分的性能保障。一个简单两节点配置的延迟基准表明zetcd是可以承受大量请求的。具体配置为两台Linux服务器通过一个千兆交换机互联，其中一台设备在RAID磁盘配置上运行代理和和服务端，另外一台设备用于产生客户请求。zkbook通过创建一个空的key存储，然后从中读取128Kbytes的键值对来进行测量。用户请求被限制在每秒2500个请求，然后逐渐增加并发客户端数量。ZooKeeper 3.4.10和etcd结果对比见下图。

下图揭示了zetcd客户端并发数与创建key的平均延迟之间的关系。由于etcd在延迟上比ZooKeeper要有5-35ms的优势，zetcd有足够余地处理由于额外负载和网络跳转造成的延迟。比起ZooKeeper，zetcd代理始终还是存在20ms左右的差距，但是从处理2500请求的吞吐量数据来看，并没有出现队列堵塞。一种对zetcd写比较慢的解释是，与读不一样，由于数据模型上存在差异，所以在每个ZooKeeper key写时需要写多个key。

下图揭示了zetcd客户端并发数与key取值的平均延迟之间的关系。由于ZooKeeper的取值延迟比etcd要快那么2ms左右，想要zetcd提供数据的速度快过ZooKeeper的话恐怕还得依赖于etcd本身性能的进一步提升。然而，尽管zetcd需要从etcd请求额外的key来模拟Zookeeper znode的元数据，zetcd的命中延迟在等待etcd key提取数据方面只增加了大概1.5ms。zetcd在key的数据提取操作方面仅需一次往返，因为读请求会被打包到一个etcd事务中。

zetcd承诺上述性能基准测试的结果是合理的，在可接受的延迟情况下，可以轻松支撑每秒上千个操作。以上模拟对于Mesos，Kafka和Drill替代ZooKeeper提供了一个替代选择。但是对于zetcd本身来说性能方面仍有不少的提升空间。与此同时测试更多的ZooKeeper应用也会进一步推动zetcd成为ZooKeeper服务器的替代品。

zetcd从去年十月开始在开源社区发行，最近刚发布第一个版本：zetcd v0.0.1。尽管是第一个beta发行版，但是已经为未来生产系统提供稳定管理和部署。如果跟etcd配合起来使用，运行zetcd的系统将会一套自驱动的“ZooKeeper”集群，它可以自动后台升级，备份和TLS管理。

etcd为分布式系统提供可靠、高效的配置管理服务，在Docker、Kubernetes、Mesos等平台中扮演了越来越重要的角色。作为2013年开始的项目，它还很年轻，官方文档中缺乏实现上全面、系统的介绍，本课程深入浅出地介绍了etcd的实现，并为运维和二次开发提供了系统的指导和建议。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!