我把几个服务实例缩容下线了、本以为流量自然就不会再来,可接下来好几十秒里调用方还在大量报连接被拒绝、请求纷纷失败,我盯着监控纳闷那些实例明明已经停了,最后才想明白实例没了是一回事、调用方什么时候知道它没了是另一回事,这中间隔着一段谁也绕不开的传播延迟

这是一次让我把服务发现这件事,从"实例下线了流量自然就不来了",重新理解成"实例没了和调用方知道它没了之间隔着一段传播延迟、这期间必须靠调用方容错兜底"的事故。我把几个服务实例缩容下线了,本以为流量自然就不会再来。可接下来好几十秒里,调用方还在大量报"连接被拒绝"(connection refused)、请求纷纷失败。我盯着监控纳闷:那些实例明明已经停了啊。最后才想明白:实例没了是一回事、调用方什么时候知道它没了是另一回事,这中间隔着一段谁也绕不开的传播延迟。这篇就把这次"实例下线了、流量还在往死实例上打"的事故,从头到尾复盘一遍。

故障现场:实例都停了,调用方还在往它们上面打

我的服务部署了多个实例,注册在服务注册中心(如 Nacos/Eureka/Consul/K8s Service),调用方通过服务发现拿到实例列表、再负载均衡地把请求分发过去。某次我做缩容,把其中几个实例直接停掉了。我想当然地以为:实例一停,它们就从可用列表里没了,流量自然只会去剩下的健康实例。

可现实是:实例停掉后的好几十秒里,调用方持续报错——大量 connection refused、请求超时、接口成功率掉了一截,然后才慢慢恢复正常。我盯着那些已经停掉的实例的监控,确认它们真的停了,百思不得其解:都停了,怎么流量还往上打? 我查了调用方的日志,发现它请求的目标 IP,正是那几个已经下线的实例。直到我把服务发现的工作机制捋了一遍,才彻底明白根因——"一个实例停了"这个事实,不会在它停掉的那一瞬间,就立刻被所有调用方知道。中间隔着一连串的传播延迟:注册中心通常靠心跳判活,实例停了之后,要等几个心跳周期没收到心跳(超时),注册中心才认定它下线、把它从列表里摘掉;而调用方为了性能,往往还缓存了一份服务实例列表、或本地负载均衡器有自己的刷新周期,即使注册中心摘掉了,调用方也要等下次拉取/推送更新才知道。这几段延迟叠加起来,就是几十秒——在这几十秒里,实例实际上已经没了,但调用方还以为它健康,继续把请求轮询到它的 IP 上,而那个 IP 上已经没有进程在监听了,于是 connection refused。我以为"停掉实例"和"流量不再来"是同一个瞬间发生的事,可它俩之间,横着一道由心跳超时和客户端缓存共同造成的、无法瞬间消除的认知时差。

实例下线后, "它没了" 这个消息传到调用方的链路(每段都有延迟):

  实例停止运行
    ↓ (注册中心要等几个心跳周期没收到心跳才判定下线)  ← 延迟1: 心跳超时
  注册中心把它从实例列表摘除
    ↓ (调用方缓存了实例列表 / LB 有刷新周期)          ← 延迟2: 客户端缓存
  调用方更新本地的实例列表
    ↓
  调用方不再把流量发给它

这几段延迟叠加 = 几十秒。在这期间:
  实例【实际已停】, 但调用方【还以为它健康】, 继续把请求打过去
  → 打到一个没人监听的 IP → connection refused / 超时 / 请求失败

根因: "状态的真相(实例没了)" 和 "各方对状态的认知(以为它还在)"
      之间, 有一段无法瞬间消除的传播延迟。

