zetcd：让应用解除对ZooKeeper的依赖
2023-09-27 14:27:26 时间
本文讲的是zetcd：让应用解除对ZooKeeper的依赖【编者的话】etcd团队最近发布了zetcd的beta版本，一款能够让etcd兼容Zookeeper协议的代理工具，用户可以通过它解除现有应用对Zookeeper服务的依赖。
分布式系统通常都依赖一个仲裁系统协同工作，一般这样的系统通过仲裁来保证信息的准确传达，以避免出现脑裂。这类系统通过牺牲通用性换来了充分的设计余地，这种做法显然已经被不断扩散的各种具体实现所例证。这样的系统有很多，例如：chubby，ZooKeeper，etcd和consul等。尽管这些系统的理念和协议不同，但是提供的都是类似的基于key-value的分布式仲裁。作为将etcd打造成分布式系统最受瞩目的基础组件计划的一部分，etcd团队开发了一款全新的代理，zetcd，无需变动就可以让etcd集群消费ZooKeeper的服务请求。
ZooKeeper是第一个开源实现的仲裁软件，这促使它成为众多分布式系统偏好的后端。理论上来说这些系统应该可以跟etcd兼容，但由于历史原因，事实并非如此；etcd集群无法替代ZooKeeper，其数据模型和客户端协议跟ZooKeeper应用不兼容；反之亦然。倘若该系统已经投产，那么几乎没什么动力可以推动它接入新的后端，引入新的复杂度。幸运的是，etcd v3 API正准备通过一个标准代理zetcd实现对ZooKeeper数据模型的模拟支持，zetcd是一个由etcd团队开发的全新开源项目，今天发布了zetcd第一个beta版本，v0.0.1，目标是在生产系统中管理和部署zetcd系统。
zetcd 代理部署在etcd集群前面，服务于一个模拟的ZooKeeper客户端端口，使得ZooKeeper应用可以在上层原生调用etcd。总体上来说，zetcd接受ZooKeeper的客户请求，转化成etcd的数据模型和API，将请求转发到etcd，然后将返回信息以客户端可以理解的方式转发回去。zetcd的性能跟ZooKeeper不相上下，并且简化了ZooKeeper集群与etcd之间的管理和操作复杂性。本文将揭示如何使用zetcd，zetcd工作原理以及性能基准。
zetcd入门 zetcd运行所需的是一个go编译器，从互联网上获取的源代码，以及一个可以运行etcd的系统。以下例子展示了从获取zetcd源码，一直到如何在zetcd上运行ZooKeeper命令。由于均是基于开发分支构建的etcd和zetcd，所以并不建议在生产环境这样做，这只是一个讲解如何使用的简单示例。
首先，获得etcd和zetcd源码，并编译成二进制代码：
其次，运行etcd，将zetcd连接到etcd客户服务端：
通过增加订阅和创建一个key来试用zetd：
从概念上讲，上述例子即完成在一个单个的etcd实例上增加一层zetcd。
zetcd这层到底是做什么的呢？
etcd3中对ZooKeeper的支持 深入来讲，zetcd会将ZooKeeper的数据模型翻译成适配etcd API。对于key查找，zetcd将ZooKeeper层级式目录转换成etcd扁平的二分键值空间（flat binary keyspace）。为了管理元数据，当写入etcd后端时，zetcd利用内存级别的事务将信息安全、原子地更新为ZooKeeper znode信息。
ZooKeeper以目录方式列出key（getChildren），而etcd则是通过间隔（Range）方式。下图讲解了zetcd如何对etcd下的key进行编码从而有效地支持以目录形式列出。所有在etcd中的zetcd key都有一个包括全目录名的前缀（例如："/"和“/abc”分别代表深度为0 和1）。要列出一个目录时，zetcd发出一个带前缀的range请求（例如[“/zk/key/002/abc/”, “/zk/key/002/abc0”）来列出满足目录深度和路径的所有/abc/下的key。深度限制只针对目录本身；如果zetcd只使用路径而不使用深度，那么etcd将返回这个目录下的所有key，zetcd则会丢弃该结果，反之则只返回本目录下的key。
每个ZooKeeper key在ZNode里都带有一些元数据，即key的调整，版本和权限等。尽管etcd也有每个key的元数据，却比ZNode要简单很多，例如因为没有目录也就没有子版本，因为etcd使用的是基于角色认证的机制因此也就没有ACL，因为实际的时钟超出范畴所以没有时间戳。这些额外的元数据会被映射为对应的key，用来描述一个完整的ZNode。修改元数据时，zetcd利用内存级别的软事务来自动更新key的子集，确保ZNodes不需要昂贵的加锁机制就可以保持一致。
此外，zetcd可以和一台授权的ZooKeeper服务器做动态校验。为了做比较，zetcd可以同时连到etcd和外部ZooKeeper服务器。当客户端发起请求给该模式下的zetcd时，请求会被同时转发到zetcd和ZooKeeper服务端。如果两个服务器响应的数据不一致，zetcd会给此响应标识一个警告。
性能基准 由于数据的转换以及额外的网络开销，也许很容易觉得这样的模拟不切实际。尽管对于ZooKeeper或者etcd集群来说，zetcd有额外的花销，但是它仍然有一个优势，即某些etcd应用安装完毕后仍然需要ZooKeeper来协调的场景。例如，早期用户报告称在zetcd里通过etcd的TLS加密流量比一个类似的经典ZooKeeper配置更简单。在这些场景中，支持同一种ZooKeeper协议所带来的简单可靠性比性能更重要一些。
跟etcd性能工具的接口及报告形式类似，zetcd命令行工具zkboom可以用来判断一个zetcd的性能基准是否满足要求。其它ZooKeeper性能工具应该也可以用在zetcd；zkboom为用户提供了便利，我们不妨试试用它来做下创建key的测试：
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管理。如想了解更多，请参阅https://github.com/coreos/zetcd/。
【ZooKeeper】④ ZooKeeper 实际应用（服务器的动态感知） 使用 ZooKeeper 实现服务器的动态感知，动态获取应用服务（秒杀服务）的上线、宕机情况，并能够让客户端（如 Java 客户端）知道。 ① 每个集群服务器的秒杀服务都需要连接 ZooKeeper 客户端。当上线秒杀服务的时候，往 ZooKeeper 的指定目录创建临时顺序节点，并写入当前秒杀服务器的信息（ip 地址、端口等） 为什么是【临时顺序节点】？ 临时节点的特点：当会话断开的时候，临时节点会自动被移除（可实现服务器宕机的时候自动移除服务器在 ZooKeeper 注册中心的信息） 顺序节点的特点：顺序节点的节点名字可以一样，ZooKeeper 会自动在节点的名字后面加上顺序号
全托管：MSE+SAE 微服务应用全托管解决方案 进入新世纪互联网时代后，以腾讯和阿里为代表的社交电商巨头开始面临流量和复杂度大增的挑战。此时的研发团队相较于之前已经明显扩大，并开始实践 SOA /微服务架构，比如阿里的 HSF。
分布式系统通常都依赖一个仲裁系统协同工作，一般这样的系统通过仲裁来保证信息的准确传达，以避免出现脑裂。这类系统通过牺牲通用性换来了充分的设计余地，这种做法显然已经被不断扩散的各种具体实现所例证。这样的系统有很多，例如：chubby，ZooKeeper，etcd和consul等。尽管这些系统的理念和协议不同，但是提供的都是类似的基于key-value的分布式仲裁。作为将etcd打造成分布式系统最受瞩目的基础组件计划的一部分，etcd团队开发了一款全新的代理，zetcd，无需变动就可以让etcd集群消费ZooKeeper的服务请求。
ZooKeeper是第一个开源实现的仲裁软件，这促使它成为众多分布式系统偏好的后端。理论上来说这些系统应该可以跟etcd兼容，但由于历史原因，事实并非如此；etcd集群无法替代ZooKeeper，其数据模型和客户端协议跟ZooKeeper应用不兼容；反之亦然。倘若该系统已经投产，那么几乎没什么动力可以推动它接入新的后端，引入新的复杂度。幸运的是，etcd v3 API正准备通过一个标准代理zetcd实现对ZooKeeper数据模型的模拟支持，zetcd是一个由etcd团队开发的全新开源项目，今天发布了zetcd第一个beta版本，v0.0.1，目标是在生产系统中管理和部署zetcd系统。
zetcd 代理部署在etcd集群前面，服务于一个模拟的ZooKeeper客户端端口，使得ZooKeeper应用可以在上层原生调用etcd。总体上来说，zetcd接受ZooKeeper的客户请求，转化成etcd的数据模型和API，将请求转发到etcd，然后将返回信息以客户端可以理解的方式转发回去。zetcd的性能跟ZooKeeper不相上下，并且简化了ZooKeeper集群与etcd之间的管理和操作复杂性。本文将揭示如何使用zetcd，zetcd工作原理以及性能基准。
zetcd入门 zetcd运行所需的是一个go编译器，从互联网上获取的源代码，以及一个可以运行etcd的系统。以下例子展示了从获取zetcd源码，一直到如何在zetcd上运行ZooKeeper命令。由于均是基于开发分支构建的etcd和zetcd，所以并不建议在生产环境这样做，这只是一个讲解如何使用的简单示例。
首先，获得etcd和zetcd源码，并编译成二进制代码：
go get github.com/coreos/etcd/cmd/etcd go get github.com/coreos/zetcd/cmd/zetcd
其次，运行etcd，将zetcd连接到etcd客户服务端：
#etcd uses localhost:2379 by default etcd zetcd -zkaddr localhost:2181 -endpoints localhost:2379
通过增加订阅和创建一个key来试用zetd：
go install github.com/coreos/zetcd/cmd/zkctl zkctl watch / zkctl create /abc "foo"
从概念上讲，上述例子即完成在一个单个的etcd实例上增加一层zetcd。
zetcd这层到底是做什么的呢？
etcd3中对ZooKeeper的支持 深入来讲，zetcd会将ZooKeeper的数据模型翻译成适配etcd API。对于key查找，zetcd将ZooKeeper层级式目录转换成etcd扁平的二分键值空间（flat binary keyspace）。为了管理元数据，当写入etcd后端时，zetcd利用内存级别的事务将信息安全、原子地更新为ZooKeeper znode信息。
ZooKeeper以目录方式列出key（getChildren），而etcd则是通过间隔（Range）方式。下图讲解了zetcd如何对etcd下的key进行编码从而有效地支持以目录形式列出。所有在etcd中的zetcd key都有一个包括全目录名的前缀（例如："/"和“/abc”分别代表深度为0 和1）。要列出一个目录时，zetcd发出一个带前缀的range请求（例如[“/zk/key/002/abc/”, “/zk/key/002/abc0”）来列出满足目录深度和路径的所有/abc/下的key。深度限制只针对目录本身；如果zetcd只使用路径而不使用深度，那么etcd将返回这个目录下的所有key，zetcd则会丢弃该结果，反之则只返回本目录下的key。
每个ZooKeeper key在ZNode里都带有一些元数据，即key的调整，版本和权限等。尽管etcd也有每个key的元数据，却比ZNode要简单很多，例如因为没有目录也就没有子版本，因为etcd使用的是基于角色认证的机制因此也就没有ACL，因为实际的时钟超出范畴所以没有时间戳。这些额外的元数据会被映射为对应的key，用来描述一个完整的ZNode。修改元数据时，zetcd利用内存级别的软事务来自动更新key的子集，确保ZNodes不需要昂贵的加锁机制就可以保持一致。
此外，zetcd可以和一台授权的ZooKeeper服务器做动态校验。为了做比较，zetcd可以同时连到etcd和外部ZooKeeper服务器。当客户端发起请求给该模式下的zetcd时，请求会被同时转发到zetcd和ZooKeeper服务端。如果两个服务器响应的数据不一致，zetcd会给此响应标识一个警告。
性能基准 由于数据的转换以及额外的网络开销，也许很容易觉得这样的模拟不切实际。尽管对于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管理。如想了解更多，请参阅https://github.com/coreos/zetcd/。
原文链接：zetcd: running ZooKeeper apps without ZooKeeper（翻译：杨峰 审校：吴佳兴）
原文发布时间为：2017-05-22
本文作者：杨峰
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：zetcd：让应用解除对ZooKeeper的依赖
【ZooKeeper】④ ZooKeeper 实际应用（服务器的动态感知） 使用 ZooKeeper 实现服务器的动态感知，动态获取应用服务（秒杀服务）的上线、宕机情况，并能够让客户端（如 Java 客户端）知道。 ① 每个集群服务器的秒杀服务都需要连接 ZooKeeper 客户端。当上线秒杀服务的时候，往 ZooKeeper 的指定目录创建临时顺序节点，并写入当前秒杀服务器的信息（ip 地址、端口等） 为什么是【临时顺序节点】？ 临时节点的特点：当会话断开的时候，临时节点会自动被移除（可实现服务器宕机的时候自动移除服务器在 ZooKeeper 注册中心的信息） 顺序节点的特点：顺序节点的节点名字可以一样，ZooKeeper 会自动在节点的名字后面加上顺序号
全托管：MSE+SAE 微服务应用全托管解决方案 进入新世纪互联网时代后，以腾讯和阿里为代表的社交电商巨头开始面临流量和复杂度大增的挑战。此时的研发团队相较于之前已经明显扩大，并开始实践 SOA /微服务架构，比如阿里的 HSF。
相关文章
- 架构设计：一种远程调用服务的设计构思（zookeeper的一种应用实践）
- 14. 监视ZooKeeper实例
- ZooKeeper 到底解决了什么问题？
- ZooKeeper实现分布式的思路
- zookeeper+kafka集群安装之二
- Zookeeper学习之Zab一致性协议
- Zookeeper从入门到放弃之Zookeeper典型应用场景
- Zookeeper和Kafka on k8s 部署
- 服务端相关知识学习（四）之Zookeeper启动过程
- Zookeeper ZAB 协议分析
- 【Zookeeper】源码分析之服务器（四）之FollowerZooKeeperServer
- 【分布式】Zookeeper在大型分布式系统中的应用
- Zookeeper系列五：Master选举、ZK高级特性：基本模型
- Zookeeper集群部署与配置（三）
- Zookeeper完全分布式集群的搭建
- Dubbo及Zookeeper安装
- zookeeper分布式锁实现
- Zookeeper API for JAVA实战与应用