工行总结了 Zookeeper 在作为服务注册中心时面临的哪些问题？

.1.随着服务数量以及服务提供者节点的增加，服务推送的数据量会呈爆炸式增长。举个例子，一个服务有 100 个提供者，当提供者启动的时候，因为 Zookeeper 的 CP 特性，每上线一个提供者，消费者都会收到事件通知，并从 Zookeeper 来读取这个服务的当前全部提供者的列表，然后刷新本地缓存。这个场景下，理论上每个消费者总共收到了 100 次事件通知，并从 Zookeeper 读取了 100 次服务提供者列表，1+2+3+...+100，总计 5050 条提供者数据。这在业务系统投产高峰期问题尤为突出，容易导致 Zookeeper 集群的网络被打满，造成服务订阅效率极其低下，并进一步影响了服务注册的性能。 2.随着写在 Zookeeper 上节点数量的增多，Zookeeper 的 snapshot 文件也不断变大，每次snapshot 写入磁盘，会出现一次磁盘 IO 冲高。投产高峰期，因为事务量大，写 snapshot 文件的 频率也非常高，这对基础设施带来了较大的风险。同时 snapshot 文件越大，也预示着 Zookeeper 节点故障后恢复的时间越长。 3.当 Zookeeper 选举节点发生重新选举后，Observer 节点都要从新的 Leader 节点同步全量事务，这个阶段如果耗时过长，就很容易导致连接在 Observer 节点上的客户端 session 超时，使对应providers 节点下的临时节点全部被删除，即从注册中心角度看，这些服务都下线了，消费者端则 出现无提供方的异常报错。紧接着，这些提供者会重新连接 Zookeeper 并重新注册服务，这种短时间内大批量服务的注册翻转现象，往往带来更为严重的服务注册推送的性能问题。

答复内容摘自《云原生技术与架构实践年货小红书》，这本电子书收录开发者藏经阁 下载连接：https://developer.aliyun.com/topic/download?id=1127