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

发布时间：2020-12-15 05:06:15 所属栏目：安全来源：网络整理

导读：《zetcd：让应用解除对ZooKeeper的依赖》要点：本文介绍了zetcd：让应用解除对ZooKeeper的依赖，希望对您有用。如果有疑问，可以联系我们。分布式系统通常都依赖一个仲裁系统协同工作,一般这样的系统通过仲裁来保证信息的准确传达,以避免出现脑裂.这类系统

《zetcd：让应用解除对ZooKeeper的依赖》要点：
本文介绍了zetcd：让应用解除对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源码,并编译成二进制代码：

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.

zetd

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.

etcd

每个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/.

深入浅出学习etcd

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

文章来自微信公众号：Docker

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!