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

首先,获得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的支持

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.

此外,zetcd可以和一台授权的ZooKeeper服务器做动态校验.为了做比较,zetcd可以同时连到etcd和外部ZooKeeper服务器.当客户端发起请求给该模式下的zetcd时,请求会被同时转发到zetcd和ZooKeeper服务端.如果两个服务器响应的数据不一致,zetcd会给此响应标识一个警告.

性能基准

跟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客户端并发数与创建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从去年十月开始在开源社区发行,最近刚发布第一个版本：zetcd v0.0.1.尽管是第一个beta发行版,但是已经为未来生产系统提供稳定管理和部署.如果跟etcd配合起来使用,运行zetcd的系统将会一套自驱动的“ZooKeeper”集群,它可以自动后台升级,备份和TLS管理.如想了解更多,请参阅 https://github.com/coreos/zetcd/.

深入浅出学习etcd

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

文章来自微信公众号：Docker