微服务架构中，注册中心基本上是第一个接触到的中间件，今天就简单的分析下注册中心的本质和选择依据。
下面就从以下三点来学习和分析吧：
- 注册中心本质
- Zookeeper是注册中心的最佳选择吗？
- 注册中心选型对比
1、注册中心本质
基本功能：
如图所示，注册中心的基础功能主要包括如下三点：
1.服务注册/服务发现，这个是注册中心最最基本的功能了。
2.故障发现/服务提出，在运行过程中，难免会出现部分服务出现异常done机的情况，这时候注册中心就需要能自动的发现故障，并及时剔除对应的服务
3.服务恢复/重新发现，故障的服务在重新启动恢复后，又需要重新的注册以及重新发现。
以上三点应该是注册中心最核心的功能了，当然，如果需要做的更加完善，还需要提供监控以及服务管理功能。
CP or AP
注册中心的最基本的功能，其实也就是提供数据的存取功能，因此我们需要分析下会出现数据不一致的场景。
个人任务主要有以下两种情况：
1.注册中心1与注册中心2数据不一致，服务调用方连接不同的注册中心。导致不同的服务调用方获得的服务提供者IP列表不一致。
2.服务调用方本地存储服务提供者IP列表，当服务调用方与注册中心网络故障时，若注册中心内的服务提供方IP有变更，此时服务调用方无法及时更新本地存储的服务提供者IP列表。导致不同的服务调用方获得的服务提供者IP列表不一致。
当数据出现不一致时，注册中心到底影响的是什么呢？其实分析下就会发现，影响的也就是流量不均衡。
因为在服务调用方会有本地缓存，当数据不一致时，最终体现的也就是不同的服务调用方进行路由时的服务提供列表不一样。
因此可以分析得出，注册中心其实只要满足AP即可，无须保证数据的强一致性。
2、Zookeeper是注册中心的最佳选择吗？
最近关于Zookeeper不是注册中心的最佳选择的分析文章很多，我也就简单的说说我的理解吧。先看下下图：
如上图所示，Zookeeper分别部署在三个机房，重点分析下下面两种情况：
1.A和B机房之间网络断开，或者B和C机房之间网络断开，此时由于Zookeeper选举机制的N/2+1仍然是满足的，所以Zookeeper集群仍正常服务。影响的只是单独出去的机房，比如上述情况的B机房或者C机房。这种情况下面，B机房或者C机房的服务是无法注册和无法发现的。
2.A、B、C三个机房的网络都断开了，这个时候整个Zookeeper的选举都是无法成功的，最终导致所有机房的服务都无法注册和无法发现，进而系统无法正常使用。
从这两点分析，再结合上述分析注册中心是AP的，可以得出Zookeeper不是注册中心的最佳选择的原因：
1.注册中心的本质是AP，而Zookeeper的本质是CP的。
2.在复杂的或者大量的服务节点（1000+）场景下，Zookeeper是不适合作为注册中心的。
3、注册中心选型对比
最后，来对比下目前市面上常见的注册中心吧。
上图简单的从两个维度来对比了目前大部分注册中心，我们可以根据自己的业务常见来选择了，是选择CP的还是AP？
