Spring Cloud中服务治理Eureka是怎么样的

这篇文章将为大家详细讲解有关Spring Cloud中服务治理Eureka是怎么样的，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

一、请说说eureka和zookeeper两个的区別&为什么微服务服务治理选择Eureka,而不是zookeeper？

所谓的CAP原则:C:Consistency一致性  A:Availability可用性 P:Partition tolerance分区容错性

一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡

zookeeper遵守CP

当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对一致性的要求要高于可用性。

但是zookeeper会出现这样一种情况,当 master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。

问题在于,选举leader的时间太长,30~120s,目选举期间整个zookeeper集群都是不可用的,这就导致在选举期间注册服务瘫痪。

在云部署的环境下,因网络问题使得zookeeper 集群失去 master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。

或许这个回答太过于抽象  用一种其他说法来说 就是 ：

当有一个zookeeper挂了,那其他的zookeeper会进行一次选举(强一致性 ： 我一定要保持数据一致性）,而在此选举期间zookeeper是不可用的,而当前 有用户正在使用,用户就不爽了

eureka遵守AP

Eureka:看明白了这一点,因此在设计时就优先保证可用性。

Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。

而Eureka的客户端在向某个Eureka注册时,如果发现连接失败,则会自动切换至其它节点,

只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的不保证强一致性)。

除此之外, Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么 Eurekas就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务

2. Eureka仍然能够接受新服务的注册和査询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)

3.当网络稳定时,当前实例新的注册信息会被同步到其它节点中

因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情況,而不会像 zookeeper那样使整个注册服务瘫痪。

基本原理

服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步。

当消费者调用提供者，则向服务注册中心获取服务提供者地址，然后将服务提供者地址缓存到本地，下次再调用的时候，直接从本地缓存中读取，完成一次调用。

当服务注册中心EurekaServer检测到提供者，由于宕机、网络原因等不可用时，则在服务注册中心将服务置为Down状态，并把当前服务提供者的状态向订阅者发布，订阅过的消费者更新本地缓存。

服务提供者在启动后，周期性(默认30秒)向Eureka Server发送心跳，以证明当前服务时可用状态。Eureka Server在一定时间(默认90秒)未收到客户端的心跳，则认为服务宕机，注销该实例。

总结：选择Eureka作为服务注册中心更好，因为注册服务更重要的是可用性，我们可以接受短时间内达不到一致性的状况。

二、Eureka高可用原理

默认情况下Eureka是让服务注册中心，不注册自己

Eureka高可用实际上将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组相互注册的服务注册中心，从而实现服务清单的互相同步，达到高可用效果。

关于Spring Cloud中服务治理Eureka是怎么样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。