服务注册发现技术对比
技术对照表
| 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 可以参见：
数据一致性
ZAB 是 zookeeper 的原子广播协议，基于 Paxos 算法改的。
Raft 是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。
这两个算法都没毛病，都可以实现分布式一致性，只是实现方式不同。
Eureka 选择的是 AP，不要求强一致性，自然没有使用数据一致性算法。
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 支持的很全面，可以配置服务自定义的健康检查接口地址，还有完善的管理界面，可以查看所有服务和节点的健康检查状态。
推荐阅读：
