服务发现场景下zookeeper vs etcd

Posted 2021-04-13 奔跑中的蜗牛

在服务发现领域，一直以来zookeeper都是不二的选择，近两年，由于zookeeper发展速度的缓慢，docker的崛起引爆了etcd这个服务发现组件，下面就这两个组件做一下分析。

etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于 ZooKeeper 和 Doozer，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。

ZooKeeper，Apache ZooKeeper是Apache软件基金会的一个软件项目，他为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。 ZooKeeper曾经是Hadoop的一个子项目，但现在是一个独立的顶级项目。 ZooKeeper的架构通过冗余服务实现高可用性。

zookeeper真的是高可用吗？

No，zookeeper实际上是一个cp的系统，通过paxos（zab）来保证一致性，也就是参议员投票机制，假设在3个data center分别部署了3个zk节点（为了容灾），发生网络分区的时候，也就是其中一个节点和其他两个断网了，已经连接到这个节点的应用将无法向这个节点读写数据，作为一个分布协调系统，做到这点是必须的。实际上在客户端缓存数据是一个折中的办法，大多服务化框架也是这么做的，但是对于服务发现情况下，正在启动的服务，就非常不幸了。而这种场景并不少见，特别是当某个data center大面积故障时。

而etcd虽然是不可写的，但是可以读取数据。在服务发现这种场景下，能读取到不一致的数据要好于什么都读不到。

Zookeeper的故障恢复时间是惊人的

一旦网络发生抖动，触发选主流程，意味着整个集群是不可用状态，而选主的时间通常在30-120s之间，在这段时间，应用会不断的报出异常（CONNECTIONLOSS(连接断开) 和SESSIONEXPIRED(Session 过期)），如果你自己分析生产环境上的日志，就会发现这个问题。

而etcd依赖raft算法，选主流程要快的多。Raft竞选过程中，如果发生票数相同的情况，竞选节点（candidate）time out时间采用随机值，有效降低了冲突的概率。

Etcd并不是强一致的

假设有5个节点，发生网络分区后，其中leader节点被分到了少数区域，此时多数节点又选出了一个新的leader，这种情况下，存在两个leader，新的 leader 在下一次heartbeat timeout 时向所有的节点发送一次 heartbeat， leader 在收到步进数更高的leader heartbeat 时放弃 leader 地位并切换到 follower 状态。值得注意的是，步进数落后的leader将丢弃前面的数据，和leader保持一致。

即使使用zookeeper，要保证强一致性也要费一番力气，你无法保证服务端的所有变化都能不遗漏的通知到每个客户端（zookeeper并不是直接把变化的数据发送到客户端，而是发送变化时，让客户端来服务端取数据。重要的是你不能永久性的watch节点变化，只能重复注册，在收到变化，重新注册之前，这个时间段变化的数据，你是会永久性的错过的）。

节点数变更

无论是zookeeper还是etcd，减少节点数并不复杂。如果要增加节点，zookeeper在3.5以上版本支持动态扩容，etcd比较容易。

易用性

Etcd做的不错，提供了http+json和客户端两种选择。需要注意的是，如果使用http+json，需要自己实现一系列功能。看客户端的代码你就知道了。

容灾

实际上对两个系统来说都能做到，只是需要适当调大超时时间和心跳间隔，etcd的官方建议可以看这里https://coreos.com/etcd/docs/latest/tuning.html，不过对于zookeeper来说，由于上文中提到的一些观点，可用性、性能受到挑战，很多公司采用在单个区域形成集群，跨区域增加oberserver的方式来提升读性能。例如北京地区三机房，部署一套集群，在杭州增加oberserver的方式，优先访问本地节点。这样的话，需要在客户端设置优先策略，否则客户端访问server list是采用随机后轮训的机制。

总结

再回到服务发现这个应用场景，在此场景下，etcd是一个不错的选择，理由可以参加上文。另一个理由是apache的项目更新速度太慢，很多问题长时间不解决。导致很多用户自行修改源码，或者直接放弃。要知道，在很多公司，凭几个技术人员的几句话，完全可以放弃一个存在个别问题的成熟的开源项目，转为自己开发。也正是因为etcd的更新速度比较快，架构和接口容易变更，会有一定的成本。需要注意的是etcd还不算特别成熟，应用范围并不算广，目前知道的是CoreOS、Kubernetes和CloudFoundry等知名项目均在生产环境中使用了etcd。而zookeeper无疑在很多公司和大型的项目中被大规模使用。但是etcd还是非常值得期待的。

附etcd2.1.0官方benchmarks

1.1 Performance

1.1.1reading one single key

key size in bytes	number of clients	target etcd server	read QPS	90th Percentile Latency (ms)
64	1	leader only	1534	0.7
64	64	leader only	10125	9.1
64	256	leader only	13892	27.1
256	1	leader only	1530	0.8
256	64	leader only	10106	10.1
256	256	leader only	14667	27.0
64	64	all servers	24200	3.9
64	256	all servers	33300	11.8
256	64	all servers	24800	3.9
256	256	all servers	33000	11.5

1.1.2writing one single key

key size in bytes	number of clients	target etcd server	write QPS	90th Percentile Latency (ms)
64	1	leader only	60	21.4
64	64	leader only	1742	46.8
64	256	leader only	3982	90.5
256	1	leader only	58	20.3
256	64	leader only	1770	47.8
256	256	leader only	4157	105.3
64	64	all servers	1028	123.4
64	256	all servers	3260	123.8
256	64	all servers	1033	121.5
256	256	all servers	3061	119.3