Eureka的自我保护机制

Posted 2022-01-09 mb61caa1c74a413

目录

• 前言
• 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: 7001

eureka:
  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/