这是我参与8月更文挑战的第17天，活动详情查看：8月更文挑战
0.1 用Zookeeper真的合适么
前些时候，一篇阿里为什么不用zookeeper做服务发现的文章被纷纷传阅。这里，我们对涉及到主要观点再做下简要阐述：
1、注册中心的高可用诉求
问：CAP中注册中心一定要保证的是谁？
是分区容错性。
分布式服务依赖网络进行节点连通，在遇到任何网络分区故障时，仍然需要能够保证系统可以对外提供服务（一致性 或 可用性的服务），除非是整个网络环境都发生了故障。
来源：www.w3cschool.cn/zookeeper/
我们不允许当节点间通信出现故障时，被孤立节点都不能提供服务。最简单的，可以让所有节点拥有所有数据。
问：在分区容错前提下，注册中心需要保的是一致性还是可用性？
如果保证一致性，是否可以满足我们对系统的诉求呢。
来源：infoq.cn/article/why-doesnot-alibaba-use-zookeeper
如图，假如机房3 内部署了ServiceA，ServiceB，连接ZK5，由于发生网络异常，ZK5节点无法工作，则serviceB的实例都无法进行注册，处于机房3内的serviceA , 无法正常调用ServiceB的任何实例，这个是我们不希望看到的。
而如果保证可用性，因为机房内部各节点是连通的，因此，调用无影响，这才更符合我们的希望。
然而，zookeeper实际上实现的是CP原则。当在Leader选举过程中或一些极端情况下，整个服务是不可用的。
但是我们对于注册中心的可用性诉求，要比数据一致性要大的多。也可以说，生产环境，我们是无法容忍注册中心无法保证可用性。这对实际生产的影响是灾难性的。
2、注册中心的容灾诉求
在实践中，注册中心不能因为自身的任何原因破坏服务之间本身的可连通性。所以，如果整个注册中心宕机了呢？
但是，zookeeper是无法实现跨机房、跨地域容灾的。
因为，它只能存在一个leader。
3、服务规模、容量的增长
互联网的发展，有一定的偶发性，现在的节点上限、带宽能满足业务发展，1年后也能满足么? 3年后呢？
当扛不住后，ZK能水平扩展么？是不行的。。。
