Zookeeper作为注册中心缺陷

• 1、CAP与BASE
  • zk 满足CAP理论中的CP，牺牲A；作为注册中心是可用性A重要还是C强一致性重要
    • 若满足了C强一致性则牺牲服务联通性，注册中心本身不应该影响服务间的连通性
    • 若满足了A可用性，牺牲了强一致性，带的问题只是每个服务消费不均衡，满足最终一致性，也是在可控范围之内
• 2、性能问题
  • 当服务集群节点规模过大在几十万或者几百万级别时，若服务进行发布或者扩容操作时会很容易打满网卡，事件广播流量=（服务+消费）2服务集群节点数*1KB
  • 单点写问题，不能水平扩展解决写的性能问题
    • 写请求串行化，Leader写
• 3、持久化
  • 是否关心过去持久化的数据，关注的是实时的节点、接口数据
  • 健康检查的节点列表数据可以不持久化，最多带来负载不均衡的问题
  • 接口信息相关数据注册之后不会变，变化的是节点列表数据
    • 应该考虑分开存储
• 4、容灾
  • 应用弱依赖注册中心
  • 注册中心完全不可用的情况下，目前是无法满足的
    • 客户端提供缓存
• 5、健康检查
  • 做的是TCP的存活性检测，而非服务本身的健康检查