服务注册发现技术对比

技术对照表

	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存储	✅	✅	✅	❌
服务健康检查	心跳	心跳	服务状态，<br/>内存，硬盘等	自定义
自身监控	❌	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 协议中的消息会以一传10、十传百的指数级速度在网络中快速传播。

网络中任何节点的异常都不会影响 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的生成方案
• 如何判断一个元素是否存在于一个亿级数据集中？