zetcd löst, wie die Abhängigkeit von Anwendungen von ZooKeeper entfernt wird

Verteilte Systeme sind in der Regel auf ein Schlichtungssystem angewiesen, um zusammenzuarbeiten. Im Allgemeinen nutzen solche Systeme die Schlichtung, um die genaue Übertragung von Informationen sicherzustellen und Split-Brain zu vermeiden. Solche Systeme opfern Vielseitigkeit im Austausch für großen Gestaltungsspielraum, eine Praxis, die sich deutlich in der Verbreitung von Implementierungen zeigt. Es gibt viele solcher Systeme, wie zum Beispiel: Chubby, ZooKeeper, etcd und Consul usw. Obwohl die Konzepte und Protokolle dieser Systeme unterschiedlich sind, bieten sie alle eine ähnliche verteilte Schlichtung auf Schlüsselwertbasis. Im Rahmen des Plans, etcd zur bekanntesten Grundkomponente verteilter Systeme zu machen, hat das etcd-Team einen neuen Agenten, zetcd, entwickelt, der es dem etcd-Cluster ermöglicht, ZooKeeper-Dienstanfragen ohne Änderungen zu verarbeiten.

ZooKeeper war die erste Open-Source-Implementierung einer Schlichtungssoftware, was dazu führte, dass sie zum bevorzugten Backend für viele verteilte Systeme wurde. Theoretisch sollten diese Systeme mit etcd kompatibel sein, aber aus historischen Gründen ist dies nicht der Fall; etcd-Cluster können ZooKeeper nicht ersetzen, und ihre Datenmodelle und Client-Protokolle sind nicht mit ZooKeeper-Anwendungen kompatibel und umgekehrt. Wenn das System bereits in Produktion ist, besteht kaum ein Anreiz, es in ein neues Backend einzubinden und neue Komplexität einzuführen.

Glücklicherweise bereitet sich die etcd v3-API auf die Implementierung der Simulationsunterstützung für das ZooKeeper-Datenmodell über einen Standard-Proxy vor. zetcd ist ein neues Open-Source-Projekt, das vom etcd-Team entwickelt wurde veröffentlicht. Ziel ist die Verwaltung und Bereitstellung des zetcd-Systems in Produktionssystemen.

zetcd-Agent wird vor dem etcd-Cluster bereitgestellt und bedient einen simulierten ZooKeeper-Client-Port, sodass ZooKeeper-Anwendungen nativ etcd in der oberen Ebene aufrufen können. Im Allgemeinen akzeptiert zetcd ZooKeeper-Clientanfragen, konvertiert sie in das Datenmodell und die API von etcd, leitet die Anfragen an etcd weiter und leitet die Rückgabeinformationen dann auf eine für den Client verständliche Weise zurück. Die Leistung von zetcd ist mit der von ZooKeeper vergleichbar und vereinfacht die Verwaltungs- und Betriebskomplexität zwischen ZooKeeper-Cluster und etcd. In diesem Artikel erfahren Sie, wie Sie zetcd verwenden, wie zetcd funktioniert und welche Leistungsbenchmarks es gibt.

Was zetcd ausführen muss, ist ein Go-Compiler, Quellcode aus dem Internet und ein System, das etcd ausführen kann. Das folgende Beispiel zeigt, wie Sie den zetcd-Quellcode erhalten und den ZooKeeper-Befehl auf zetcd ausführen. Da etcd und zetcd auf dem Entwicklungszweig basieren, wird davon abgeraten, dies in einer Produktionsumgebung zu tun. Dies ist nur ein einfaches Beispiel, um die Verwendung zu erklären.

Besorgen Sie sich zunächst die Quellcodes etcd und zetcd und kompilieren Sie sie in Binärcodes:

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

Zweitens führen Sie etcd aus und verbinden zetcd mit dem etcd-Clientserver:

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

