阿里巴巴为什么不用 ZooKeeper 做服务发现？

注册中心需求分析及关键设计考量

注册中心是 CP 还是 AP 系统?

CAP 和 BASE 理论相信读者都已经耳熟能详，其业已成了指导分布式系统及互联网应用构建的关键原则之一，在此不再赘述其理论，我们直接进入对注册中心的数据一致性和可用性需求的分析:

数据一致性需求分析:

注册中心最本质的功能可以看成是一个 Query 函数 Si = F(service-name)，以service-name为查询参数，service-name对应的服务的可用的endpoints (ip:port)列表为返回值.

注: 后文将 service 简写为 svc。

先来看看关键数据 endpoints (ip:port)不一致性带来的影响，即 CAP 中的 C 不满足带来的后果 :

很明显，在分布式系统中，即使是对等部署的服务，因为请求到达的时间，硬件的状态，操作系统的调度，虚拟机的 GC 等，任何一个时间点，这些对等部署的节点状态也不可能完全一致，而流量不一致的情况下，只要注册中心在 SLA 承诺的时间内（例如 1s 内）将数据收敛到一致状态（即满足最终一致），流量将很快趋于统计学意义上的一致，所以注册中心以最终一致的模型设计在生产实践中完全可以接受.

分区容忍及可用性需求分析:

接下来我们看一下网络分区（Network Partition）情况下注册中心不可用对服务调用产生的影响，即 CAP 中的 A 不满足时带来的影响。

现在因为注册中心自身为了保脑裂 (P) 下的数据一致性（C）而放弃了可用性，导致了同机房的服务之间出现了无法调用，这是绝对不允许的！可以说在实践中，注册中心不能因为自身的任何原因破坏服务之间本身的可连通性，这是注册中心设计应该遵循的铁律！后面在注册中心客户端灾容上我们还会继续讨论。

通过以上我们的阐述可以看到，在 CAP 的权衡中，注册中心的可用性比数据强一致性更宝贵，所以整体设计更应该偏向 AP，而非 CP，数据不一致在可接受范围，而 P 下舍弃 A 却完全违反了注册中心不能因为自身的任何原因破坏服务本身的可连通性的原则。