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