今天风和日丽，阳光高照，虽然是周末，但是小慕仍然来到了公司肝文，不为别的，就为了让关注我的靓仔靓女们有东西值得看。（快夸我勤快，哈哈
）。 话说天气现在越来越热起来了，于是我穿上了我的凉皮鞋，被同事吐槽是罗马战士的战靴，看图，反正我是觉得挺好看的，Great!
废话不多说了，我们看看今天要学习的内容吧，eureka和zookeeper有什么区别？ 当年我入职半年以后，曾经有领导找我谈话的时候，曾经就问我这两者有什么区别。当时我没回答上来，后来我就专门查资料去搞明白这两者的区别是啥，那么今天我正好想把这个问题抛出来一起研究！
一、啥是服务注册中心？到底有啥用？
我简单说一下做个说明吧，在微服务领域，服务与服务之间会存在着相互调用。比如在A服务中要调用B服务，这个是不是得拿到B服务的实例入口？那A服务要怎么拿到B服务的实例呢？这个时候就体现出注册中心的作用了，让B服务把自己的实例信息注册到 服务注册中心上，然后A去注册中心上获取B服务的信息不就行了，这样的话，A服务就可以调用B的服务了，so easy, OK!
二、注册中心有哪些？各有啥特点？
在springCloud微服务架构中，有很多注册中心组件可供我们我们选择，比如常见的eureka，zookeeper，nacos,Consul, 到底哪个好呢？不好说，只能说各自有其特点，网上有人整理了出来，挺详细的。
三、为啥说Eureka是支持AP,而Zookeeper支持CP呢？
Zookeeper集群和Eureka集群有一个最大的区别，zookeeper集群是存在leader和follower关系的，也就是一主多从。
而eureka集群却不是这样，eureka集群中的各个节点是平等的地位，peer to peer对等通信。这是一种去中心化的架构，在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点都可被视为其他节点的副本。
zookeeper是如何保证“一致性”呢？
当往zookeeper的leader节点写数据时，leader会对剩下的follower节点进行主从数据同步，它必须得同步超过半数的follower节点才给客户端返回写成功的信号。
所以从这点上它是保证了数据一致性，但是却不是强一致性。
另外一点就是，如果由于网络故障或是其他原因导致leader节点挂了，那么这个时候zookeeper集群就得在剩下那些follower接点中重新进行leader的选举，选出一个新leader来。但是别忘了，选举是需要时间的，哪怕30s到120秒，这一段时间之内，zookeeper集群是不能给外部提供服务的，处于不可用的状态，所以从这个角度来讲它丧失了一定的系统可用性（即CAP中的A）。
eureka是如何保证“可用性”的呢？
Eureka集群中各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper集群那样使整个注册服务瘫痪。