问题被钉死在这个认知错位上:我以为"停掉一个实例"和"流量不再发给它"是同一时刻发生的,但在分布式服务发现里,"实例没了"这个状态变化,需要经过"心跳超时被注册中心判定下线"和"调用方更新本地缓存的实例列表"这两段传播,才能被调用方感知到;在传播完成之前,调用方手里的实例列表还是旧的,它会继续按这份过时的列表把流量轮询到那个已经死了的实例上。状态的真相(实例停了)和各方对状态的认知(以为它还健康)之间,存在一段由机制决定的、无法瞬间消除的延迟;我没有为这段延迟做任何准备——既没让实例下线前主动通知大家"我要走了",调用方也没有"打到死实例就重试别的"的容错,于是这几十秒的认知时差,就直接表现成了用户可见的请求失败。我以为关了灯房间立刻就黑了,可"灯关了"这个消息传到每个还在看着这间房的人眼里,是需要时间的;在他们反应过来之前,还会朝着那盏已经灭了的灯走过去。

第一件事:想明白状态变化的传播有延迟,要主动通告 + 容错兜底

把这次事故彻底想清楚,关键是理解在分布式系统里,一个节点的状态变化(上线、下线、健康/不健康),不会瞬间被所有依赖它的人知道——这个消息要通过注册中心的健康检查(心跳超时)、再经过调用方的列表缓存刷新,才能传播到每个调用方;这中间的传播延迟(通常几秒到几十秒)是服务发现机制固有的。所以,"我这边把实例停了"绝不等于"所有调用方此刻都知道它停了、不再发流量";在认知追上现实之前,旧流量一定会继续打到已经下线的实例上。

弥合这段"认知时差"造成的伤害,要从两端一起下手:其一,下线方主动通告、优雅下线——实例停止前,先主动向注册中心注销自己(而不是被动等心跳超时),再配合"等待一段时间让在途流量摘除"(如 K8s 的 preStop sleep、就绪探针先转不健康),让流量在它真正停止前就被引走;其二,更关键的是,调用方必须容错——因为传播延迟客观存在、且下线可能是实例崩溃(根本来不及主动注销),调用方不能假设拿到的实例列表 100% 健康,必须有"连不上/调用失败就快速重试列表里的其它实例"的能力,并配合熔断(把连续失败的实例临时标记为不健康、暂时不再发给它)、连接级的主动健康检查、合理的连接超时;其三,可以适当缩短心跳超时和客户端缓存刷新周期,缩小传播延迟的窗口(但缩不到零)。关键认知是:在分布式系统里,任何状态变化从"发生"到"被所有相关方感知"都需要时间,你不能假设状态一变所有人立刻就知道、行为立刻就跟着调整;要弥合这段必然存在的认知时差,既要让状态变化方主动、尽早地通告,更要让依赖方具备容错能力、能优雅地应对"它以为还在、其实已经没了"的对象。

// 正解1: 下线方优雅下线 —— 先主动注销、等流量摘除, 再停
func shutdown() {
    registry.Deregister(self)        // 1) 主动告诉注册中心"我要下线了", 别等心跳超时
    readiness.SetUnhealthy()         // 2) 就绪探针转不健康, LB 不再分新流量
    time.Sleep(15 * time.Second)     // 3) 等在途请求处理完、各方更新列表(认知追上来)
    server.Stop()                    // 4) 再真正停止
}

// 正解2(更关键): 调用方容错 —— 不假设列表里的实例都健康
func call(req Request) (Resp, error) {
    instances := discovery.List("order-svc")  // 拿到的列表可能含已死实例
    for _, inst := range pickWithRetry(instances, 3) {  // 失败就换一个重试
        if breaker.IsOpen(inst) {
            continue                 // 熔断: 跳过最近连续失败的实例
        }
        resp, err := doCall(inst, req, withTimeout(2*time.Second))
        if err == nil {
            breaker.OnSuccess(inst); return resp, nil
        }
        breaker.OnFailure(inst)      // 连不上/失败 -> 记一笔, 连续多次就熔断该实例
        // 自动重试列表里的下一个实例(很可能是健康的)
    }
    return Resp{}, ErrAllInstancesFailed
}

