Eureka的自我保护机制
本篇要点
- 介绍Eureka的自我保护机制。
- 介绍CAP原则。
- 介绍为什么需要自我保护。
- 介绍如何禁止自我保护机制
Eureka的自我保护
保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护。一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据，也就是不会注销任何微服务。
我们之前在注册之后，强项停止某个微服务，就会出现下面这段红字，此时就代表Eureka已经进入保护模式。
简单来说：如果某个时刻某个微服务不可用了，Eureka不会立即对其进行清理，反而会依旧对该微服务信息进行保存。属于分布式CAP原则的AP分支【可用性和分区容忍性】。
CAP是啥?
直接看看百度百科给出的解释吧：
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
-
一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
-
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
-
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。
为什么会产生Eureka的自我保护机制
默认情况下，如果EurekaServer在一定时间内没有收到某个微服务实例的心跳，EurekaServer将会注销该实例【默认90s】。但是当网络分区故障发生【延时、卡顿、拥挤】时候，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了。
此时微服务本身其实是健康的，本不应该注销这个微服务，Eureka通过自我保护模式来解决这个问题：当EurekaServer节点在短时间内丢失过多客户端时候(可能发生了网络分区故障)，那么这个节点就会进入自我保护模式了。
综上：自我保护模式是一种应对网络异常的安全保护措施，它的涉及哲学就是宁可同时保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。老话反说就是：宁可放过三千，也不错杀一个。自我保护模式让Eureka集群更加健壮稳定。
如何禁止自我保护
自我保护是可配置的，默认是开启的，我们也可以通过配置禁止它，这里演示一下如何禁止。
这一项配置由eureka.client.enable-self-preservation决定，我们让它变为false即可。
eureka.client.server.enable-self-preservation=false # 默认是true的
关闭之后，我们再次启动server7001，访问localhost:7001，出现以下警示：
表明注册中心的自我保护模式已经成功关闭。
为了进行测试，我们使用单机版的Eureka环境，将cloud-eureka-server7001的配置改为如下：
eureka:
instance:
hostname: eureka7001.com #eureka服务端的实例名称
client:
register-with-eureka: false #false表示不向注册中心注册自己。
fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
service-url:
# 设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
server:
#关闭自我保护机制，保证不可用服务被及时踢除
enable-self-preservation: false
# 清理增量队列中过期的频率
eviction-interval-timer-in-ms: 2000
- 关闭自我保护机制
enable-self-preservation。 - 每2秒清理一次失效的服务：
eviction-interval-timer-in-ms。
为了能更快地看到效果，将cloud-provider-payment8001 的配置也进行修改：
eureka:
client:
#表示是否将自己注册进EurekaServer默认为true。
register-with-eureka: true
#是否从EurekaServer抓取已有的注册信息，默认为true。单节点无所谓，集群必须设置为true才能配合ribbon使用负载均衡
fetchRegistry: true
service-url:
#单机版
defaultZone: http://localhost:7001/eureka
instance:
instance-id: payment8001
#访问路径可以显示IP地址
prefer-ip-address: true
#Eureka客户端向服务端发送心跳的时间间隔，单位为秒(默认是30秒)
lease-renewal-interval-in-seconds: 1
#Eureka服务端在收到最后一次心跳后等待时间上限，单位为秒(默认是90秒)，超时将剔除服务
lease-expiration-duration-in-seconds: 2
- 设置Eureka客户端向服务端发送心跳的时间间隔为1s。
- Eureka服务端在收到最后一次心跳后等待时间上限为2s。
接着我们先启动7001，才启动8001：
关闭8001：
此时，测试成功，一旦关闭自我保护模式，只要服务因为各种原因出现通信异常，服务端不会再保存他们的信息，而是选择剔除 。
源码下载
本系列文章为《尚硅谷SpringCloud教程》的学习笔记【版本稍微有些不同，后续遇到bug再做相关说明】，主要做一个长期的记录，为以后学习的同学提供示例，代码同步更新到Gitee：https://gitee.com/tqbx/spring-cloud-learning，并且以标签的形式详细区分每个步骤，这个系列文章也会同步更新。