type
status
date
slug
summary
tags
category
icon
password
标签
这里就平时经常用到的服务发现的产品进行下特性的对比，首先看下结论:
Feature | Consul | zookeeper | etcd | euerka |
服务健康检查 | 服务状态，内存，硬盘等 | (弱)长连接，keepalive | 连接心跳 | 可配支持 |
多数据中心 | 支持 | — | — | — |
kv存储服务 | 支持 | 支持 | 支持 | — |
一致性 | raft | paxos | raft | — |
cap | ca | cp | cp | ap |
使用接口(多语言能力) | 支持http和dns | 客户端 | http/grpc | http（sidecar） |
watch支持 | 全量/支持long polling | 支持 | 支持 long polling | 支持 long polling/大部分增量 |
自身监控 | metrics | — | metrics | metrics |
安全 | acl/https | acl | https支持（弱） | — |
spring cloud集成 | 已支持 | 已支持 | 已支持 | 已支持 |
- 服务的健康检查
Euraka使用时需要显式配置健康检查支持；ZookeeperEtcd则在失去了和服务进程的连接情况下任务不健康，而Consul相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。
- 多数据中心支持
Consul通过WAN的Gossip协议，完成跨数据中心的同步；而且其他的产品则需要额外的开发工作来实现；
- KV 存储服务
除了
Eureka,其他几款都能够对外支持 k-v 的存储服务，所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务，也能够较好的转化为动态配置服务哦。
- 产品设计中 CAP 理论的取舍
Eureka典型的 AP,作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。其次 CA 类型的场景Consul,也能提供较高的可用性，并能k-vstore服务保证一致性。 而ZookeeperEtcd则是CP类型 牺牲可用性，在服务发现场景并没太大优势；
- 多语言能力与对外提供服务的接入协议
Zookeeper的跨语言支持较弱，其他几款支持http提供接入的可能。Euraka一般通过sidecar的方式提供多语言客户端的接入支持。Etcd还提供了Grpc的支持。Consul除了标准的Rest服务api,还提供了DNS的支持。
- Watch的支持（客户端观察到服务提供者变化）
Zookeeper支持服务器端推送变化，Eureka 2.0(正在开发中)也计划支持。Eureka 1ConsulEtcd则都通过长轮询的方式来实现变化的感知；
- 自身集群的监控
除了
Zookeeper,其他几款都默认支持metrics，运维者可以搜集并报警这些度量信息达到监控目的；
- 安全
ConsulZookeeper支持ACL，另外ConsulEtcd支持安全通道https.
- SpringCloud的集成
目前都有相对应的
boot starter，提供了集成能力。
总的来看，目前
Consul 自身功能，和 SpringCloud 对其集成的支持都相对较为完善，而且运维的复杂度较为简单（没有详细列出讨论），Eureka 设计上比较符合场景，但还需持续的完善。转载 : Luyi's Blog