CAP理论
RuoYiplus 使用Eureka做为注册中心，说到注册中心首先想到的应该是‘’分布式”，分布式系统有个著名的理论—CAP理论【Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）】git
著名的CAP理论指出，一个分布式系统不可能同时知足C(一致性)、A(可用性)和P(分区容错性)。因为分区容错性在是分布式系统中必需要保证的，所以咱们只能在A和C之间进行权衡。Eureka保证的是AP，Zookeeper则保证的是CP。github
- 一致性（C）：在分布式系统中的全部数据备份，在同一时刻是否一样的值。（等同于全部节点访问同一份最新的数据副本）
- 可用性（A）：在集群中一部分节点故障后，集群总体是否还能响应客户端的读写请求。（对数据更新具有高可用性）
- 分区容忍性（P）：以实际效果而言，分区至关于对通讯的时限要求。系统若是不能在时限内达成数据一致性，就意味着发生了分区的状况，必须就当前操做在C和A之间作出选择。 （当分区数据不一致时，要保证系统的正常运行）
Zookeeper(CP)
zk使用的是ZAB协议（Zookeeper 原子广播协议），ZooKeeper它所作的就是确保对数据的修改都会被复制到集合体中超过半数的节点上。若是少于半数的机器出现故障，则最少有一台机器会保存最新的状态，那么这台机器就是咱们的Leader。其他的副本最终也会更新到这个状态。若是 Leader挂了，因为其余机器保存了Leader的副本，那就能够从中选出一台机器做为新的Leader继续提供服务。
从原则上来讲,zookeeper保证了强一致性,但实际上写操做的2pc提交不须要全部的节点都投票经过,而是超过半数的节点投票经过便可,那么有的节点有可能没有第一时间接收到写操做的同步而leader已经经过该写操做,这样的话链接到该节点的服务只能说获得了数据单调一致性的保障,而不是强一致性的保障。可是总的来讲，zookeeper是至关偏向于一致性而非可用性的服务注册与管理中间件，须要注意的是这也会大幅度增长写入数据的性能成本，可是通常状况下做为服务中心写入的数据并很少，还在可接受的范围内。（以上为网上资料）redis
Eureka(AP)
相对于zookeeper，eureka至关偏向于A而非C，便是说一台链接不到集群的eureka节点依然能够对外提供服务,即便提供的数据不必定是最新的,可是在某些状况下总比服务之间宕机要好。spring
在eureka集群中，若是某个节点发生宕机，eureka不会有相似zookeeper选举的行为,即不会对外中止服务。客户端请求会切换到别的eureka节点，当宕机的服务器从新恢复后会被再次加入集群管理中同步别的eureka server保存的注册信息。当网络分割故障发生时，每一个eureka server节点都能继续对外提供服务。后端
eureka server还有心跳机制，默认状况下eureka server一段时间内没有接受服务提供者发送的心跳就会将其剔除，可是也有多是eureka server发生了网络分区故障。若是eureka server在一段时间内丢失了大量心跳，那么会进入自我保护模式，此时有如下行为模式：
一、Eureka Server再也不从注册列表中移除由于长时间没收到心跳而应该过时的服务。
二、Eureka Server仍然可以接受新服务的注册和查询请求，可是不会被同步到其它节点上，保证当前节点依然可用。
三、当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
所以Eureka Server能够很好的应对因网络故障致使部分节点失联的状况，而不会像ZK那样若是有一半不可用的状况会致使整个集群不可用而变成瘫痪。设计模式
eureka client还拥有缓存功能，即便全部的eureka server都不可用，那么client依然可以使用本地缓存链接已缓存的一些服务。 （以上为网上资料）缓存
总结
- Eureka更偏向AP，注重服务的可用性。zk更偏向CP，注重服务的一致性。至于才用那种，须要看具体业务，例如支付相关，相比一致性才是更重要。
- 就做者而言，两种注册中都是使用过，感受来讲。zk太笨重，Eureka轻巧好用。
- 如今的互联网应用，正逐渐全面走向微服务架构，Eureka是spring cloud的一员，相比来讲，将来的扩展前景会更好。
RuoYiPlus开源
本项目由 SMP 多商户权限管理系统 + API 接口服务组成，是在开源项目 RuoYi4.0（若依） 的基础上升级调整的微服务体系，项目基于 SpringBoot2.x，springcloudG 版本 eureka、hystrix、feign、config、gateway 微服务架构，集成 redis、tk.mybatis、lombok、各类设计模式等，是可选性后台管理系统或后端接口服务。服务器
源码地址
- Gitee(主)：https://gitee.com/aimeng2017/RuoYi-plus
- Github(辅)：https://github.com/zebra-ruoyi-plus/ruoyi-plus
加入社区
