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

---

一、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

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