Zookeeper适合做服务发现吗

在Dubbo这个RPC框架中，Zookeeper充当着注册中心的角色，那Zookeeper适合做服务发现吗？今天咱们就来讨论一下

1. 注册中心是CP还是AP系统

相信大家是比较熟悉CAP理论的，C:一致性 A:可用性 P:分区容忍性 

一致性分析

如图所示，比如一个服务有10台机器，注册到注册中心了，由于注册中心的不一致，而consumer的同一函数的两次调用中，第一次返回了，1，2，...，9机器列表，第二次返回了2，3，...，10. 这样的影响是provider的1，10两台机器流量的不均匀，但是在分布式系统中，即使是对等部署的服务，因为请求到达的时间，硬件的状态，操作系统的调度，虚拟机的 GC 等，任何一个时间点，这些对等部署的节点状态也不可能完全一致，而流量不一致的情况下，只要注册中心在SLA承诺的时间内（例如1s内）将数据收敛到一致状态（即满足最终一致），流量将很快趋于统计学意义上的一致，所以注册中心以最终一致的模型设计在生产实践中完全可以接受。

分区容忍及可用性分析

以zk集群为例子，当机房三出现网络分区时，成为一个孤岛，此时节点zk5是不可写的，所以机房三的provider不能注册，这就出现了一个矛盾，机房三里的consumer和provider之间的网络是好的，为啥不能调用本机房的服务，现在因为注册中心自身为了保脑裂(P)下的数据一致性（C）而放弃了可用性，导致了同机房的服务之间出现了无法调用，这是绝对不允许的！可以说在实践中，注册中心不能因为自身的任何原因破坏服务之间本身的可连通性，这是注册中心设计应该遵循的铁律

同时在这种情况下，如果机房1，2，3之间都成了孤岛，那么如果每个机房的consumer都只拿到本机房的 provider的ip列表，也即在各机房provider 的ip列表数据完全不一致，影响是什么？其实没啥大影响，只是这种情况下，全都变成了同机房调用而已

综上所述，在 CAP 的权衡中，注册中心的可用性比数据强一致性更宝贵，所以整体设计更应该偏向 AP，而非 CP，数据不一致在可接受范围，而P下舍弃A却完全违反了注册中心不能因为自身的任何原因破坏服务本身的可连通性的原则。zookeeper侧重于CP，所以实际上zookeeper不适合做服务发现

2. 扩展性问题

熟悉zookeeper的同学可能知道，zookeeper的写并不是可扩展的，不可以通过加节点解决水平扩展性问题。作为一个服务发现的注册中心，势必会影响到服务的规模和容量，这也是为什么阿里的双十一采用的HSF的注册中心不是zookeeper的缘故

综上所述：zookeeper主要用来做分布式协调，不适合做服务发现