sringcloud2.0学习-6-Eureka自我保护机制

Eureka自我保护机制

Eureka角色

EurekaClient- 注册中心的客户端,之前文章中的member服务,order服务都是属于eureka客户端
EurekaServer-注册中心服务端 之前文章中的eureka注册中心

Eureka自我保护机制演示

  1. 启动springcloud2.0-eureak-server(端口8100)和springcloud2.0-eureak-server2(端口9100)
  2. 启动order服务和两个member服务,member服务做双机集群
    此时注册中心如下:
    sringcloud2.0学习-6-Eureka自我保护机制_第1张图片
  3. 通过order调用member服务,ribbon实现客户端本地负载均衡
    sringcloud2.0学习-6-Eureka自我保护机制_第2张图片
  4. 停掉一个member服务,再去请求
    sringcloud2.0学习-6-Eureka自我保护机制_第3张图片
    此时注册中心仍显示两个member服务
    在这里插入图片描述
    在上面演示中,明明已经停掉了一台服务器,访问也报错,但是注册中心仍然显示两个member服务,这种现象就是Eureak的自我保护机制

Eureak自我保护机制的定义

默认情况下,EurekaClient会定时向EurekaServer端发送心跳,如果EurekaServer在一定时间内没有收到EurekaClient发送的心跳,便会把该实例从注册服务列表中剔除(默认是90秒),但是在短时间内丢失大量的实例心跳,这时候EurekaServer会开启自我保护机制,Eureka不会踢出该服务。

Eureka自我保护机制产生原因

在开发测试时,需要频繁地重启微服务实例,但是我们很少会把eureka server一起重启(因为在开发过程中不会修改eureka注册中心),当一分钟内收到的心跳数大量减少时,会触发该保护机制。可以在eureka管理界面看到Renews threshold和Renews(last min),当后者(最后一分钟收到的心跳数)小于前者(心跳阈值)的时候,触发保护机制,会出现红色的警告:
sringcloud2.0学习-6-Eureka自我保护机制_第4张图片
从警告中可以看到,eureka认为虽然收不到实例的心跳,但它认为实例还是健康的,eureka会保护这些实例,不会把它们从注册表中删掉。
该保护机制的目的是避免网络连接故障,在发生网络故障时,微服务和注册中心之间无法正常通信,但服务本身是健康的,不应该注销该服务,如果eureka因网络故障而把微服务误删了,那即使网络恢复了,该微服务也不会重新注册到eureka server了因为只有在微服务启动的时候才会发起注册请求,后面只会发送心跳和服务列表请求,这样的话,该实例虽然是运行着,但永远不会被其它服务所感知。 所以,eureka server在短时间内丢失过多的客户端心跳时,会进入自我保护模式,该模式下,eureka会保护注册表中的信息,不在注销任何微服务,当网络故障恢复后,eureka会自动退出保护模式。

Eureka自我保护机制的初衷

Eureka自我保护模式可以让Eureka集群更加健壮。

什么情况关闭自我保护

我们在开发测试阶段,需要频繁地重启发布,如果触发了保护机制,则旧的服务实例没有被删除,这时请求有可能跑到旧的实例中,而该实例已经关闭了,这就导致请求错误,影响开发测试。所以,在开发测试阶段,我们可以把自我保护模式关闭

如何关闭自我保护

  • Eureka Server端配置如下:
  server:
    # 测试时关闭自我保护机制,保证不可用服务及时踢出
    enable-self-preservation: false
    ##剔除失效服务间隔
    eviction-interval-timer-in-ms: 2000
  • Eureka Client配置如下:
# 心跳检测检测与续约时间
# 测试时将值设置设置小些,保证服务关闭后注册中心能及时踢出服务
  instance:
###Eureka客户端向服务端发送心跳的时间间隔,单位为秒(客户端告诉服务端自己会按照该规则)  
    lease-renewal-interval-in-seconds: 1
####Eureka服务端在收到最后一次心跳之后等待的时间上限,单位为秒,超过则剔除(客户端告诉服务端按照此规则等待自己)
    lease-expiration-duration-in-seconds: 2    

测试:在eureka两个服务端和三个客户端分别加入对应配置,重启服务,然后去测试不可用的服务能否从注册中心剔除(关闭自我保护机制,一个member服务不可用之后,注册中心有一个判断服务是否不可用的过程,因此需要等待一段时间,服务才会被剔除)sringcloud2.0学习-6-Eureka自我保护机制_第5张图片

Eureka一些概念

  • 服务消费者模式

获取服务
  消费者启动的时候,使用服务别名,会发送一个rest请求到服务注册中心获取对应的服务信息,让后会缓存到本地jvm客户端中,同时客户端每隔30秒从服务器上更新一次。可以通过 fetch-inteval-seconds=30参数进行修以通过eureka.client .registry该参数默认值为30,单位为秒。
服务下线
  在系统运行过程中必然会面临关闭或重启服务的某个实例的情况,在服务关闭期有我们自然不希望客户端会继续调用关闭了的实例。所以在客户端程序中,当服务实例过正常的关闭操作时,它会触发一个服务下线的REST请求给Eureka Server, 告诉服务日中心:“我要下线了”。服务端在接收到请求之后,将该服务状态置为下线(DOWN),井该下线事件传播出去。

  • 服务注册模式

失效剔除
  有些时候,我们的服务实例并不一定会正常下线,可能由于内存溢出、网络故障气因使得服务不能正常工作,而服务注册中心并未收到“服务下线”的请求。为了从服务表中将这些无法提供服务的实例剔除,Eureka Server 在启动的时候会创建一个定时任多默认每隔一一段时间(默认为60秒)将当前清单中超时(默认为90秒)没有续约的服务除出去

服务真实宕机的处理

在服务确实宕机的情况下,开发时需要考虑:接口网络延迟时的接口调用幂等性、本地调用重试机制、服务降级功能等。

代码地址:
springcloud2.0学习代码
本例中使用的项目:
springcloud2.0-eureak-server
springcloud2.0-eureak-server2
springcloud2.0-member
springcloud2.0-order

你可能感兴趣的:(SpringCloud2.0)