Probieren Sie zetd aus, indem Sie ein Abonnement hinzufügen und einen Schlüssel erstellen:

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

Konzeptionell vervollständigt das obige Beispiel das Hinzufügen einer Ebene von zetcd zu einer einzelnen etcd-Instanz.

Im Detail wird zetcd das Datenmodell von ZooKeeper in eine angepasste etcd-API übersetzen. Für Schlüsselsuchen konvertiert zetcd das hierarchische ZooKeeper-Verzeichnis in den flachen binären Schlüsselraum von etcd. Um Metadaten zu verwalten, nutzt zetcd beim Schreiben in das etcd-Backend Transaktionen auf Speicherebene, um die Informationen sicher und atomar auf ZooKeeper-Znode-Informationen zu aktualisieren.

ZooKeeper listet Schlüssel in einem Verzeichnisformat (getChildren) auf, während etcd Schlüssel in einem Intervallformat (Range) auflistet. Die folgende Abbildung erläutert, wie zetcd Schlüssel unter etcd codiert, um die Auflistung in Verzeichnisform effektiv zu unterstützen. Alle zetcd-Schlüssel in etcd haben ein Präfix, das den vollständigen Verzeichnisnamen enthält (zum Beispiel: „/“ und „/abc“ stehen für Tiefen von 0 bzw. 1). Um ein Verzeichnis aufzulisten, gibt zetcd eine vorangestellte Bereichsanforderung aus (z. B. ["/zk/key/002/abc/", "/zk/key/002/abc0"), um die Verzeichnisse aufzulisten, die der Verzeichnistiefe und dem Pfad entsprechen . Alle Schlüssel unter /abc/. Die Tiefenbeschränkung gilt nur für das Verzeichnis selbst; wenn zetcd nur den Pfad, nicht aber die Tiefe verwendet, gibt etcd alle Schlüssel in diesem Verzeichnis zurück und zetcd verwirft das Ergebnis, andernfalls werden nur die Schlüssel in diesem Verzeichnis zurückgegeben.

Jeder ZooKeeper-Schlüssel enthält einige Metadaten im ZNode, nämlich Schlüsselanpassung, Version und Berechtigungen usw. Obwohl etcd auch Metadaten für jeden Schlüssel hat, ist es viel einfacher als ZNode. Da es beispielsweise kein Verzeichnis gibt, gibt es keine Subversion, weil etcd einen rollenbasierten Authentifizierungsmechanismus verwendet, es keine ACL gibt und weil die eigentliche Uhr liegt außerhalb des Gültigkeitsbereichs. Es gibt keinen Zeitstempel. Diese zusätzlichen Metadaten werden den entsprechenden Schlüsseln zugeordnet, um einen vollständigen ZNode zu beschreiben. Beim Ändern von Metadaten verwendet zetcd Soft-Transaktionen auf Speicherebene, um eine Teilmenge von Schlüsseln automatisch zu aktualisieren und so sicherzustellen, dass ZNodes ohne teure Sperrmechanismen konsistent bleiben können.

Darüber hinaus kann zetcd eine dynamische Überprüfung mit einem autorisierten ZooKeeper-Server durchführen. Zum Vergleich: zetcd kann sowohl eine Verbindung zu etcd als auch zu einem externen ZooKeeper-Server herstellen. Wenn der Client in diesem Modus eine Anfrage an zetcd initiiert, wird die Anfrage sowohl an zetcd als auch an den ZooKeeper-Server weitergeleitet. Wenn die von den beiden Servern geantworteten Daten inkonsistent sind, markiert zetcd eine Warnung für diese Antwort.

由于数据的转换以及额外的网络开销，也许很容易觉得这样的模拟不切实际。尽管对于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的实现，并为运维和二次开发提供了系统的指导和建议。

Das obige ist der detaillierte Inhalt vonzetcd löst, wie die Abhängigkeit von Anwendungen von ZooKeeper entfernt wird. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!