想通这一层,我才明白自己错在哪:我把"停掉实例"当成了一个"所有调用方立刻就会知道并响应"的瞬时事件,而没意识到这个状态变化的传播是有延迟的——在调用方的认知追上现实之前,它还会按旧列表把流量打到死实例上。我既没让实例优雅下线(主动注销、等流量摘除),调用方也没有容错(打到死实例自动重试别的),于是这段必然存在的认知时差,就赤裸裸地变成了用户看到的请求失败。根治之道,是两端配合:下线方主动尽早通告、依赖方具备容错能力。不是假设状态一变大家立刻都知道,而是承认传播有延迟、并让系统能优雅地熬过这段"有人还以为它在、其实它已经没了"的窗口。

第二件事:正解——优雅下线主动注销 + 调用方重试熔断容错

找到根因,正解就清晰了:两端配合弥合传播延迟——下线方优雅下线(停止前先主动向注册中心注销、就绪探针转不健康、等一段时间让在途流量摘除再停),让流量尽早被引走;调用方容错(连不上/调用失败就快速重试列表里的其它实例、用熔断把连续失败的实例临时摘除、配连接超时),让它能优雅应对"列表里还有死实例";再辅以缩短心跳超时和客户端缓存刷新周期、缩小延迟窗口。

# K8s 侧: 优雅下线 —— preStop 先摘流量, 就绪探针配合, 给传播留时间
spec:
  containers:
  - name: app
    lifecycle:
      preStop:
        exec:
          # 收到停止信号先 sleep, 让 endpoint 同步把本 Pod 摘掉, 再让应用退出
          command: ["sh", "-c", "sleep 15"]
    readinessProbe:        # 下线时探针失败, 从 Service endpoint 摘除不再分新流量
      httpGet: { path: /healthz, port: 8080 }
      periodSeconds: 2
  terminationGracePeriodSeconds: 30

// 调用方侧: 重试 + 熔断, 应对列表里可能存在的死实例
type Caller struct {
    disc    Discovery
    breaker *CircuitBreaker      // 记录各实例近期失败, 连续失败就熔断
}

func (c *Caller) Call(svc string, req Request) (Resp, error) {
    list := c.disc.List(svc)               // 可能含尚未剔除的死实例
    tried := 0
    for _, inst := range shuffle(list) {   // 打散避免都先撞同一个死实例
        if c.breaker.IsOpen(inst) {
            continue                       // 已熔断的实例直接跳过
        }
        resp, err := dial(inst, req, 2*time.Second)  // 短连接超时, 快速失败
        if err == nil {
            c.breaker.OnSuccess(inst)
            return resp, nil
        }
        c.breaker.OnFailure(inst)          // connection refused 也算失败, 累计就熔断
        if tried++; tried >= 3 {           // 最多重试 3 个实例
            break
        }
    }
    return Resp{}, fmt.Errorf("all instances failed for %s", svc)
}

这套做法的精髓,是承认"实例状态变化的传播有延迟、调用方手里的列表随时可能含死实例"这个事实,然后两端各尽其责:下线方主动、尽早地把"我要走了"通告出去并等流量摘除,调用方则不盲信列表、用重试和熔断优雅地绕开那些"它以为还在、其实已经没了"的实例。优雅下线缩小了"计划内下线"的伤害;而调用方容错是底线——因为实例还可能是崩溃(来不及注销),传播延迟也永远缩不到零,只有调用方能应对死实例,系统才真正健壮。不是指望状态一变所有人立刻同步,而是让通告尽早、让依赖方能容错地熬过认知时差。

【应对服务发现传播延迟, 我现在认死的几条】

1. 实例下线后, "它没了"传到所有调用方有延迟(心跳超时+客户端缓存)

2. 这期间调用方按旧列表把流量打到死实例 -> connection refused

3. 下线方优雅下线: 主动注销 + 就绪探针转不健康 + 等流量摘除再停

4. 调用方必须容错: 连不上/失败就重试别的实例(底线, 因为还可能是崩溃)

5. 配熔断: 连续失败的实例临时摘除, 别反复撞同一个死实例

6. 配合理连接超时: 让打到死实例快速失败、好快速重试别的

