今天在家水群的时候，发现群里在讨论关于注册中心的选择，Zookeeper，Nacos，Eureka到底是用哪个。有人说用Zookeeper好，有人说Nacos好，各有各的说法。具体怎么好，也没人说上来。其实说来说去，就是在CAP定理中，选择AP还是CP。只要仔细想想注册中心的职责，就该知道如何选择了。
注册中心是 CP 还是 AP 系统
CAP 和 BASE 理论已经耳熟能详，其业已成了指导分布式系统及互联网应用构建的关键原则之一，在此不再赘述其理论。
注册中心的本质功能可以当成一个函数 Si = F(service-name)。service-name是查询参数，ip和port(以下简称endpoints)是返回值。
C不满足
先来分析一下endpoints不一致带来的影响，即CAP中C不满足带来的后果。
假设我们有一个ServiceA 服务部署了3个节点，其中1个节点刚刚启动。此时有ServiceB调用ServiceA，那么 ServiceB 肯定会先去注册中心获取 ServiceA 的endpoint信息。这时候，会用两种返回值: Si = f(ServiceA1, ServiceA2) 和 Si = f(ServiceA1, ServiceA2, ServiceA3)
那么这次不一致带来的影响是什么？ServiceA的各个节点流量会有一点不均衡，因为ServiceA3节点刚刚启动，注册中心的数据还没有全部同步。所以，打在ServiceA3中的流量会少一点。
在分布式系统中，即使对等部署的服务，因为请求到达的时间，硬件的状态，操作系统的调度，虚拟机的GC等，都会导致在任一时间点这些对等的服务状态也不可能完全一致。注册中心都会有一个SLA承诺时间，比如1S内将数据完全同步，即最终一致性，这一点我们可以完全接受。
A不满足
下面分析一下注册中心不可用对服务调用产生的影响，即CAP中A不满足时带来的后果。
一个典型的Zookeeper3机房3节点(zk1, zk2, zk3)部署，其中zk1是leader。假设其中一个节点机房zk3出现网络分区，虽然Zookeeper服务是可用的，但是zk3是不可写的，因为联系不上leader。也就是说，这时候部署在机房3的服务是不可以重新部署，扩容的。站在服务调用的角度上看，机房3的服务虽然无法调用机房1和机房2的服务，但是与自己本机房的服务网络明明是通的啊。为什么在同一个机房内的服务却不能调用？？？
熟悉Zookeeper的人应该都知道Zookeeper中有个脑裂的概念，Zookeeper自身为了保脑裂(CAP中的P)下的数据一致性(C)而放弃了可用性(A)，导致了同一个机房的服务无法相互调用。可以说，这是绝对不允许的。在实践中，注册中心不能因为自身的任何原因破坏服务之间本身的可连通性，这是注册中心设计应该遵循的铁律！
同时我们再考虑一下这种情况下的数据不一致性(AP)，如果机房1，2，3之间都成了孤岛，那么如果每个机房的服务都只拿到本机房的服务的ip列表，也即在各机房的服务列表数据完全不一致，影响是什么？在这种情况下，会全部变成同机房调用。设计注册中心的时候，有时候甚至会主动利用这种注册中心的数据可以不一致性，来帮助应用主动做到同机房调用。
结语
通过以上分析，可以看到，注册中心的可用性比数据强一致性更宝贵，所以整体设计更应该偏向 AP，而非 CP，数据不一致在可接受范围，而P下舍弃A却完全违反了注册中心不能因为自身的任何原因破坏服务本身的可连通性的原则。
这篇文章并不是全盘否定Zookeeper，Zookeeper本职是分布式协调服务器，注册中心只是他的功能之一，在粗粒度分布式锁，分布式选主，主备高可用切换等不需要高TPS 支持的场景下有不可替代的作用。
只是，在进行架构设计中，选择正确的注册中心，对整个微服务架构是至关重要的。这只是我对如何选择注册中心的一个总结，希望对以后如何正确的使用Zookeeper，如何自己设计一个注册中心有个参考依据。条条大路通罗马，祝愿你的注册中心直接就诞生在罗马。
