要想在 ZooKeeper 基础上硬着头皮解决服务规模的增长问题 ， 一个实践中可以考虑的方法是想办法梳理业务 ， 垂直划分业务域 ， 将其划分到多个 ZooKeeper 注册中心 ， 但是作为提供通用服务的平台机构组 ， 因自己提供的服务能力不足要业务按照技术的指挥棒配合划分治理业务 ， 真的可行么？
而且这又违反了因为注册中心自身的原因（能力不足）破坏了服务的可连通性 ， 举个简单的例子 ， 1 个搜索业务 ， 1 个地图业务 ， 1 个大文娱业务 ， 1 个游戏业务 ， 他们之间的服务就应该老死不相往来么？也许今天是肯定的 ， 那么明天呢 ， 1 年后呢 ， 10 年后呢？谁知道未来会要打通几个业务域去做什么奇葩的业务创新？注册中心作为基础服务 ， 无法预料未来的时候当然不能妨碍业务服务对未来固有联通性的需求 。
注册中心需要持久存储和事务日志么？需要 ， 也不需要 。
我们知道 ZooKeeper 的 ZAB 协议对每一个写请求 ， 会在每个 ZooKeeper 节点上保持写一个事务日志 ， 同时再加上定期的将内存数据镜像（Snapshot）到磁盘来保证数据的一致性和持久性 ， 以及宕机之后的数据可恢复 ， 这是非常好的特性 ， 但是我们要问 ， 在服务发现场景中 ， 其最核心的数据 – 实时的健康的服务的地址列表真的需要数据持久化么？
对于这份数据 ， 答案是否定的 。
如上图所示 ， 如果 svcB 经历了注册服务 (ip1) 到扩容到 2 个节点（ip1 ， ip2）到因宕机缩容 (ip1 宕机） ， 这个过程中 ， 产生了 3 次针对 ZooKeeper 的写操作 。
但是仔细分析 ， 通过事务日志 ， 持久化连续记录这个变化过程其实意义不大 ， 因为在服务发现中 ， 服务调用发起方更关注的是其要调用的服务的实时的地址列表和实时健康状态 ， 每次发起调用时 ， 并不关心要调用的服务的历史服务地址列表、过去的健康状态 。
但是为什么又说需要呢 ， 因为一个完整的生产可用的注册中心 ， 除了服务的实时地址列表以及实时的健康状态之外 ， 还会存储一些服务的元数据信息 ， 例如服务的版本 ， 分组 ， 所在的数据中心 ， 权重 ， 鉴权策略信息 ， service label 等元信息 ， 这些数据需要持久化存储 ， 并且注册中心应该提供对这些元信息的检索的能力 。
Service Health Check使用 ZooKeeper 作为服务注册中心时 ， 服务的健康检测常利用 ZooKeeper 的 Session 活性 Track 机制 以及结合 Ephemeral ZNode 的机制 ， 简单而言 ， 就是将服务的健康监测绑定在了 ZooKeeper 对于 Session 的健康监测上 ， 或者说绑定在 TCP 长链接活性探测上了 。
【dubbo提供者配置 zookeeper和dubbo原理】这在很多时候也会造成致命的问题 ， ZK 与服务提供者机器之间的 TCP 长链接活性探测正常的时候 ， 该服务就是健康的么？答案当然是否定的！注册中心应该提供更丰富的健康监测方案 ， 服务的健康与否的逻辑应该开放给服务提供方自己定义 ， 而不是一刀切搞成了 TCP 活性检测！
健康检测的一大基本设计原则就是尽可能真实的反馈服务本身的真实健康状态 ， 否则一个不敢被服务调用者相信的健康状态判定结果还不如没有健康检测 。
注册中心的容灾考虑前文提过 ， 在实践中 ， 注册中心不能因为自身的任何原因破坏服务之间本身的可连通性 ， 那么在可用性上 ， 一个本质的问题 ， 如果注册中心（Registry）本身完全宕机了 ， svcA 调用 svcB 链路应该受到影响么？
是的 ， 不应该受到影响 。
服务调用（请求响应流）链路应该是弱依赖注册中心 ， 必须仅在服务发布 ， 机器上下线 ， 服务扩缩容等必要时才依赖注册中心 。
推荐阅读
- 红米note2出厂系统版本 红米note2参数配置
- 金立M30怎么样，金立M30主要参数配置是什么
- wastl10是什么机型nova几，华为nova青春版参数配置
- vivox7plus手机现在价格 vivox7plus参数配置详情
- 鱼缸下过滤器水加多少，鱼缸下过滤系统需要几个泵怎么配置
- 骁龙870参数配置是什么，有什么特别之处？
- 红米Note9Pro和荣耀30s有哪些配置区别，哪个好性价比更高
- 华为Mate50Pro参数配置详情，华为Mate50Pro怎么样？
- 三星GalaxyZFlipLite参数配置详情，感兴趣的朋友不要错过了
- 三星GalaxyZFlip2的相关配置，三星GalaxyZFlip2怎么样？