7. 缩短心跳超时/客户端缓存刷新, 缩小延迟窗口(但缩不到零)

第三件事:其他"状态已变、各方认知却没跟上"的同类坑

顺着"真相已经变了、但各方对它的认知有传播延迟、在追上之前按旧认知行事"这条线,我把同类的坑都排查了一遍:

第一个,配置改了但客户端还用旧配置。配置中心改了值,但各实例的本地缓存/长轮询有刷新延迟,改完一段时间内各节点行为不一致(有的新有的旧)。

第二个,DNS 改了解析还连旧 IP。改了域名指向,但各处 DNS 缓存(TTL)没过期,一段时间内还连旧 IP;和服务发现剔除延迟同源。

第三个,缓存失效/数据更新的传播延迟。主库改了数据、缓存还是旧的(或从库还没同步),读到的是过期值,直到失效/同步传播到位。

第四个,多副本/分布式系统的最终一致。一处写了,其它副本要过一会儿才同步到,这期间不同副本读到不同值——本质都是"状态变化的传播需要时间"。

第四件事:下线方做了什么 vs 调用方有没有容错——一张对照表

我把"实例下线的处理方式"和"调用方有无容错"组合起来对比,核心看"认知时差窗口内会不会伤到用户":

看清这张表,优先级就清楚了:优雅下线能缓解"计划内下线"的伤害,但调用方容错才是底线——因为实例还会崩溃(来不及优雅下线)、传播延迟也永远存在,只有调用方能"打到死实例就重试别的",系统在任何下线/崩溃场景下才都不会大面积失败。我这次踩坑,正是下线方直接 kill 不注销 + 调用方无容错这个最差组合。优雅下线是锦上添花,调用方容错是雪中送炭、缺它不可。

第五件事:我曾经对服务下线想当然的几个误区

这次事故也把我对服务发现的一堆"想当然"照了个底朝天:

这些误区的根子是同一个:我默认"状态一变,所有依赖它的人立刻就知道、立刻就调整",而忽略了在分布式系统里,状态变化从"发生"到"被所有相关方感知"之间,有一段必然存在的传播延迟。实例停了是瞬时的,但"实例停了"这个消息传遍所有调用方,需要时间;在这段时间里,各方手里的还是旧认知,会按旧认知继续行事。把"真相变了"等同于"所有人都立刻知道真相变了",而忽略认知传播的延迟,是这类分布式不一致问题的共同根源。

第六件事:做下线/扩缩容、排查"实例停了流量还来"时,我现在的自检习惯

现在每当我做实例下线/扩缩容、或排查"实例都停了调用方还在报连接拒绝",我都会先按这张图问自己:

这张图的精髓,是"实例停了流量还来是服务发现传播延迟;下线方优雅下线缩小窗口、调用方容错(重试别的+熔断)兜底是底线"。设计就下线方优雅下线(主动注销+就绪探针+preStop 等摘流量)、调用方容错(重试别的实例+熔断+连接超时)、缩短心跳和缓存周期、排查就看调用方是不是在往已下线实例的 IP 打、确认是服务发现剔除的传播延迟。这套习惯,让我从"停掉实例就完事"变成了"先想'它没了'多久才传到所有调用方、这期间怎么办"——核心始终是:在分布式系统里一个节点的状态变化(上线、下线、健康/不健康)不会瞬间被所有依赖它的人知道——这个消息要通过注册中心的健康检查(心跳超时:实例停了要等几个心跳周期没收到心跳注册中心才认定下线并从列表摘掉)、再经过调用方的列表缓存刷新(调用方为性能往往缓存了一份实例列表或本地负载均衡器有刷新周期、即使注册中心摘掉了也要等下次拉取/推送更新才知道),这两段传播延迟叠加起来就是几十秒、是服务发现机制固有的;所以"我这边把实例停了"绝不等于"所有调用方此刻都知道它停了不再发流量",在认知追上现实之前调用方还会按手里那份过时的列表把流量轮询到已经死了的实例上(IP 上没进程监听就 connection refused);弥合这段认知时差造成的伤害要从两端一起下手:下线方主动通告优雅下线(停止前先主动向注册中心注销自己而不是被动等心跳超时、就绪探针先转不健康、再等一段时间让在途流量摘除再真正停),更关键的是调用方必须容错——因为传播延迟客观存在且下线还可能是实例崩溃根本来不及主动注销,调用方不能假设拿到的实例列表 100% 健康必须有连不上或调用失败就快速重试列表里其它实例的能力并配熔断(把连续失败的实例临时标记为不健康暂时不再发给它)、合理的连接超时,还可适当缩短心跳超时和客户端缓存刷新周期缩小延迟窗口但缩不到零;一句话,任何状态变化从发生到被所有相关方感知都需要时间不能假设状态一变所有人立刻就知道、要让状态变化方主动尽早通告更要让依赖方具备容错能力优雅应对它以为还在其实已经没了的对象。

