Eureka的自我保护机制 _Eureka

关山初度尘未洗，策马扬鞭再奋蹄！这篇文章主要讲述Eureka的自我保护机制相关的知识，希望能为你提供帮助。
【Eureka的自我保护机制】
目录

前言
1.1 eureka的自我保护机制
- 1.1.1 自我保护开关
- 1.1.2 开发环境配置
2.1 集群搭建

前言首先对Eureka注册中心需要了解的是Eureka各个节点都是平等的，没有ZK中角色的概念，即使N-1个节点挂掉也不会影响其他节点的正常运行。
默认情况下，如果Eureka Server在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，Eureka Server将会移除该实例。但是当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，而微服务本身是正常运行的，此时不应该移除这个微服务，所以引入了自我保护机制。
1.1 eureka的自我保护机制自我保护机制：长时间没有访问、检测不到心跳，或者修改实例名称，eureka启动自我保护机制（好死不如赖活着-哈哈）
即：某一个时刻，某一个微服务不可用了，eureka不会立即清理，依旧会对该微服务的信息进行保存！！！
官方对于自我保护机制的定义：

文章图片

这样做的目的是eureka担心这个服务注册中心是不是死掉了，而做出的一种保护机制。但是当该微服务又重新活过来了之后，Eureka会将之前保存的信息还原到该微服务上。
自我保护机制的工作机制是：如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制，此时会出现以下几种情况：

Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，而不会像ZK那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。

1.1.1 自我保护开关
Eureka自我保护机制，通过配置 eureka.server.enable-self-preservation 来true打开/false禁用自我保护机制，默认打开状态，建议生产环境打开此配置。
1.1.2 开发环境配置
开发环境中如果要实现服务失效能自动移除，只需要修改以下配置。
1、注册中心关闭自我保护机制，修改检查失效服务的时间。

eureka: server: enable-self-preservation: false eviction-interval-timer-in-ms: 3000

2、微服务修改减短服务心跳的时间。

# 默认90秒 lease-expiration-duration-in-seconds:10# 默认30秒 lease-renewal-interval-in-seconds:3

2.1 集群搭建一般我们都不会搭建一个微服务注册实例，而是搭建一个集群，这样就算长时间内某个实例没有相应其他实例可以接着运行，因此按照CAP定理来看，Eureka其实满足AP的但是它不满足CP。它可以保证高可用，但是不能保证一致性。

server: port: 7001eureka: instance: hostname: eureka7001.com #eureka服务端的实例名称 client: register-with-eureka: false#false表示不向注册中心注册自己。 fetch-registry: false#false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务 service-url: #单机 defaultZone: http://$eureka.instance.hostname:$server.port/eureka/#设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址（单机）。 defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/