服务注册发现技术对比

技术对照表

	Zookeeper	Etcd	Consul	Eureka
CAP模型	CP	CP	CP	AP
数据一致性算法	ZAB	Raft	Raft	❌
多数据中心	❌	❌	✅	❌
多语言支持	客户端	Http/gRPC	Http/DNS	Http
Watch	TCP	Long Polling	Long Polling	Long Polling
KV存储	✅	✅	✅	❌
服务健康检查	心跳	心跳	服务状态， 内存，硬盘等	自定义
自身监控	❌	metrics	metrics	metrics
SpringCloud 支持	✅	✅	✅	✅
自身开发语言	Java	Go	Go	Java

CAP模型

CAP 这3个字母代表：

• Consistence（一致性）
• Availability（可用性）
• Partition Tolerance（分区容错性）

在一个分布式系统中，这3者不可兼得。

由于网络的原因，分布式系统中 P 是必备的，意味着只能选择 AP 或者 CP。

CP 代表数据一致性是第一位的，AP 代表可用性是第一位的。

他们4个只有 Eureka 是 AP 的，Eureka 在数据不一致的情况下也可以使用，只要数据最终一致即可。

如果想更多的了解 CAP 可以参见：

架构设计中的 CAP 和 BASE 理论

数据一致性

ZAB 是 zookeeper 的原子广播协议，基于 Paxos 算法改的。

Raft 是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。

这两个算法都没毛病，都可以实现分布式一致性，只是实现方式不同。

Eureka 选择的是 AP，不要求强一致性，自然没有使用数据一致性算法。

Paxos 和 Raft 参考资料：

分布式一致性算法 Paxos

分布式一致性算法 Raft

多数据中心

就是多机房，只有 Consul 支持。

zookeeper 不支持多数据中心是指，如果你跨多个机房部署了一套 zookeeper，一旦出现网络划分，那么就不可用了。

Consul 是通过 Gossip 协议实现的。

Gossip 协议中的消息会以一传十、十传百的指数级速度在网络中快速传播。

网络中任何节点的异常都不会影响 Gossip 消息传播，分布式系统容错性极强。

Gossip 协议是去中心化的，所有节点对等，节点无需知道整个网络状况，只要网络是连通的，任意一个节点就可以把消息散播到全网。

Watch

Zookeeper 的 watch 实现比较简单，就是 TCP Ping。

Long Polling（长轮询）是拉模式，客户端每隔一段时间请求拉取一次数据。

客户端发起 Long Polling，如果服务端没有数据，会等待，直到服务端有数据，或者等待到超时，返回后，客户端会再次发起 Long Polling。

多语言支持

Zookeeper 多语言客户端比较成熟。

Consul 支持 DNS 比较有意思，如果你第一次看到可能不太理解。

DNS 方式允许应用程序使用服务发现，而无需与Consul进行任何高度集成。

例如，不需要向 Consul 发送 HTTP 请求，可以使用 DNS 服务器直接通过名字查找，如 redis.service.us-east-1.consul，就会自动转查找位于 us-east-1 这个数据中心提供 redis 服务的节点。

使用DNS的方式可以在程序中集成一个DNS解析库，也可以自定义本地的DNS Server。

自定义本地 DNS Server 是指将 .consul 域的请求全部转发到 Consul Agent。

服务健康检查

心跳方式比较简单，客户端上报自己的存活状态即可。

但存活不代表健康，例如一个应用的服务层没问题，但数据库连接故障了，那么就无法正常提供服务，这就是存活但不健康。

Eureka 支持服务自定义健康检查逻辑。

Consul 支持的很全面，可以配置服务自定义的健康检查接口地址，还有完善的管理界面，可以查看所有服务和节点的健康检查状态。

推荐阅读：

• Zookeeper vs Etcd

• 前端开发利器 - Wep Replay

• kafka 中 zookeeper 具体是做什么的？

• 分布式唯一ID的生成方案

• 如何判断一个元素是否存在于一个亿级数据集中？