服务注册发现技术对比 -高频面试必知必会系列
2022-02-16 11:25:53 14 举报AI智能生成
一文看懂服务注册发现技术选型思路 zookeeper etcd consul eureka CAP模型 数据一致性算法 多数据中心（多机房） 多语言支持 服务健康检查 自身监控 SpringCloud支持 自身开发语言
作者其他创作
大纲/内容
服务健康检查
zookeeper
心跳
etcd
心跳
consul
服务状态
内存
硬盘
等
eureka
自定义
自身监控<br>
zookeeper
无
etcd
metrics
consul
服务状态
内存
硬盘
等
eureka
自定义
SpringCloud 支持<br>
zookeeper
支持
etcd
支持
consul
支持
eureka
支持
自身开发语言<br>
zookeeper
java
etcd
go
consul
go
eureka
java
CAP模型<br>
zookeeper
CP
etcd
CP
consul<br>https://www.cnblogs.com/dalianpai/p/12269024.html<br>https://zhuanlan.zhihu.com/p/361869606<br>
CP
eureka
AP
扩展
数据一致性算法<br>
zookeeper<br>
ZAB
ZAB 是 zookeeper 的原子广播协议，基于 Paxos 算法改的。<br>用于奔溃恢复和状态同步
分布式一致性算法Paxos
etcd<br>
Raft
Raft 是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。<br><br>
分布式一致性算法Raft
consul<br>
Raft
eureka<br>
无
Eureka 选择的是 AP，不要求强一致性，自然没有使用数据一致性算法。<br><br>
总结
ZAB和Raft这两个算法都没毛病，都可以实现分布式一致性，只是实现方式不同。<br><br>
多数据中心（多机房）<br>
zookeeper
不支持（不建议更为准确）
zookeeper 不支持多数据中心是指，如果你跨多个机房部署了一套 zookeeper，一旦出现网络划分，那么就不可用了。<br><br>
etcd
不支持
consul
支持
Consul 是通过 Gossip 协议实现的。<br><br>
Gossip 协议中的消息会以一传十、十传百的指数级速度在网络中快速传播。<br><br>
网络中任何节点的异常都不会影响 Gossip 消息传播，分布式系统容错性极强。<br><br>
Gossip 协议是去中心化的，所有节点对等，节点无需知道整个网络状况，只要网络是连通的，任意一个节点就可以把消息散播到全网。<br><br>
eureka
不支持
多语言支持<br>
zookeeper
支持多客户端
Zookeeper 多语言客户端比较成熟。<br><br>
etcd
Http/gRPC
consul
Http/DNS
DNS
Consul 支持 DNS 比较有意思，如果你第一次看到可能不太理解。<br><br>
DNS 方式允许应用程序使用服务发现，而无需与Consul进行任何高度集成。<br><br>
例如，不需要向 Consul 发送 HTTP 请求，可以使用 DNS 服务器直接通过名字查找，如 redis.service.us-east-1.consul，就会自动转查找位于 us-east-1 这个数据中心提供 redis 服务的节点。<br><br>
使用DNS的方式可以在程序中集成一个DNS解析库，也可以自定义本地的DNS Server。<br><br>
自定义本地 DNS Server 是指将 .consul 域的请求全部转发到 Consul Agent。<br><br>
eureka
Http
Watch
zookeeper
TCP
Zookeeper 的 watch 实现比较简单，就是 TCP Ping。<br><br>
etcd
Long Polling（长轮询）(拉模式)
Long Polling（长轮询）是拉模式，客户端每隔一段时间请求拉取一次数据。<br><br>
客户端发起 Long Polling，如果服务端没有数据，会等待，直到服务端有数据，或者等待到超时，返回后，客户端会再次发起 Long Polling。<br><br>
consul
Long Polling（长轮询）(拉模式)
eureka
Long Polling（长轮询）(拉模式)
KV存储
zookeeper
etcd
支持
支持
consul
支持
eureka
不支持
高频面试题
Zookeeper vs Etcd
Zookeeper
概述
zookeeper 起源于 Hadoop，后来进化为 Apache 的顶级项目。<br><br>现在已经被广泛使用在 Apache 的项目中，例如 Hadoop，kafka，solr 等等。<br><br>
zookeeper 使用 ZAB 协议作为其一致性协议。<br><br>
<br>zookeeper 通过团队的形式工作，一组 node 一起工作，来提供分布式能力，这组 node 的数量需要是奇数。
<br><br>第一个节点与其他节点沟通，选举出一个 leader，获取多数票数的成为 leader，这就是为什么需要奇数个 node，其他节点被称为follower。<br>
<br>client 连接 zookeeper 时可以连接任何一个，client 的读请求可以被任何一个节点处理，写请求只能被 leader 处理。所以，添加新节点可以提高读的速度，但不会提高写的速度。
<br><br>对于 CAP 模型，zookeeper 保障的是 CP。
zookeeper架构
子主题
ZNode
Znode架构
子主题<br>
特性
存储数据时，zookeeper 使用树形结构，其中的每个节点称作 ZNode，访问一个 ZNode 时，需要提供从 root 开始的绝对路径。
每个 ZNode 可以存储最多 1MB 的数据，用户可以：<br><br> - 创建 ZNode<br> - 删除 ZNode<br> - 存储数据到指定 ZNode<br> - 从 ZNode 中读取数据
zookeeper 还提供了一个非常重要的特性：watcher API。<br><br>
zookeeper watches<br>
用户可以对一个 ZNode 设置 watch，当这个 ZNode 发生了变化时，例如 创建、删除、数据变更、添加或移除子节点，watch API 就会发出通知，这是 zookeeper 非常重要的功能。
<br><br>zookeeper 的 watch 有一个缺点，就是这个 watch 只能被触发一次，一旦发出了通知，如果还想对这个节点继续 watch，用户需要重新设置 watch。
优点<br>
非阻塞全部快照（达成最终一致）
<br>高效的内存管理
<br>高可靠
<br>API 简单
<br>连接管理可以自动重试
<br>ZooKeeper recipes 的实现是经过完整良好的测试的。
<br>有一套框架使得写新的 ZooKeeper recipes 非常简单。
<br>支持监听事件
<br>发生网络分区时，各个区都会开始选举 leader，那么节点数少的那个分区将会停止运行。
缺点
zookeeper 是 java 写的，那么自然就会继承 java 的缺点，例如 GC 暂停。
<br>如果开启了快照，数据会写入磁盘，此时 zookeeper 的读写操作会有一个暂时的停顿。
<br>对于每个 watch 请求，zookeeper 都会打开一个新的 socket 连接，这样 zookeeper 就需要实时管理很多 socket 连接，比较复杂。
Etcd
概述
etcd 是用 go 开发的，出现的时间并不长，不像 zookeeper 那么悠久和有名，但是前景非常好。<br>
<br>etcd 是因为 kubernetes 而被人熟知的，kubernetes 的 kube master 使用 etcd 作为分布式存储获取分布式锁，这为 etcd 的强大做了背书。
etcd 使用 RAFT 算法实现的一致性，比 zookeeper 的 ZAB 算法更简单。
<br><br>etcd 没有使用 zookeeper 的树形结构，而是提供了一个分布式的 key-value 存储。
Etcd架构图
子主题
API
<br>put - 添加一个新的 key-value 到存储中
<br>get - 获取一个 key 的 value
<br>range - 获取一个范围的 key 的 value，例如：key1 - key10
<br>transaction - 读、对比、修改、写的组合
<br>watch - 监控一个或一个范围的 key，发生变化后就会得到通知
优点
性能比较
子主题
支持增量快照，避免了 zookeeper 的快照暂停问题
<br>堆外存储，没有垃圾回收暂停问题
<br>无需像 zookeeper 那样为每个 watch 都做个 socket 连接，可以复用
<br>zookeeper 每个 watch 只能收到一次事件通知，etcd 可以持续监控，在一次 watch 触发之后无需再次设置一次 watch
<br>zookeeper 会丢弃事件，etcd3 持有一个事件窗口，在 client 断开连接后不会丢失所有事件
缺点
如果超时，或者 client 与 etcd 网络中断，client 不会明确的知道当前操作的状态
<br>在 leader 选举时，etcd 会放弃操作，并且不会给 client 发送放弃响应
<br>在网络分区时，当 leader 处于小分区时，读请求会继续被处理
总结
zookeeper 是用 java 开发的，被 Apache 很多项目采用。
<br><br>etcd 是用 go 开发的，主要是被 Kubernetes 采用。
<br><br>zookeeper 非常稳定，是一个著名的分布式协调系统，etcd 是后起之秀，前景广阔。
<br><br>因为 etcd 是用 go 写的，现在还没有很好的 java 客户端库，需要通过 http 方式调用。
<br><br>而 zookeeper 在这方面就成熟很多，对于 java 之外的其他开发语言都有很好的客户端库。
<div class="mind-clipboard"><br><br>具体选择 zookeeper 还是 etcd，需要根据您的需求结合它们各自的特性进行判断，还有您所使用的开发语言。</div>
kafka中zookeeper是干什么的？
概述
zookeeper 是 kafka 不可分割的一部分，可见其重要程度，所以我们有必要了解一下 zookeeper 在 kafka 中的具体工作内容。<br>
<br><br>zookeeper 存储了一些关于 consumer 和 broker 的信息，那么就从这两方面说明 zookeeper 的作用。
broker
状态
<br>zookeeper 记录了所有 broker 的存活状态，broker 会向 zookeeper 发送心跳请求来上报自己的状态。<br>
<br>zookeeper 维护了一个正在运行并且属于集群的 broker 列表。
控制器选举
<br>kafka 集群中有多个 broker，其中有一个会被选举为控制器。
<br><br>控制器负责管理整个集群所有分区和副本的状态，例如某个分区的 leader 故障了，控制器会选举新的 leader。<br>
<br>从多个 broker 中选出控制器，这个工作就是 zookeeper 负责的。
限额权限
<br>kafka 允许一些 client 有不同的生产和消费的限额。<br>
<br>这些限额配置信息是保存在 zookeeper 里面的。<br>
<br>所有 topic 的访问控制信息也是由 zookeeper 维护的。
记录 ISR
<br>ISR（in-sync replica） 是 partition 的一组同步集合，就是所有 follower 里面同步最积极的那部分。<br>
<br>一条消息只有被 ISR 中的成员都接收到，才被视为“已同步”状态。<br>
<br>只有处于 ISR 集合中的副本才有资格被选举为 leader。<br>
<br>zookeeper 记录着 ISR 的信息，而且是实时更新的，只要发现其中有成员不正常，马上移除。
node 和 topic 注册
<br>zookeeper 保存了所有 node 和 topic 的注册信息，可以方便的找到每个 broker 持有哪些 topic。<br>
<br>node 和 topic 在 zookeeper 中是以临时节点的形式存在的，只要与 zookeeper 的 session 一关闭，他们的信息就没有了。
topic 配置
<br>zookeeper 保存了 topic 相关配置，例如 topic 列表、每个 topic 的 partition 数量、副本的位置等等。
consumer
offset
<br>kafka 老版本中，consumer 的消费偏移量是默认存储在 zookeeper 中的。<br>
<br>新版本中，这个工作由 kafka 自己做了，kafka 专门做了一个 offset manager。
注册
<br>和 broker 一样，consumer 也需要注册。<br>
<br>consumer 会自动注册，注册的方式也是创建一个临时节点，consumer down 了之后就会自动销毁。
分区注册
<br>kafka 的每个 partition 只能被消费组中的一个 consumer 消费，kafka 必须知道所有 partition 与 consumer 的关系。
什么是CAP
Consistence（一致性）
<br>Availability（可用性）
<br>Partition Tolerance（分区容错性）
收藏
0 条评论
下一页
