内容简介：zetcd：让应用解脱对ZooKeeper的依赖
分布式系统一般都需要一个仲裁系统，一般系统都自己提供这样的仲裁以免出现脑裂。这样的系统有很多，例如： chubby ， ZooKeeper ， etcd 和 consul 等。尽管这些系统的术语和协议不同，但是都提供基于key-value方式的分布式仲裁。最近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源码，并编译成二进制代码：
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 &
用watching启动zetcd，创建一个key：
go install github.com/coreos/zetcd/cmd/zkctl zkctl watch / & zkctl create /abc "foo"
那么zetcd这层到底是做什么的呢？
etcd3中对ZooKeeper的支持
如上图中，zetcd将ZooKeeper数据模型翻译成适合etcd API的。对于key查询，zetcd将ZooKeeper层级式目录转换成etcd的flat binary keyspace。对于metadata管理，当写入etcd后端时，zetcd利用交易内存将信息安全完整地更新为ZooKeeper znode信息。
ZooKeeper以目录方式列出keys（getChildren），而etcd则通过interval（Range）方式。下图列出zetcd如何对etcd下的keys进行打包来有效支持目录列表。所有在etcd中的zetcd keys都有一个包括全目录名的前缀（例如："/"和“/abc”分别代表深度为0 和1）。当有类目录需求时，zetcd发出一个带前缀的range请求（例如[“/zk/key/002/abc/”, “/zk/key/002/abc0”）来列出满足目录深度和路径的所有/abc/下的keys。深度限制只针对目录本身；如果zetcd只使用路径而不使用深度，那么这个目录下所有keys都将返回，反之只返回本目录下的keys。
每个ZooKeeper key都包含有在ZNode中保存的修改，版本和权限等metadata。尽管etcd也有每个key的metadata，却比ZNode中的要简单很多，例如因为没有目录因此没有子版本，因为etcd使用基于角色认证机制因此没有ACLs，因为超出实时时钟范围因此没有时间戳。这些额外metadata映像为一批keys，描述一个完整的ZNode。为了调整metadata，zetcd使用软件交易内存更新keys，保证ZNodes不需要昂贵的加锁机制就可以保持一致。
另外，zetcd可以动态地与ZooKeeper服务器做校验。zetcd同时连接到etcd和外部ZooKeeper服务器。当客户端发起请求，请求会被同时转发到zetcd和ZooKeeper服务端。如果两个服务器响应不同，zetcd会给此响应标识一个警告。
性能基准
从以上原理上看因为有数据转换以及额外的网络开销，很容易想见这些操作效率不高。尽管相对于ZooKeeper或者etcd集群来说，zetcd有额外的花销，但是它仍然有一个优势在于某些etcd应用安装完毕后仍然需要ZooKeeper来协调。例如，早期用户报告称zetcd重加密etcd TLS的流量比加密经典ZooKeeper配置要简单。在这些场景中，说同一种ZooKeeper语言的可靠性相对于性能来说更重要一些。
使用zetcd命令行工具 zkboom 可以用来判断性能基准，接口和报告跟etcd性能 工具 类似。其它ZooKeeper性能工具也能跟zetcd协同工作；zkboom提供方便性，可以做如下测试：
go get github.com/coreos/zetcd/cmd/zkboom zkboom --conns=50 --total=10000 --endpoints=localhost:2181 create
zetcd为小负载提供足够的性能保障。两节点配置性能延迟证实zetcd对大量请求是可以接受的。具体配置是两台 Linux 服务器通过一个千兆交换机互联，其中一台设备在RAID磁盘配置上运行代理和和服务端，另外一台设备用于产生客户请求。zkbook通过，创建一个空keystore，并从中读取128Kbytes键值对来进行测量。用户请求被限制在每秒2500个请求，逐渐增加并发客户端数量。ZooKeeper 3.4.10和etcd结果如下比较所示：
下图表明zetcd并行客户端数量与平均key创建延迟之间关系。因为etcd在延迟上比zookeeper要有5-35ms的优势，zetcd有足够的空间吸纳由于额外负载造成的延迟。zetcd代理比起ZooKeeper有20ms左右的劣势，但是从处理2500请求的吞吐量数据来看，并不弱。一种对zetcd写比较慢的解释是，与读不一样，对每个ZooKeeper key写时因为有额外的数据模型不同，所以需要写多次。
未来
尽管zetcd承诺以上结果，性能数据是合理的，在可接受延迟情况下，可以支撑每秒上千个操作。以上模拟对Mesos，Kafka和Drill替代ZooKeeper提供了足够好的解决方案，但是对于zetcd来说仍然后足够的空间提高性能期望。同样的，需要更多基于ZooKeeper应用采用zetcd做替代性测试。
zetcd从去年十月开始在开源社区出现，最近刚发布第一个版本：zetcd v0.0.1。尽管是第一个beta发行版，但是已经为未来生产系统提供稳定管理和部署。如果跟etcd配合起来使用，运行zetcd的系统将会一套自驱动的“ZooKeeper”集群，它可以自动后台升级，备份和TLS管理。如想了解更多，请参阅 https://github.com/coreos/zetcd/ 。
原文链接： zetcd: running ZooKeeper apps without ZooKeeper （翻译：杨峰）
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- 浅析依赖倒转、控制反转、IoC 容器、依赖注入。
- Angular 4 依赖注入教程之五 FactoryProvider配置依赖对象
- Gradle构建SpringBoot程序依赖管理之依赖版本自动控制
- Maven学习笔记七【可选的依赖项和依赖项排除】
- 模块化解耦框架RxFluxArchitecture4-依赖库与依赖注入
- 不依赖OS编译器，不依赖库，用汇编/机器码直接编程
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
