zetcd入门及应用

　　zetcd是一款架在ZooKeeper与etcd之间的代理程序，它可以将ZooKeeper客户端的请求消息转换成etcd要求的格式，并转发给etcd，然后将响应消息转换后返回给客户端。本文介绍了zetcd的使用方法、工作原理以及性能评测。以下是译文。

　　分布式系统需要依赖分布式一致性来协调工作。通常情况下，提供分布式一致性担保信息的系统会接收到按顺序投递过来的消息，这样就不会产生脑裂冲突（split-brain conflicts，译者注：本来一个大脑的两个半球是互相配合的，但是现在分裂变成了两个独立的大脑，并且都认为对方已死。此时，双方都会去尝试接管集群资源，这样就可能会造成冲突，产生严重的后果）。这类系统的用途是显而易见的。像chubby、ZooKeeper、etcd、consul这些项目，尽管它们的原理和协议各不相同，但它们都侧重于为分布式一致性提供类似的基本键值原语。为了让etcd成为分布式系统中最具吸引力的项目，etcd团队开发了一款新的代理服务器程序：zetcd，使用这款软件，etcd集群无需修改即可处理ZooKeeper客户端的请求。

　　ZooKeeper是这方面第一个流行起来的开源软件，它是很多分布式系统的首选后端软件。这些系统理论上也可以搭配etcd一起运行，但是由于历史原因，实际上根本实现不了。etcd集群不支持ZooKeeper，因为etcd的数据模型和客户端协议与ZooKeeper应用程序不兼容。ZooKeeper应用程序也不是原生的支持etcd；如果系统已经在稳定运行了，那么没有必要去为了适应新的后端软件而让系统更加复杂。幸运的是，etcd的第三版API相当的牛逼，它可以通过一个普通的代理来模拟ZooKeeper客户端的数据模型，这就是zetcd，一个由etcd团队开发的新的开源项目。今天，zetcd发布了第一个测试版，v0.0.1版，这为在生产系统中管理和部署zetcd打下了基础。

　　zetcd代理位于etcd集群的前端，它提供了一个模拟ZooKeeper客户端的端口，让原版的ZooKeeper应用程序可以运行在etcd上。其基本原理是，zetcd将ZooKeeper客户端的请求转换为适合于etcd数据模型和API要求的消息，将发送给etcd，然后将etcd的响应消息转换后返回给客户端。该代理的性能可以与ZooKeeper相媲美，利用etcd的特性和工具可以简化ZooKeeper集群管理。下文将展示zetcd的使用方法和工作原理，并分享一些性能评测数据。

　　zetcd入门

　　让zetcd运行起来需要三样东西：一个Go编译器、一个能够获取源代码的互联网连接，以及一个可以运行etcd的系统。下面的示例展示了如何用源代码编译生成zetcd，并对它运行ZooKeeper命令。当我们需要部署正式环境的时候，我们并不建议从开发分支来获取源代码并编译etcd和zetcd，但是如果只是试用一下的话，这是最简单的方法。

　　首先，获取源代码并编译etcd和zetcd的二进制文件：

　　接下来，运行etcd，并将zetcd连接到etcd的客户端接入点：

　　试用zetcd，启动查看并创建一个key：

　　这个例子展示了在一个独立的etcd实例上部署了一个zetcd代理层：

　　一个简单的zetcd服务器拓扑

　　那么这个zetcd代理层是做什么的呢？

　　ZooKeeper接入etcd3

　　在底层，zetcd将ZooKeeper的数据模型转换为适合的etcd API的数据。对于key的查找，zetcd将ZooKeeper的分级目录转换为etcd的普通二进制keyspace。对于元数据的管理，zetcd利用事务内存安全地和原子地将ZooKeeper znode信息更新到etcd后端。

　　ZooKeeper是按目录列出所有的key（getChildren），而etcd是按区间（Range）列出所有的key。下图说明了zetcd是如何在etcd中对key进行编码以便可以快速地列出目录中的key。所有zetcd的key都有一个包括目录深度的前缀（例如，“/”和“/abc/”分别具有0和1的深度）。要列出一个目录，zetcd会给出前缀范围，这个前缀以目录的深度和路径来匹配相应的key（例如，前缀范围［“/zk/key/002/abc/”，“/zk/key/002/abc0”］用于列出/abc/）。这里的目录深度是为了限制目录本身被当作key。如果zetcd将路径当作是没有深度的前缀，那么目录下的所有key，而不是只有其直接子节点，会由etcd返回并被代理抛弃。