服务发现框架选型

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

相比于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机制,实时性稍差一点,需考虑如何尽可能提高实时性,问题不会很大。

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

相关推荐