SpringCloud的架构总结（一）：注册服务中心，Eureka

            SpringCloud的架构总结（一）：注册服务中心，Eureka

SpringCloud是一个分布式服务框架，提供了分布式开发中所需要的重要模块，如服务注册中心，服务提供者和消费者等等，基于SpringBoot开发也使得开发分布式服务时更加的便捷。

SpringCloud有诸多的模块，笔者将会循序渐进，推出相关的介绍，首先说说SpringCloud注册服务中心--Eureka。

说到注册服务中心，我们可能会想到另外一个大名鼎鼎的分布式框架，Dubbo，Dubbo默认采用zookeeper来作为服务注册中心，其作用和Eureka是一样的，用于服务的注册和发现。

本系列文章将不会细致的介绍项目的搭建，具体的开发方式，读者可以参考下面的文章：Eureka开发。

Zookeeper的特点

此处我们回顾一下zookeeper的特点，zookeeper依赖ZAB（原子广播协议）来保证zookeeper集群的一致性以及高可用性。

在zookeeper中，每一个提交到服务器端的事务都会有一个zxid，以保证事务先后的有序性，只有当事务作用于每一个follower下时，leader才会确认事务的提交，这也就是ZAB中的消息广播。

zookeeper在leader崩溃时，需要选举follower中，事务id编号最大的节点作为子节点，此时，zookeeper集群是无法提供对外服务的，这也就是ZAB中的崩坏恢复。

zookeeper的follower可以分担leader读取压力，所以zookeeper的qps是相当高的，但是由于强一致性的限制，只有leader能够进行写操作，并且在节点增加以后，leader会增加同步带来的压力，所以，zookeeper的tps不是特别的高，这也是他不能作为内存数据库的原因。

CAP

分布式开发中有一个著名的CAP原理，C（一致性），A（可用性），P（分区容错性），这三者在开发中不可兼得，很容易的可以理解，如果要保证一致性，如zookeeper，需要选举leader的过程，并完成数据一致的同步，在这个过程中，zookeeper就是不可用的。一致性和可用性好理解，分布容错性是什么呢？所谓分布式容错性，就是在一个分布式集群中，一个节点崩溃，对整个分布式不会产生影响，又由于分区容错性是一个分布式系统所必须的条件，所以人们往往会在AC之间取舍。

zookeeper和eureka的区别

如上可以知道在zookeeper作为注册中心时，是会在leader选举时，发生集群不可用的情况的，而dubbo中，当zookeeper全部不可用，消费者会使用本地缓存，所以也是可以发现服务的。

而eureka和zookeeper的区别就在于，他没有leader，当一台服务崩坏了会切换到另外一台机器，不会对其他节点造成影响，但是很有可能切换的节点数据不是最新的，因为Eureka不保证高一致性。

eureka保证AP，zookeeper保证CP，这就是两者最大的区别，但是作为注册中心，更重要的显然是可用性。