服务注册发现技术对比

技术对照表

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 支持的很全面,可以配置服务自定义的健康检查接口地址,还有完善的管理界面,可以查看所有服务和节点的健康检查状态。

推荐阅读:

服务注册发现技术对比_第1张图片

你可能感兴趣的:(zookeeper)