[大数据] 常见服务注册中心

名称	优点	缺点	接入	算法
zookeeper	1.功能强大，不仅仅只是服务发现。2.提供watcher机制能实时获取服务提供者的状态。3.dubbo等框架支持	1.没有健康检查2.需在服务中集成sdk，复杂度高3.不支持多数据中心。	sdk	Paxos
consul	1.简单易用，不需要集成sdk。2.自带健康检查。3.支持多数据中心。4.提供web管理界面	1.不能实时获取服务信息的变化通知。	http/dns	Raft
etcd	1.简单易用，不需要集成sdk。2.可配置性强。	1.没有健康检查。2.需配合第三方工具一起完成服务发现。3.不支持多数据中心。	http	Raft

Etcd：是一个采用http协议的分布式键值对存储系统。如果想要提供完整的服务发现功能，必须搭配一些第三方的工具。比如 etcd、Registrator、confd组合，但这就稍微麻烦点了，尤其相对consul来说。所以etcd大部分场景都是被用来做kv存储，比如kubernetes。
Consul：相较于etcd、zookeeper，consul ：它整合了服务发现普遍的需求，开箱即用，不需要任何第三方的工具。代码实现上也足够简单。
- 通过DNS或HTTP，应用能轻易地找到它们依赖的系统。
- 提供了多种健康检查方式：http返回码200，内存是否超限，tcp连接是否成功。
- kv存储，并提供http api
- 多数据中心，这点是zookeeper所不具备的。
- 不需要专门的sdk集成到服务中，不限制语言。

每台服务器上都要安装一个consul agent。
consul agent支持通过配置文件注册服务，或者在服务中通过http接口来注册服务。
注册服务后，consul agent通过指定的健康检查方式，定期检查服务是否存活。
如果服务想查询其他服务的存活状态，只需要与本机的consul agent发起一次http请求或者dns请求即可。
简单点说，consul的使用不依赖任何sdk，依靠简单的http请求就能满足服务发现的所有逻辑。
不过，服务每次都从consul agent获取其他服务的存活状态，相比于zookeeper的watcher机制，实时性稍差一点，需考虑如何尽可能提高实时性，问题不会很大。
watch：https://juejin.cn/post/6984378158347157512

为了以后支持多数据中心，同时为了快速支持不同的语言比如nodejs、python服务，我会选择consul作为我们的服务发现框架，但是实时获取服务信息变化通知的问题需尽可能减小。