zetcd：让应用解除对ZooKeeper的依赖

分布式实验室 · 公众号 · 后端 · 2017-05-27 07:45

正文

分布式系统通常都依赖一个仲裁系统协同工作，一般这样的系统通过仲裁来保证信息的准确传达，以避免出现脑裂。这类系统通过牺牲通用性换来了充分的设计余地，这种做法显然已经被不断扩散的各种具体实现所例证。这样的系统有很多，例如：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。

etcd这层到底是做什么的呢？

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的依赖

正文

请到「今天看啥」查看全文