服务发现工具比较

服务发现工具的适用场景

场景 说明
服务发现 服务发现就是在一个分布式集群中,如何发现服务端并建立连接。即,发现对应服务的IP和端口,建立连接而已。
消息发布与订阅 在构建一个配置共享中心,数据提供者在这个配置中心发布消息,而消息订阅者则订阅他们关心的主题,一旦主题有消息发布,就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。
负载均衡 分布式系统中,为了保证服务的高可用以及数据的一致性,通常都会把应用节点部署多分,以此达到对等服务,即使其中的某一个服务失效了,也不影响使用。因为每个对等服务节点上都存有完整的服务功能,利用合理的负载均衡策略,访问流量就可以分流到不同的机器上。
分布式通知与协调 这个功能与消息发布和订阅有些相似,但是,也有一定得区别。它们都用到了Watcher机制,通过注册与异步通知机制,实现分布式环境下不同系统或者模块之间的通知与协调,从而对数据变更做到实时处理。不同系统都对同一个目录进行注册,同时设置Watcher观测该目录的变化。只要某个系统更新了目录,其它设置了Watcher的系统就会收到通知,并作出相应处理。
分布式锁 锁服务有两种使用方式,一是保持独占,二是控制时序。
分布式队列 创建一个先进先出的队列,保证顺序。另一种比较有意思的实现是在保证队列达到某个条件时再统一按顺序执行。

常见的服务发现工具对比

指标\服务发现工具 Zookeeper Etcd Consul Eureka
实现语言 Java Go Java
AP or CP CP Mixed CP AP
接口 sdk http http/dns http
并发 6000-7000 1万/秒 - -
一致性算法 Paxos Raft Raft 非强一致性
优点 1.功能强大,不仅仅只是服务发现
2.提供watcher机制能实时获取服务提供者的状态
3.dubbo等框架支持
1.简单易用,不需要集成sdk
2.可配置性强
1.简单易用,不需要集成sdk
2.自带健康检查
3.支持多数据中心
4.提供web管理界面
-
缺点 1.没有健康检查
2.需在服务中集成sdk,复杂度高
3.不支持多数据中心
1.没有健康检查
2.需配合第三方工具一起完成服务发现
3.不支持多数据中心
1.不能实时获取服务信息的变化通知 -
坚持原创技术分享,您的支持将鼓励我继续创作!