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