我立下的几条规矩

这场"实例下线了流量还往死实例上打"的事故,换来了我做下线/扩缩容时,刻进骨子里的几条铁律:

1. 实例下线后"它没了"传到所有调用方有延迟(心跳超时 + 客户端缓存),几十秒级。
2. 这期间调用方按旧列表把流量打到死实例,connection refused。
3. 下线方优雅下线:主动注销 + 就绪探针转不健康 + 等流量摘除再停。
4. 调用方必须容错:连不上/失败就重试别的实例——这是底线(实例还会崩溃)。
5. 配熔断:连续失败的实例临时摘除,别反复撞同一个死实例。
6. 配合理连接超时:让打到死实例快速失败、好快速重试别的。
7. 缩短心跳超时/客户端缓存刷新周期,缩小延迟窗口(但缩不到零)。

附:我现在做服务下线的"优雅下线 + 调用方容错"骨架

这是我现在做服务下线/扩缩容固定套的骨架——把这次踩坑的教训(下线方优雅下线主动注销、调用方重试+熔断容错)固化成一套结构,让"实例停了流量还往死实例上打"那种坑再不会埋进系统:

// 下线方: 优雅下线流程(stop hook / SIGTERM 里调用)
func gracefulShutdown() {
    registry.Deregister(serviceID)   // 1) 主动注销, 别等心跳超时
    health.SetNotReady()             // 2) 就绪探针转不健康, LB/网关不再分新流量
    time.Sleep(drainWait)            // 3) 等在途请求处理完 + 各方刷新列表(认知追上)
    httpServer.Shutdown(ctx)         // 4) 优雅关闭, 处理完存量再退
}

// 调用方: 带重试 + 熔断 + 超时的健壮调用(应对列表里的死实例)
func (c *Client) Do(ctx context.Context, svc string, req Req) (Resp, error) {
    insts := c.lb.Pick(svc, 3)       // 负载均衡选出最多 3 个候选(已跳过熔断的)
    var lastErr error
    for _, inst := range insts {
        cctx, cancel := context.WithTimeout(ctx, 2*time.Second)  // 连接级超时
        resp, err := c.invoke(cctx, inst, req)
        cancel()
        if err == nil {
            c.breaker.Success(inst)
            return resp, nil
        }
        c.breaker.Fail(inst)         // connection refused 等都算失败, 累计就熔断该实例
        lastErr = err
        // 自动重试下一个候选实例(很可能是健康的)
    }
    return Resp{}, fmt.Errorf("%s all candidates failed: %w", svc, lastErr)
}

// 自检: 演练直接 kill 一个实例(模拟崩溃, 不走优雅下线), 观察调用方成功率
//   健壮的系统: kill 后调用方靠重试+熔断, 成功率几乎不掉

