Eureka Consul zookeeper等常用注册中心对比

最大的区别是Eureka保证AP, Consul为CP。

Consul强一致性(C)带来的是:

服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
Leader挂掉时,重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
Eureka保证高可用(A)和最终一致性:

服务注册相对要快,因为不需要等注册信息replicate到其他节点,也不保证注册信息是否replicate成功
当数据出现不一致时,虽然A, B上的注册信息不完全相同,但每个Eureka节点依然能够正常对外提供服务,这会出现查询服务信息时如果请求A查不到,但请求B就能查到。如此保证了可用性但牺牲了一致性。
其他方面,eureka就是个servlet程序,跑在servlet容器中; Consul则是go编写而成。

这里就平时经常用到的服务发现的产品进行下特性的对比,首先看下结论:

FeatureConsulzookeeperetcdeuerka
服务健康检查服务状态,内存,硬盘等(弱)长连接,keepalive连接心跳可配支持
多数据中心支持
kv存储服务支持支持支持
一致性raftpaxosraft
capcpcpcpap
使用接口(多语言能力)支持http和dns客户端http/grpchttp(sidecar)
watch支持全量/支持long polling支持支持 long polling支持 long polling/大部分增量
自身监控metricsmetricsmetrics
安全acl /httpsaclhttps支持(弱)
spring cloud集成已支持已支持已支持已支持
  • 服务的健康检查

Euraka 使用时需要显式配置健康检查支持;Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康,而 Consul 相对更为详细点,比如内存是否已使用了90%,文件系统的空间是不是快不足了。

  • 多数据中心支持

Consul 通过 WAN 的 Gossip 协议,完成跨数据中心的同步;而且其他的产品则需要额外的开发工作来实现;

  • KV 存储服务

除了 Eureka ,其他几款都能够对外支持 k-v 的存储服务,所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务,也能够较好的转化为动态配置服务哦。

  • 产品设计中 CAP 理论的取舍

Eureka 典型的 AP,作为分布式场景下的服务发现的产品较为合适,服务发现场景的可用性优先级较高,一致性并不是特别致命。

(以下为更正原文部分)

熟悉CAP理论的人都应该清楚,CA架构是比较难保证的,因为现在系统很难避免网络分区(P)的情况出现。

虽然CAP理论三者之间没有绝对的界限,但是Consul的设计更偏重CP架构,保证一致性的前提下,尽量保证可用性。

而Zookeeper,Etcd则是CP类型 牺牲可用性,在服务发现场景并没太大优势;

  • 多语言能力与对外提供服务的接入协议

Zookeeper的跨语言支持较弱,其他几款支持 http11 提供接入的可能。Euraka 一般通过 sidecar的方式提供多语言客户端的接入支持。Etcd 还提供了Grpc的支持。 Consul除了标准的Rest服务api,还提供了DNS的支持。

  • Watch的支持(客户端观察到服务提供者变化)

Zookeeper 支持服务器端推送变化,Eureka 2.0(正在开发中)也计划支持。 Eureka 1,Consul,Etcd则都通过长轮询的方式来实现变化的感知;

  • 自身集群的监控

除了 Zookeeper ,其他几款都默认支持 metrics,运维者可以搜集并报警这些度量信息达到监控目的;

  • 安全

Consul,Zookeeper 支持ACL,另外 Consul,Etcd 支持安全通道https.

  • Spring Cloud的集成

目前都有相对应的 boot starter,提供了集成能力。

总的来看,目前Consul 自身功能,和 spring cloud 对其集成的支持都相对较为完善,而且运维的复杂度较为简单(没有详细列出讨论),Eureka 设计上比较符合场景,但还需持续的完善。

转自:https://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/

关于consul是ca还是cp:http://www.manongjc.com/article/34358.html

consul官方对比说明:https://www.consul.io/intro/vs/serf.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值