Eureka控制台相关介绍及自我保护机制解说

  • Post author:
  • Post category:其他





一、Eureka控制台简介

对于Eureka大家都有所了解,不懂请参考:

https://blog.csdn.net/forezp/article/details/81040925

1.进入Eureka控制台首页,首先看HOME页的头部

【System Status】

  • Environment : 环境,默认为test, 该参数在实际使用过程中,可以不用更改
  • Data center : 数据中心,使用的是默认的是 “MyOwn”
  • Current time:当前的系统时间
  • Uptime : 已经运行了多少时间
  • Lease expiration enabled :是否启用租约过期 , 自我保护机制关闭时,该值默认是true, 自我保护机制开启之后为false。
  • Renews threshold : 每分钟最少续约数
  • Renews (last min) : 最后一分钟的续约数量(不含当前,1分钟更新一次)

2.【DS Replicas】和 【Instances currently registered with Eureka】

  • DS Replicas

    这里表示这个地址是这个Eureka Server相邻节点,互为一个集群
  • Instances currently registered with Eureka

    表示各个微服务注册到这个服务上的实例信息

2.1 系统在三种情况下会出现红色加粗的字体提示:

  • 1.在配置上,自我保护机制关闭


RENEWALS ARE LESSER THAN THE THRESHOLD. THE SELF PRESERVATION MODE IS TURNED OFF.THIS MAY NOT PROTECT INSTANCE EXPIRY IN CASE OF NETWORK/OTHER PROBLEMS.

  • 2.自我保护机制开启了


EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE

NOT BEING EXPIRED JUST TO BE SAFE.

  • 3.在配置上,自我保护机制关闭了,但是一分钟内的续约数没有达到85% , 可能发生了网络分区,会有如下提示


THE SELF PRESERVATION MODE IS TURNED OFF.THIS MAY NOT PROTECT INSTANCE EXPIRY IN CASE OF NETWORK/OTHER PROBLEMS.


3.【General Info】

【General Info】

  • total-avail-memory : 总共可用的内存
  • environment : 环境名称,默认test
  • num-of-cpus : CPU的个数
  • current-memory-usage : 当前已经使用内存的百分比
  • server-uptime : 服务启动时间
  • registered-replicas : 相邻集群复制节点
  • unavailable-replicas :不可用的集群复制节点,如何确定不可用? 主要是server1 向 server2和server3 发送接口查询自身的注册信息,

    如果查询不到,则默认为不可用 , 也就是说如果Eureka Server自身不作为客户端注册到上面去,则相邻节点都会显示为不可用。
  • available-replicas :可用的相邻集群复制节点


4.【Last 1000 since startup】

  • Last 1000 cancelled leases(最后1000个取消的租约)
  • Last 1000 newly registered leases(最后1000个新注册的租约)

    在这里插入图片描述



二、Eureka自我保护机制

默认情况下,如果Eureka Server在一定时间内(默认90秒)没有接收到某个微服务实例的心跳,Eureka Server将会移除该实例。但是当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,而微服务本身是正常运行的,此时不应该移除这个微服务,所以引入了自我保护机制。

  1. 自我保护模式正是一种针对网络异常波动的安全保护措施,使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。

  2. 自我保护机制的工作机制是如果在15分钟内超过85%的客户端节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,Eureka Server自动进入自我保护机制

比如在开发测试时,需要频繁地重启微服务实例,但是我们很少会把eureka server一起重启(因为在开发过程中不会修改eureka注册中心),当一分钟内收到的心跳数大量减少时,会触发该保护机制。可以在eureka管理界面看到Renews threshold和Renews(last min),当后者(最后一分钟收到的心跳数)小于前者(心跳阈值)的时候,触发保护机制,会出现红色的警告:

我们可以看到,eureka认为虽然收不到实例的心跳,但它认为实例还是健康的,eureka会保护这些实例,不会把它们从注册表中删掉。



注意:该保护机制的目的是避免网络连接故障,在发生网络故障时,微服务和注册中心之间无法正常通信,但服务本身是健康的,不应该注销该服务。 如果eureka因网络故障而把微服务误删了,那即使网络恢复了,该微服务也不会重新注册到eureka server了,因为只有在微服务启动的时候才会发起注册请求,后面只会发送心跳和服务列表请求,这样的话,该实例虽然是运行着,但永远不会被其它服务所感知。 所以,eureka server在短时间内丢失过多的客户端心跳时,会进入自我保护模式,该模式下,eureka会保护注册表中的信息,不在注销任何微服务,当网络故障恢复后,eureka会自动退出保护模式。自我保护模式可以让集群更加健壮。


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



eureka.server.enable-self-preservation=false


但在生产环境,不会频繁重启,所以,一定要把自我保护机制打开,否则网络一旦终端,就无法恢复。



版权声明:本文为qq_25112523原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。