服务发现框架选型，Consul还是Zookeeper还是etcd

zookeeper

官网这么介绍zookeeper的，翻译过来，zookeeper的功能有：

• 作为配置信息的存储的中心服务器
• 命名服务
• 分布式同步
• 分组服务

能看出，zookeeper并不只是作为服务发现框架使用的，它非常庞大。
如果只是打算将zookeeper作为服务发现工具，就需要用到其配置存储和分布式同步的功能。前者可以理解成具有一致性的kv存储，后者提供了zookeeper特有的watcher注册于异步通知机制，zookeeper能将节点的状态实时异步通知给zookeeper客户端。

zookeeper的使用流程如下：

1. 确保有所选语言的sdk，理论上github上第三方的库有一些，仔细筛选一下应该可以用。
2. 调用zookeeper接口连接zookeeper服务器。
3. 注册自身服务
4. 通过watcher获取监听服务的状态
5. 服务提供者需自行保持与zookeeper服务器的心跳。

总得来说，zookeeper需要胖客户端，每个客户端都需要通过其sdk与zookeeper服务保活，增加了编写程序的复杂性。此外，还提供api实现服务注册与发现逻辑，需要服务的消费者实现服务提供者存活的检测。

etcd

etcd是一个采用http协议的分布式键值对存储系统，因其易用，简单。很多系统都采用或支持etcd作为服务发现的一部分，比如kubernetes。但正事因为其只是一个存储系统，如果想要提供完整的服务发现功能，必须搭配一些第三方的工具。

比如配合etcd、Registrator、confd组合，就能搭建一个非常简单而强大的服务发现框架。但这种搭建操作就稍微麻烦了点，尤其是相对consul来说。所以etcd大部分场景都是被用来做kv存储，比如kubernetes。

consul

相较于etcd、zookeeper，consul最大的特点就是：它整合了用户服务发现普遍的需求，开箱即用，降低了使用的门槛，并不需要任何第三方的工具。代码实现上也足够简单。

consul的功能有：

• 通过DNS或HTTP，应用能轻易地找到它们依赖的系统
• 提供了多种健康检查方式：http返回码200，内存是否超限，tcp连接是否成功
• kv存储，并提供http api
• 多数据中心，这点是zookeeper所不具备的。

consul使用

相比于zookeeper的服务发现使用，consul并不需要专门的sdk集成到服务中，因此它不限制任何语言的使用。我们看看consul一般是怎么使用的。

1. 每台服务器上都要安装一个consul agent。
2. consul agent支持通过配置文件注册服务，或者在服务中通过http接口来注册服务。
3. 注册服务后，consul agent通过指定的健康检查方式，定期检查服务是否存活。
4. 如果服务想查询其他服务的存活状态，只需要与本机的consul agent发起一次http请求或者dns请求即可。

简单点说，consul的使用不依赖任何sdk，依靠简单的http请求就能满足服务发现的所有逻辑。

不过，服务每次都从consul agent获取其他服务的存活状态，相比于zookeeper的watcher机制，实时性稍差一点，需考虑如何尽可能提高实时性，问题不会很大。

总结

raft一致性算法原理的动画演示：http://thesecretlivesofdata.com/raft/

原文：https://www.servercoder.com/2018/03/30/consul-vs-zookeeper-etcd/