服务自愈：解密 Eureka Server 租约过期清理（Eviction）与退避算法

在微服务体系中，服务注册中心负责实时维护所有存活节点的网络地址。当下游服务节点因异常崩溃、物理断电或者 JVM OOM（内存溢出）导致进程瞬间死亡时，它通常无法向注册中心发送注销（Cancel）请求。如果注册中心不能及时剔除这些已死亡的“僵尸节点”，调用端（如 API 网关）就会持续将流量打向故障机器，导致大面积请求报错。

为了实现对死亡节点的自动检测与清理，Spring Cloud Netflix Eureka Server 设计了一套**租约过期自动剔除（Eviction）**机制，并与自我保护机制（Self Preservation）形成互补。

本文将系统拆解 Eureka Server EvictionTask 的定时扫描逻辑、租约过期时间判定计算、以及自保退避算法。

一、 核心生命周期：失效节点自动剔除的三道防线

Eureka Server 清理僵尸节点的过程遵循以下严格的规则和判定条件：

二、 租约过期自动清理任务的流转拓扑

在 Eureka Server 内部，失效清理是由后台单线程定时任务 EvictionTask 驱动的：

      [ Eureka Server 启动 (Bootstrapping) ]
                       │
                       ▼ 1. 开启后台守护线程 (EvictionTask)
       [ 默认每 60 秒运行一次的定时剔除器 ]
                       │
                       ├─ 2. 检查自我保护开关 (isSelfPreservationModeEnabled())
                       │     (自保开启 ──> 3. 放弃本次剔除，退避保护)
                       │
                       ▼ (自保未开启)
       [ 4. 统计所有租约过期失效的实例 (Lease Expired) ]
                       │
                       ├─ 5. 限制单次最大剔除比例为当前存活数的 15%
                       │
                       ▼ 6. 依次执行真实剔除，从内存注册表删除，发布下线事件
       [ 广播同步给 Peer 节点 ──> 7. 客户端下一次拉取时动态更新路由表 ]

三、 代码实战：在生产环境配置敏感、快速的失效剔除

在生产环境的持续滚动发布中，默认的 90 秒租约过期与 60 秒剔除频率过于迟钝，这会导致服务下线后网关仍然导流 1-2 分钟。我们可以配置缩短该周期以实现快速失效：

1. 客户端配置（微服务节点）—— 缩短心跳与续约时间

eureka:
  instance:
    # 1. 客户端发送心跳时间，由默认 30s 缩短为 5s
    lease-renewal-interval-in-seconds: 5
    # 2. 服务端判定心跳超时的租约过期时间，由默认 90s 缩短为 10s
    lease-expiration-duration-in-seconds: 10

2. 服务端配置（Eureka 注册中心）—— 加快失效扫描频率

eureka:
  server:
    # 1. 后台失效剔除任务的扫描周期，由默认 60s 缩短为 5s
    eviction-interval-timer-in-ms: 5000
    # 2. 生产环境建议保持自我保护开启，防范网络波动导致的节点全被误杀
    enable-self-preservation: true

四、 总结

Eureka Server 的租约过期清理（Eviction）与自保退避机制，是实现微服务注册拓扑自愈的核心稳定器。

它通过**基于 EvictionTask 的周期性租约扫描，及时剔除了失去心跳的网络节点，维持了路由表的纯净度；并配合 15% 熔断安全上限和 0.85 自保机制，形成了极强健的双向退避防线**。掌握这套健康剔除逻辑与参数微调方案，是解决滚动发布服务调用超时、进行微服务可用性兜底保障的核心看家本领！