这套骨架把我这次的教训钉死在了结构里:下线方走 优雅下线(主动注销→就绪转不健康→等流量摘除→优雅关闭),缩小计划内下线的伤害;调用方走 重试+熔断+连接超时(连不上就快速失败重试别的候选、连续失败的实例熔断摘除),这是应对死实例的底线;并用 直接 kill 一个实例的演练验证调用方成功率几乎不掉。这样,无论是计划内优雅下线还是实例突然崩溃,调用方都能优雅地绕开那些"它以为还在、其实已经没了"的实例,而不再是当初那个"实例停了、调用方还按旧列表往死实例上猛打几十秒"的局面。把"正视真相与认知的传播时差、让通告尽早+让依赖方容错"这个道理,沉淀成服务下线的固定骨架,这是我对这次"流量打到死实例"最实在的交代——毕竟,你这边关了门,门外的人不会立刻知道,得让他们撞了门也能转身去找还开着的那扇。

写在最后

回头看,这场由"服务发现传播延迟"引发的"流量打到死实例"事故,真正教给我的,远不止"加个优雅下线和重试"这一个技巧。它让我对"'一件事在现实中发生了' 和 '所有相关的人都知道了这件事',从来不是同一个瞬间;一个状态的改变(某物没了、某值变了),需要通过一条条信息通道,花上一段时间,才能传遍每一个依赖它的人;在这段'真相已变、认知未达'的时差里,那些还没收到消息的人,仍会理直气壮地按旧的认知行事——而我们若假设'状态一变,全世界立刻同步',就会被这段必然存在的时差反复绊倒",有了一次刻骨的体会。我栽跟头,是因为我把"实例在我这边停了"等同于了"所有调用方此刻都知道它停了、不会再发流量"——我以为下线是一个所有人同时见证的瞬间;我没意识到,"实例没了"这个事实虽然在它停止的那一刻就成立了,但这个消息要先等注册中心的心跳超时确认、再等每个调用方刷新本地缓存,才能真正抵达每一个会向它发请求的人;在这条消息一站站传播的几十秒里,那些还没收到通知的调用方,手里攥着的还是那份"它还健康"的旧名单,于是它们一如既往地把请求投向一个早已人去楼空的地址,撞上一连串的拒绝。这让我领悟到一个关于"真相与认知的传播时差"的深刻认知:在任何由多个独立部分组成、各自持有一份对世界的认知的系统里(分布式服务、缓存、副本、乃至人的组织),"真相的改变"和"这个改变被所有相关方感知"之间,必然存在一段传播时差——因为信息的传递需要通道、需要时间,不存在"一处改变、处处即刻同步"的免费午餐(强一致要付出极高代价);在这段时差里,系统必然处于一种"不一致"的状态:有的部分已按新真相行事,有的还按旧认知行事;而健壮的系统,不是去假装这段时差不存在、或奢求它瞬间消失,而是正视它、为它设计——一方面让"真相的改变"尽可能主动、尽早地广播出去(缩短时差),另一方面、也是更根本地,让每个依赖方都具备"容错"能力:能优雅地应对"我手里的认知可能已经过时、我依赖的对象可能已经不在"这种常态,而不是盲目信任自己那份随时可能过期的认知。这给了我一种看待"一切'状态改变需要被多方感知'之事"时的清醒:每当一个状态发生改变、而有多方依赖这个状态时,要追问"这个改变传到所有依赖方需要多久?在它们的认知追上来之前,它们会按旧认知做出什么?如果旧认知导致它们去依赖一个已经不在的东西,它们扛得住吗"——既让改变尽早主动广播,更让每个依赖方都不盲信自己的认知、能容错地应对认知与现实的时差;"正视真相与认知的传播时差、让通告尽早+让依赖方容错",是用对服务发现、也是构建一切分布式系统的关键。认清实例下线的传播有延迟、调用方手里的列表可能含死实例、要优雅下线 + 调用方容错——这,是我用一次"实例停了流量还往死实例上打"的事故,换来的、关于架构、也关于如何正视真相与认知之间那段时差的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次缩容、重启、下线实例时,先想一句"'它没了'这消息多久才传到所有调用方?这期间调用方打到它怎么办?",并给调用方配上重试和熔断,那我对着那个"实例都停了、调用方还在报连接拒绝"排查的大半天,就值了。

—— 别看了 · 2026