第13章 · 负载均衡：算法原理与 gRPC 接入实战（正式版）

写在最前面：这一版和普通讲义有什么不同

这是《内容社区》课程第 13 章，假设你已经跟着前 12 章做到了「微服务能互相找到对方」，但没系统学过负载均衡。

这一版做了四件事：① 先讲"为什么"再讲"怎么做"（负载均衡真正的目的是"把请求发给最合适的节点"）；② 所有新名词当场解释（gRPC、SubConn、Picker、哈希环、虚拟节点、半开恢复……每个都给一句大白话 + 一个生活类比）；③ 每一行代码都能跑（第三节讲原理，第四节从零写出 5 种算法 + 健康检查 + gRPC 接入，每步都有文件路径、运行命令、预期输出）；④ 章末 12 道面试问答，按「基础 4 / 进阶 4 / 追问 4」三档排列。

想要高密度速查版可以看原版第 13 章 ；两版知识点完全一致，只是讲法不同。

一、本章导读

上一章（第 12 章 · 服务注册与发现 ）我们解决了「服务之间怎么找到对方」：服务启动时把地址写进 etcd（一种分布式键值存储，可以理解为微服务们的"公告栏"），调用方从 etcd 拿到一份可用实例名单。

但拿到名单之后，一个更现实的问题立刻冒出来：

名单上有 5 个实例，我这一次请求该发给哪一个？

这就是负载均衡（Load Balance，简称 LB）要解决的问题。

很多人对负载均衡的印象停留在"轮询一下就行"，但真实生产环境远比这复杂：

• 有的机器是 16 核，有的是 4 核——平均分流量会让 4 核的那台先挂
• 有的请求希望每次都落到同一台机器上（因为那台机器的本地缓存里有这个用户的数据）
• 有的机器正在慢慢变慢甚至已经半死不活——继续把请求发给它就是雪上加霜
• 节点随时会上线、下线、扩缩容——你的分发规则不能一改机器就乱套

本章的路线是：先建立"目的感"（第一节），再讲静态算法（轮询 → 加权轮询 → 平滑加权轮询 → 随机 → 哈希 → 一致性哈希），再讲动态算法（最少连接 / 最少活跃 / 最快响应），然后落地到 gRPC（第四节接入实战），最后补上"调用失败怎么办"的 Failover。

其中有两个知识点是本章的硬骨头，也是面试高频：

• 平滑加权轮询：Nginx 的默认算法，面试要求手写。它解决的是"权重高的节点被连续打爆"这个扎堆问题。
• 一致性哈希：缓存、分库分表、消息队列分区背后共用的同一套算法。它解决的是"增加一台机器，导致 90% 的缓存全部失效"这个灾难。

另外还有一个反直觉的事实必须提前剧透：gRPC 默认根本不做负载均衡。它的默认策略叫 pick_first——永远选名单里的第一个节点，后端起了 10 个实例，请求也只会打到第 1 个。无数新手（包括很多工作两三年的工程师）在这里踩过坑：明明起了 3 个实例，监控上却只有 1 个有流量。这个点我们会在 3.4 节重点讲。

学完本章，你不仅能手写这几种算法，还能把它们真正接进 gRPC，让项目里的 post-service 调用 user-service 时实现真正的流量分发。

下一章（第 14 章）我们进入服务治理，把熔断 / 限流 / 降级这套「防雪崩」的组合拳打明白——本章第 6 步写的健康检查，其实就是熔断器的雏形。

开读前先看一眼全局：注册发现解决了"服务在哪"，本章解决"发给谁"。核心是一张策略选择图：随机 / 轮询追求均匀，一致性哈希追求"同一个 key 总落到同一台"，而健康检查负责把坏节点从候选名单里踢出去。

flowchart LR
    A["调用方拿到实例列表"] --> B{"选择负载均衡策略"}
    B -->|"随机 / 轮询 / 加权"| C["请求均匀分散"]
    B -->|"一致性哈希"| D["同一 key 固定路由
扩缩容只移动一小段"]
    C --> E{"健康检查"}
    D --> E
    E -->|"通过"| F["发往目标实例"]
    E -->|"失败"| G["剔除坏节点
请求换到别的实例"]

这张图怎么读：请求从「调用方拿到实例列表」进入「选择负载均衡策略」菱形，分两条路线——走「随机 / 轮询 / 加权」这条边，请求被均匀分散到各实例；走「一致性哈希」这条边，同一个 key 固定路由到同一实例，扩缩容时只移动一小段数据。两条路线最后都要过「健康检查」这道闸：通过才「发往目标实例」；失败则落入右下角的兜底分支——把坏节点从候选里剔除，请求换到别的实例重发。

二、本章知识点大纲

先把这张地图看一遍，知道这一章要往哪走、走到哪算够。

必会（学完必须能独立写出来）

1. 手写一个平滑加权轮询（Smooth WRR），并能手推出 A:B:C = 5:1:1 时连续 7 次的序列是 A A B A C A A。
2. 手写一个一致性哈希环（含虚拟节点 + 二分查找），并写单测验证「同一个 key 永远落在同一个节点」。
3. 用 WithDefaultServiceConfig 把 gRPC 默认的 pick_first 换成 round_robin，并解释为什么要这么配。
4. 实现 gRPC 的 PickerBuilder + Picker 两个接口，把自定义算法注册成一个新的负载均衡策略。
5. 写出一个「连续 3 次失败剔除、10 秒后半开放一个试探请求」的健康检查状态机。

理解（能讲清原理和取舍，不要求背代码）

1. 为什么说「负载均衡是手段不是目的」——真正的目的是选出"最适合"处理这个请求的节点。
2. 客户端负载均衡与服务端负载均衡的差异，以及为什么微服务时代客户端 LB 成了主流。
3. 静态算法（轮询/随机/哈希）与动态算法（最少连接/最少活跃/最快响应）的分界：前者靠统计学，后者靠指标。
4. 动态算法的固有局限：客户端只能看到自己这一侧的指标，看不到服务端真实 CPU / 内存。
5. Failover 的本质是「重试 + 负载均衡」，以及为什么重试必须配超时和退避（重试放大效应）。

了解（知道有这回事，面试能说出名字和一句话定位）

1. gRPC 内置 balancer 一览：roundrobin / weightedroundrobin / grpclb / leastrequest / rls，以及"除了前两个其他基本不用"的结论。
2. 主流框架的 LB 方案：Kratos 的 Selector（默认平滑 WRR）、go-zero 的 P2C（随机挑两个再选负载低的）。
3. gRPC 更顶级的 balancer.Balancer 接口与 Picker 的分工——99% 的场景只需要写 Picker。

前置依赖与补课清单

不需要你提前懂的：Nginx 配置、K8s Service、Istio / Service Mesh、Envoy。本章只讲「代码层面怎么把请求分发出去」。

预计时长与学习成果

• 预计时长：4 小时（精读 + 跟着敲完全部代码）；如果只求原理主干，1.5 小时可过一遍。

• 学完你能跑出来的东西（这是本章的验收标准，做到才算过关）：

  一个 pkg/balancer 包：内含轮询、平滑加权轮询、随机、最少连接、一致性哈希 5 种算法 + 一个健康检查器，全部实现统一的 Balancer 接口；其中平滑加权轮询和一致性哈希各有单测；最后注册成 gRPC 的 weighted_round_robin 和 consistent_hash 两个策略，起两个实例实测「权重 5:1 时 7 次请求分布为 5/2 且不连续命中」与「同一个 user_id 永远落同一台」。跑 go test ./pkg/balancer/... -v 全绿。

flowchart LR
    A["3.1 目的与客户端/服务端 LB"] --> B["3.2 静态算法
轮询→加权→平滑WRR→随机→哈希"]
    B --> C["3.3 动态算法
最少连接/活跃/最快响应"]
    C --> D["3.4 gRPC 接入
pick_first→round_robin→自定义 Picker"]
    D --> E["3.5 Failover
重试+LB+Done 调权重"]
    E --> F["3.6 框架方案与面试亮点"]
    F --> G["第四节 跟着写
6 步落地 pkg/balancer"]
    G --> H["第七节 面试问答 12 题"]

这张图怎么读：主线从「3.1 目的与客户端/服务端 LB」出发，先过静态算法（3.2：轮询→加权→平滑 WRR→随机→哈希），再过动态算法（3.3），然后到本章落点——gRPC 接入（3.4：pick_first→round_robin→自定义 Picker），接着补上失败兜底 Failover（3.5）与框架方案（3.6）；之后转入「第四节 跟着写」的 6 步落地，最后以 12 道面试问答收口。每条边就是「读完上一节再读下一节」的线性顺序，没有分支。

三、正文

3.0 补课：上一章我们做到哪了

在进入新内容之前，先用两分钟对齐一下"你现在手上有什么"，否则后面的代码会像凭空冒出来。

补课胶囊 · 服务注册与发现（etcd + Resolver） 一句话：服务启动时把"我是谁、我在哪"写到公告栏（etcd）上，调用方去公告栏抄一份名单回来。 类比：开分店。每家新店开张就去工商局的公告栏贴一张纸条「xx 分店，地址 A，电话 1」；总店要找分店时，去看公告栏抄一份完整名单；分店关门了，纸条会自动过期消失（靠"租约/心跳"机制——纸条有有效期，分店要不停地续期，续不上就自动撕掉）。 最小示例：第 12 章结束时，你的项目里已经有这样一个结构（本章会直接复用它）：

// pkg/registry/registry.go（第 12 章已存在，本章直接复用）
package registry

// ServiceInstance 是一个服务实例的完整信息
type ServiceInstance struct {
    InstanceID string // 实例唯一 ID，如 "user-service-7f3a"
    Name       string // 服务名，如 "user-service"
    Address    string // 地址，如 "127.0.0.1"
    Port       int    // 端口，如 9090
    Weight     int    // 权重，本章的主角之一
}

// Addr 返回 "ip:port" 形式的地址
func (s *ServiceInstance) Addr() string {
    return net.JoinHostPort(s.Address, strconv.Itoa(s.Port))
}

回到主线：注意那个 Weight 字段——它就是为本章准备的。上一章我们注册时顺手把它写进了 etcd，但一直没用到。本章的加权算法会把它真正用起来。

上一章我们做的 Resolver（解析器）是 gRPC 的一个扩展点，它的职责只有一件事：把服务名（如 user-service）翻译成一串地址（如 ["127.0.0.1:9090", "127.0.0.1:9091"]），并在地址变化时通知 gRPC。

3.1 核心概念：负载均衡到底在解决什么问题

先抛问题

假设你的 user-service 起了 3 个实例，名单拿到了：

127.0.0.1:9090  （16 核 32 G，刚启动，闲得发慌）
127.0.0.1:9091  （4 核 8 G，已经跑了三天，内存快满了）
127.0.0.1:9092  （16 核 32 G，但磁盘 IO 正在打满）

现在来了 100 个请求。如果随便发，会发生什么？

• 全发给 9091 → 4 核机器先挂，剩下的流量再压垮另外两台，最后全站雪崩（这就是级联故障）
• 平均分给三台 → 9091 还是先挂，因为它只有 4 核
• 全都发给 9090 → 9090 迟早也挂，另外两台在旁边看戏

所以核心问题不是"怎么平均分"，而是：

怎么把每一个请求，都送到"当下最合适处理它"的那台机器上？

给个直觉：超市收银台

补课胶囊 · 负载均衡（Load Balance，LB） 一句话：从一堆能干同样活的节点里，挑一个最合适的来干活。 类比：超市的收银台排队。周末超市开了 5 个收银台，你推着满满一车东西走进去——

• 如果由超市广播安排：“下一位顾客请到 3 号台”，顾客只需要听话照做 → 这就是服务端负载均衡（有个集中的调度者）
• 如果每个顾客自己看“哪个队最短、哪个收银员手脚最快"然后自己走过去 → 这就是客户端负载均衡（每个调用方自己算）

一个好的人工引导员不会机械地喊"1 号、2 号、3 号、4 号、5 号"轮着来。他会看：3 号台那位顾客买了一整车（大请求），先别排给他；5 号台的收银员是新来的动作慢，少排点；2 号台刚有个顾客在闹退货（这台机器在报错），暂时别排。

回到主线：这个"引导员"就是负载均衡器。它的 KPI 是让整个超市的结账效率最高，而不是"必须每个台轮到一样多的顾客”。

3.1.1 负载均衡是手段，不是目的

这是本章第一句要背下来的话：

负载均衡只是手段，真正的目的是把请求转发给"最适合"处理它的节点。

什么叫"最适合"？举几个例子你就懂了：

3.1.2 负载均衡是一个"简化模型”

现在问题来了：“最适合"这个词太主观了，怎么让机器判断？

工程上的做法是建立一个简化模型：

我们认为：负载最轻的节点，就是最适合的节点。

这个简化带来两个推论：

1. 既然所有节点提供的服务是等价的，那么每次都选负载最轻的，长此以往所有节点的负载会大致均衡——“均衡"是结果，不是目标。
2. 于是"选最合适的节点"这个复杂问题，被简化成了”量化负载，选最小的那个“这个可计算的问题。

flowchart LR
    R[用户请求] --> LB{负载均衡器}
    LB -->|选负载最轻| N1[节点 A
内存空闲 负载 20]
    LB -->|选负载最轻| N2[节点 B
内存吃紧 负载 85]
    LB -->|选负载最轻| N3[节点 C
CPU 空闲 负载 15]
    N3 -.->|"√ 选中"| OK[返回响应]

用一句话总结这个模型：

目的：选最适合处理请求的节点
  ↓ 简化
标准：选负载最轻的节点
  ↓ 副作用（不是目标）
结果：所有节点负载大致均衡

3.1.3 客户端负载均衡 vs 服务端负载均衡

这是面试必考的对比题。先给结论，再讲为什么。

flowchart TB
    subgraph S1["服务端 LB：多一跳，LB 是集中决策点"]
        C1[客户端 A] --> SLB[Nginx / LVS
独立部署]
        C2[客户端 B] --> SLB
        SLB --> X1[实例 1]
        SLB --> X2[实例 2]
        SLB --> X3[实例 3]
    end
    subgraph S2["客户端 LB：直连，每个客户端自己决策"]
        CL1[客户端 A
内置 LB] --> Y1[实例 1]
        CL2[客户端 B
内置 LB] --> Y2[实例 2]
        CL1 --> Y2
        CL2 --> Y1
        CL1 --> Y3[实例 3]
    end

为什么微服务时代客户端 LB 成了主流？ 三个理由：

1. 少一跳网络。微服务之间调用量是天文数字（一个外部请求可能扇出几十次内部调用），每一次都绕一层 Nginx，延迟和带宽成本都扛不住。
2. 没有单点瓶颈。服务端 LB 要处理所有流量，必须堆机器、做高可用；客户端 LB 的计算分散在每个调用方进程里，加机器就自动加算力。
3. 和注册中心天然配合。微服务实例变化频繁（扩缩容、发布、故障重启），客户端 LB 直接用注册中心推过来的实时名单，服务端 LB 还得自己再对接一遍注册中心。

用户浏览器
   ↓
云 SLB / Nginx（服务端 LB：把外部流量分给网关集群）
   ↓
API Gateway
   ↓  ← 从这里开始进入内网微服务世界
gRPC 客户端 LB（客户端 LB：网关直接连到后端的 N 个实例）
   ↓
user-service 实例 1 / 2 / 3

小收口：这一节我们建立了一个认知框架——负载均衡目的是选最合适的节点，手段是量化"负载"并选最轻的，落地方式分服务端 LB 和客户端 LB 两种。本章后续全部代码都是客户端 LB（跑在 gRPC 调用方进程里）。

3.2 静态负载均衡算法

先抛问题

上一节说了，要想选出"负载最轻"的节点，就得先量化负载。但现实很骨感：

• 你在客户端，你怎么知道服务端那台机器的 CPU 是多少？内存还剩多少？
• 就算服务端愿意告诉你，那也要一次额外的网络交互——为了选节点先问一圈，这开销比请求本身还大。

于是就有了静态算法的思路：

既然算不准真实负载，那我就不算了。我用一套固定的规则分发，请求量足够大时，按统计学规律自然就均衡了。

用大白话说就是"摆烂”——但这个摆烂在 90% 的场景下都够用，而且实现简单、无状态、性能极好。

静态算法全家福（本章会逐一实现）：

补课胶囊 · 会话保持（Session Stickiness / Session Affinity） 一句话：同一个用户的请求，尽量每次都落到同一台机器上。 类比：你常去的那家理发店，每次都找同一个 Tony 老师——他记得你的发型偏好（本地缓存），不用每次重新沟通。如果每次去都换个陌生老师，体验会差很多。 为什么需要：节点上可能有本地缓存（进程内缓存，如 Go 的 sync.Map 或 bigcache）。如果同一个用户的请求每次落到不同节点，每个节点都要各自缓存一份同样的数据，缓存命中率暴跌、内存翻倍。 回到主线：轮询和随机没有会话保持；哈希类算法有。这是选型时的重要分水岭。

3.2.1 轮询（Round Robin）

先抛问题

最简单也最常用的算法。候选节点列表 [A, B, C]，请求依次落到 A → B → C → A → B → C → …

它成立依赖于两个隐含假设：

假设 2 是轮询最大的软肋：某个节点恰好收到一个大请求（比如导出全表），它就被打爆了，而另外两台闲着。所以它只能保证"请求数均衡"，保证不了"负载均衡"。

给个直觉

flowchart LR
    Q[请求流] --> RR["轮询计数器
counter++"]
    RR -->|第 1 个| A[节点 A]
    RR -->|第 2 个| B[节点 B]
    RR -->|第 3 个| C[节点 C]
    RR -->|第 4 个| A
    RR -->|第 5 个| B

就像打牌轮流发牌：牌（请求）一张一张按顺序发给每个人（节点），发完一轮从头再来。

最小可运行示例

新建一个临时目录试跑（不影响项目）：

// 文件路径: ~/code/lb-demo/main.go
package main

import (
	"fmt"
	"sync/atomic"
)

// RoundRobin 最简轮询实现：原子自增 + 取模
type RoundRobin struct {
	nodes   []string
	counter uint64
}

// Pick 挑出一个节点
func (r *RoundRobin) Pick() string {
	// 步骤 1：原子加 1，避免多个 goroutine 同时 Pick 时计数错乱
	n := atomic.AddUint64(&r.counter, 1)
	// 步骤 2：减 1 后取模，映射到节点下标（这样第一次拿到的是下标 0）
	idx := (n - 1) % uint64(len(r.nodes))
	// 步骤 3：返回对应节点
	return r.nodes[idx]
}

func main() {
	r := &RoundRobin{nodes: []string{"A", "B", "C"}}
	for i := 0; i < 7; i++ {
		fmt.Printf("第 %d 个请求 -> %s\n", i+1, r.Pick())
	}
}

运行：

cd ~/code/lb-demo && go run main.go

预期输出：

第 1 个请求 -> A
第 2 个请求 -> B
第 3 个请求 -> C
第 4 个请求 -> A
第 5 个请求 -> B
第 6 个请求 -> C
第 7 个请求 -> A

逐行讲解

补课胶囊 · 原子操作（sync/atomic） 一句话：一条 CPU 指令就能完成、不会被其他 goroutine 打断的操作。 类比：超市的取号机。你按一下，号码必然加一，绝不会出现两个人拿到同一个号——因为"读号码 + 加一 + 写回"这三步在硬件层面是一个不可分割的整体。而手写 counter++ 就像两个人同时伸手去翻纸质号码本，可能都看到"38"、都写成"39"。 最小示例：

var n int64
atomic.AddInt64(&n, 1)      // 原子 +1，返回新值
atomic.LoadInt64(&n)        // 原子读取
atomic.CompareAndSwapInt64(&n, 1, 2) // CAS：如果当前是 1 就改成 2

回到主线：轮询只需要一个"安全的自增"，用 atomic 比用 sync.Mutex 加锁快一个数量级（无锁），这是 LB 这种高频调用场景的标准做法。

常见坑

n := atomic.AddUint64(&r.counter, 1)
idx := n % uint64(len(r.nodes)) // ← 忘了减 1

小收口：轮询是最简单、性能最好的静态算法，“遇事不决用轮询"是业界公认的经验。但它的两个隐含假设（节点同能力、请求同消耗）在现实中经常不成立——这正是后面"加权"和"动态"两条路线的出发点。

3.2.2 加权轮询（Weighted Round Robin）

先抛问题

轮询的第一个假设"所有服务器处理能力相同"不成立时怎么办？

答：给节点加权重。 权重通常代表节点的处理能力（CPU 核数、内存大小、压测出来的 QPS 上限），也有可能代表重要性或优先级。

补课胶囊 · 权重（Weight） 一句话：一个数字，表示"这个节点应该分到多少比例的流量”。 类比：切蛋糕。三个人的食量比是 5:1:1，那就把蛋糕切成 7 份，第一个人拿 5 份，后两个各拿 1 份——按比例分，而不是平均分成三份。 权重从哪来：通常是服务端自己声明的。服务启动时把自己的权重写进注册中心（etcd），客户端做服务发现时从注册信息里读出来。第 12 章我们已经在 ServiceInstance 里留好了 Weight 字段，就是为了这一刻。 另一种用法（较少见但很实用）：在多机房 / 异地多活部署时，给同机房、同城的节点设置高权重，跨机房节点设置低权重——这样请求会优先"就近"访问低延迟节点，跨机房节点只做兜底（比如同城机房全挂时才顶上）。这招叫就近访问 / 区域感知路由。

普通加权轮询怎么做，以及它的致命缺陷

最朴素的做法：把权重展开成一个更长的列表，然后对这个长列表做普通轮询。

比如 A:B:C = 1:2:3，展开成 [A, B, B, C, C, C]，然后对这个 6 元素列表轮询：

请求序列：A → B → B → C → C → C → A → B → B → C → C → C → …

流量比例是对的（A 占 1/6，B 占 2/6，C 占 3/6），但你看出来了问题吗？

小收口

加权轮询解决了"节点能力不同"的问题，但流量比例对了，分布节奏不对——高权重节点会被连续打爆。下一节的平滑加权轮询，就是要做到「比例不变，但高权重的请求被打散开」。

3.2.3 平滑加权轮询（Smooth WRR）—— 本章第一个硬骨头

这是 Nginx 的默认负载均衡算法，gRPC、Kratos、go-zero 都有实现。面试要求手写。如果本章你只记住一个算法，请记住这个。

先抛问题

我们希望：A:B:C = 5:1:1 时，7 个请求里 A 拿 5 个、B 拿 1 个、C 拿 1 个——但 A 的这 5 个不能连在一起，要像撒芝麻一样均匀撒开。

朴素加权轮询给出的是：A A A A A B C（A 连着 5 个，扎堆） 平滑加权轮询给出的是：A A B A C A A（A 的 5 个被打散了）

看出来了吗？比例完全一样，但节奏完全不同。

给个直觉：欠账与还债

算法的想法非常朴素，可以用"欠账"来理解：

每个节点有一个"当前权重"（currentWeight）。每次挑选时，所有节点的 currentWeight 先各自加上自己的 weight（相当于"攒分"），然后谁的分最高谁上。上完之后，这个赢家要扣掉所有人的总分（相当于"还债"）。

因为它扣了一大笔（总分），接下来几轮它的分追不上别人，别人就有机会上场。等它慢慢把债还清，分重新涨回最高，它又能上场了。

这个"先攒分、谁高谁上、上了就还债"的循环，天然就把高权重节点的请求打散了。

算法四步

严谨表述（这四步就是面试手写的骨架，背下来）：

1. 计算所有节点初始权重的和 totalWeight
2. 每个节点的 currentWeight += weight（攒分）
3. 选出 currentWeight 最大的节点
4. 选中节点的 currentWeight -= totalWeight（还债），返回它

flowchart TD
    S[开始 Pick] --> T["① 每个节点 currentWeight += weight
同时累加 totalWeight"]
    T --> M["② 选 currentWeight 最大的节点"]
    M --> D["③ 选中节点 currentWeight -= totalWeight"]
    D --> R["④ 返回该节点"]
    R --> S

手推一遍：A:B:C = 5:1:1，连续 7 次

这是本节最重要的一张表。请拿出纸笔跟着算一遍——算完你就能默写了。totalWeight = 5+1+1 = 7，初始 currentWeight 全为 0。

7 次结果：A A B A C A A —— A 恰好 5 次、B 1 次、C 1 次，而且 A 的 5 次被打散了，最长连续只有 2 次（开头和结尾）。

注意第 7 次结束后状态回到 0, 0, 0，与初始状态完全一致——这说明算法以 7 次为一个周期循环。这不是巧合：只要权重是整数，算法必然在 totalWeight 次调用后回到初始状态。这是一个可证明的数学性质，也是它能被形式化验证的原因。

代码实现

package wrr

import "sync"

// WeightNode 是平滑加权轮询中的一个节点
type WeightNode struct {
	Node          string // 节点标识（如 "127.0.0.1:9090"）
	Weight        int64  // 初始权重（也叫有效权重），构造后不再变化
	CurrentWeight int64  // 当前权重，每次 Pick 都会变化
}

// SmoothWRR 平滑加权轮询（Nginx 同款算法）
type SmoothWRR struct {
	mu    sync.Mutex
	nodes []*WeightNode
}

func NewSmoothWRR(nodes []*WeightNode) *SmoothWRR {
	return &SmoothWRR{nodes: nodes}
}

// Pick 挑选一个节点
func (w *SmoothWRR) Pick() string {
	w.mu.Lock()
	defer w.mu.Unlock()

	// 步骤 1：计算总权重，同时让每个节点的 currentWeight += weight
	var total int64
	for _, n := range w.nodes {
		total += n.Weight
		n.CurrentWeight += n.Weight
	}

	// 步骤 2：找到 currentWeight 最大的节点（严格大于，打平时保留先遍历到的）
	max := w.nodes[0]
	for _, n := range w.nodes[1:] {
		if n.CurrentWeight > max.CurrentWeight {
			max = n
		}
	}

	// 步骤 3：选中节点"还债"，扣掉总权重
	max.CurrentWeight -= total
	return max.Node
}

逐行讲解

常见坑

小收口：平滑加权轮询 =「攒分 → 选最大 → 还债」三步循环。它用 O(n) 的遍历换来了"比例精确 + 分布平滑"，是工程上最常用的加权算法。至此，静态算法里"轮询家族"讲完了，接下来是"随机家族"和"哈希家族"。

3.2.4 随机与加权随机

先抛问题

轮询需要维护一个计数器，还要处理并发安全。有没有更简单的办法，同样能达到"请求量大时自然均衡"的效果？

有——随机。每次请求随机挑一个节点，请求量足够大时，按大数定律（样本量越大，实际频率越接近理论概率），分布自然趋于均匀。

给个直觉

轮询 vs 随机的类比：

• 轮询 = 老师点名回答问题，按座位号依次数下去，保证每个人被点到的次数精确相等。
• 随机 = 抽奖箱摸球，摸完放回去。短期内可能连着摸到同一个人，但摸一万次之后，每个人被摸到的次数几乎相等。

随机牺牲了"短期精确性"，换来了零状态（不需要计数器，也就没有并发问题）。

代码实现：随机

// Random 随机负载均衡
type Random struct {
	nodes []string
}

func (r *Random) Pick() string {
	// 随机数对节点数取模，得到 [0, len) 的下标
	return r.nodes[rand.Intn(len(r.nodes))]
}

加权随机：把权重画成"区间"

普通随机假设所有节点能力相同。加权随机怎么做？

思路：把权重换成一条数轴上的区间长度，然后随机往数轴上扔一个点，落在谁的区间就选谁。

比如 A:B:C = 5:1:1，总权重 7，那么：

数轴：0        5    6    7
      |--------|----|----|
        A 区间    B     C
       （长度5） （1）  （1）

随机生成一个 [0, 7) 的数：落在 [0,5) 选 A，[5,6) 选 B，[6,7) 选 C。因为 A 的区间占了 5/7 的长度，所以 A 被选中的概率就是 5/7。

flowchart LR
    R["随机数 r ∈ [0, 7)"] --> C1{"r < 5 ?"}
    C1 -->|是| A["选 A（概率 5/7）"]
    C1 -->|否| C2{"r < 6 ?"}
    C2 -->|是| B["选 B（概率 1/7）"]
    C2 -->|否| C["选 C（概率 1/7）"]

// WeightedRandom 加权随机
type WeightedRandom struct {
	nodes   []string
	weights []int64 // 与 nodes 一一对应的权重
	total   int64   // 总权重
}

func (w *WeightedRandom) Pick() string {
	// 步骤 1：生成 [0, total) 的随机数
	r := rand.Int63n(w.total)
	// 步骤 2：累加权重，看 r 落进谁的区间
	var sum int64
	for i, weight := range w.weights {
		sum += weight
		if r < sum { // 首次满足说明 r 落在第 i 个区间内
			return w.nodes[i]
		}
	}
	// 步骤 3：理论上不会走到这里（r < total 必然落在某个区间），兜底返回最后一个
	return w.nodes[len(w.nodes)-1]
}

逐行讲解

为什么加权随机没有"平滑版"？

因为它本身就是随机的。 平滑加权轮询要解决的问题是"高权重节点被连续命中"——而随机算法里，连续命中同一节点的概率本来就只有 (5/7)² ≈ 51%（两次）、(5/7)⁵ ≈ 18.6%（五次），天然就是散的，没必要再平滑。

小收口：随机家族（随机、加权随机）用"零状态"换来了简单和高性能，代价是短期内分布不精确。接下来是静态算法里最有价值的"哈希家族"。

3.2.5 哈希与一致性哈希 —— 本章第二个硬骨头

先抛问题

前面所有算法都有一个共同点：同一个用户的两次请求，可能落到不同节点。

这在大多数场景没问题，但有两种场景会出事：

场景一：节点上有本地缓存

请求 1（user_id=42）→ 节点 A → 缓存未命中，查库，把 user 42 写进 A 的本地缓存
请求 2（user_id=42）→ 节点 B → 缓存未命中，查库，把 user 42 写进 B 的本地缓存
请求 3（user_id=42）→ 节点 C → 缓存未命中，查库，把 user 42 写进 C 的本地缓存

3 个节点各缓存一份完全相同的数据：缓存命中率只有 1/3，内存却花了 3 倍。

场景二：有状态的业务逻辑

比如一个"分步提交"的流程（第一步填基本信息、第二步上传材料、第三步确认），中间状态暂存在节点的内存里。如果第二步跳到了另一个节点，它会说"你谁啊？没见过你的第一步数据"。

解决办法：让同一个 key 的请求，永远落到同一个节点。这就是哈希类算法。

给个直觉：班级分学习小组

类比：老师要分学习小组，规则是"按学号的尾号分组"——学号尾号 0-2 去第一组，3-5 去第二组，6-9 去第三组。

这个规则的好处是：只要学号不变，你永远在同一个组。不用问老师，自己算一下就知道去哪。

但如果突然从 3 个组变成 4 个组，规则就变成"尾号 0-1 第一组、2-4 第二组……"——几乎所有人的组都变了，大家刚和组员混熟，全打散了。

这就是普通哈希的痛点。一致性哈希要解决的就是：组数变化时，只让尽可能少的人换组。

补课：哈希函数是什么

补课胶囊 · 哈希函数（Hash Function） 一句话：把任意长度的输入，变成固定长度的数字（哈希值）。同样的输入永远得到同样的输出。 类比：榨汁机。不管你放进去的是苹果、西瓜还是榴莲（任意输入），出来都是一杯固定容量的果汁（固定长度输出）。而且同一个水果每次榨出的汁完全一样（确定性），但你没法从果汁反推出原来是什么水果（不可逆）。 最小示例：

import "hash/crc32"

h := crc32.ChecksumIEEE([]byte("user:42"))
fmt.Println(h)          // 输出一个 uint32，如 3735928559
fmt.Println(h % 3)      // 对 3 取模，得到 0/1/2 —— 这就是节点下标

回到主线：本章用 crc32.ChecksumIEEE，因为它快且够用。生产环境一致性哈希也常用 FNV、MurmurHash3（分布更均匀）。哈希函数的选择只影响"均匀程度"，不影响算法原理。

普通哈希：取模

最简单粗暴的哈希负载均衡：把 key 算成哈希值，对节点数取模。

// Hash 简单哈希负载均衡
type Hash struct {
	nodes []string
}

func (h *Hash) Pick(key string) string {
	// 步骤 1：用 crc32 把 key 算成哈希值（uint32）
	hash := crc32.ChecksumIEEE([]byte(key))
	// 步骤 2：对节点数取模，落到固定节点
	return h.nodes[hash%uint32(len(h.nodes))]
}

它完美解决了会话保持：同一个 key 的哈希值永远一样，模 3 的结果也永远一样，所以永远落到同一个节点。

但它的致命缺陷在扩缩容时暴露：节点数从 3 变成 4，hash % 3 变成 hash % 4——几乎所有 key 的落点都会变。

我们来量化一下这个灾难有多严重。假设有 100 万个 key、3 个节点：

加权哈希：用"区间"替代"取模"

把加权随机（3.2.4 节）里的"随机数"换成"key 的哈希值"，就得到了加权哈希：

同一个 key 的哈希值是固定的 → 它永远落在数轴上同一个点 → 永远命中同一个节点。既保留了哈希的"固定落点"，又让权重高的节点分到更大的区间。

所以它的代码和 WeightedRandom 几乎一模一样，唯一的区别在第 1 行：

func (w *WeightedHash) Pick(key string) string {
	// 与 WeightedRandom 的唯一区别：把 rand.Int63n(total) 换成 key 的哈希值
	r := int64(crc32.ChecksumIEEE([]byte(key))) % w.total
	// 下面完全一致：累加权重，找 r 落在哪个区间
	var sum int64
	for i, weight := range w.weights {
		sum += weight
		if r < sum {
			return w.nodes[i]
		}
	}
	return w.nodes[len(w.nodes)-1]
}

“点从哪来"这一行的差别，就是"随机"与"会话保持"的分界线——一个用随机数（每次不同），一个用 key 的哈希值（永远相同）。这个对照非常有助于理解。

适用场景和一致性哈希类似（本地缓存命中、会话保持），只是用"区间"替代了"环”，实现更简单。它的缺点和普通哈希一样：节点数变化时落点全变。

一致性哈希：把哈希空间弯成一个环

核心思路：不要对"节点数"取模，而是把整个哈希值空间（0 ~ 2³²-1）想象成一个首尾相接的圆环：

1. 节点落环：每个节点也计算一个哈希值（通常用它的 IP 或实例 ID），落在环上的某个位置。
2. key 落环：请求的 key 也算哈希，落在环上的某个位置。
3. 顺时针找节点：从 key 的位置出发，沿顺时针方向遇到的第一个节点，就是目标节点。

flowchart TD
    Key["请求 key = user:42"] --> Hash["计算 crc32 哈希值 h"]
    Hash --> Pos["在 0 ~ 2³²-1 的环上定位"]
    Pos --> Find["从 h 出发顺时针找第一个节点"]
    Find --> Node["目标节点（如 127.0.0.1:9090）"]

为什么这样就能减少迁移？ 关键洞察：

• 增加一个节点：新节点落在环上的某个位置，它只"抢走"它逆时针方向到前一个节点之间的那段区间。其他区间的归属完全不变。
• 删除一个节点：只有这个节点负责的那段区间需要转移给它的下一个节点。其余全部不变。

flowchart LR
    subgraph Before["3 个节点时"]
        direction TB
        B1["环上依次是：A → B → C → 回到 A"]
    end
    subgraph After["插入节点 D（落在 B 和 C 之间）"]
        direction TB
        A2["只有 B→D 这一段的 key 从 C 改投 D"]
        B2["A→B 段、C→A 段完全不受影响"]
    end
    Before --> After

定量结论：N 个节点时增加 1 个节点，只有约 1/(N+1) 的 key 需要迁移（删除 1 个节点才是 1/N）。3 个节点加 1 个 = 迁移 1/4 = 25%，而普通哈希是 75%。节点越多，优势越大。

虚拟节点：解决"数据倾斜"

理想很丰满，现实很骨感。一致性哈希有个严重问题：节点很少时，它们在环上的位置是随机的，很可能挤在一起。

理想情况（均匀分布）：        实际情况（随机落点，3 个节点）：
    A ---- B ---- C              A--B-------C
  每段各占 1/3                  A 只管 10%，C 管了 60%！

3 个节点时，运气不好可能一个节点管了 70% 的 key，另两个各管 15%——这就是数据倾斜。

解决方案：虚拟节点（Virtual Node / VNode）。

不要让一个真实节点只在环上占 1 个位置，而是让它占 100~200 个位置。具体做法是给真实节点编号，生成 0#nodeA、1#nodeA、2#nodeA…… 199#nodeA 这 200 个"虚拟节点"，每个都算一个哈希落在环上，全部映射到真实节点 A。

节点多了，环上的点就密了，分布自然趋于均匀（还是大数定律）。

只有真实节点（3 个点）：           有虚拟节点（每个真实节点 100 个）：
  A--B-------------C                A B C A C B A B C C A B ...（300 个点交错）
  ↑ 分布极不均匀                    ↑ 每个真实节点约占 1/3

虚拟节点数怎么选？ 通常 100~200。太少分布不均，太多则内存和构建哈希环的开销变大（每次节点变化要重建环）。经验值：节点数 × 虚拟节点数 ≥ 1000 时分布就比较均匀了。

代码实现（完整可运行）

package consistenthash

import (
	"hash/crc32"
	"sort"
	"strconv"
	"sync"
)

// Ring 一致性哈希环
type Ring struct {
	mu       sync.RWMutex
	hashFunc func(data []byte) uint32
	replicas int               // 虚拟节点数，解决数据倾斜
	keys     []uint32          // 排好序的哈希值（环上所有虚拟节点的位置）
	hashMap  map[uint32]string // 哈希值 -> 真实节点
}

func New(replicas int, fn func(data []byte) uint32) *Ring {
	if fn == nil {
		fn = crc32.ChecksumIEEE // 默认哈希函数
	}
	return &Ring{replicas: replicas, hashFunc: fn, hashMap: make(map[uint32]string)}
}

// Add 增加节点，每个真实节点生成 replicas 个虚拟节点
func (r *Ring) Add(nodes ...string) {
	r.mu.Lock()
	defer r.mu.Unlock()
	for _, node := range nodes {
		for i := 0; i < r.replicas; i++ {
			// 虚拟节点名 = 编号 + 真实节点名，保证每个虚拟节点哈希不同
			h := r.hashFunc([]byte(strconv.Itoa(i) + node))
			r.keys = append(r.keys, h)
			r.hashMap[h] = node
		}
	}
	// 排序！只有排好序才能用二分查找
	sort.Slice(r.keys, func(i, j int) bool { return r.keys[i] < r.keys[j] })
}

// Get 根据 key 顺时针找到第一个节点
func (r *Ring) Get(key string) string {
	r.mu.RLock()
	defer r.mu.RUnlock()
	if len(r.keys) == 0 {
		return ""
	}
	h := r.hashFunc([]byte(key))
	// 二分找第一个 >= h 的哈希值，即顺时针方向的下一个节点
	idx := sort.Search(len(r.keys), func(i int) bool { return r.keys[i] >= h })
	if idx == len(r.keys) {
		idx = 0 // 走到环尾则环绕回环首（首尾相接的关键）
	}
	return r.hashMap[r.keys[idx]]
}

逐行讲解

补课胶囊 · sort.Search（标准库二分查找） 一句话：在有序序列里，找到第一个让 f(i) 返回 true 的下标；找不到就返回 n（序列长度）。 类比：查字典。你要找第一个拼音排在 “zh” 之后（含）的字——不会一页一页翻，而是从中间翻开，看这一页在 “zh” 前面还是后面，然后扔掉一半，继续对半砍。100 万页的字典只需要约 20 次翻找。 最小示例：

a := []int{1, 3, 5, 7, 9}
i := sort.Search(len(a), func(i int) bool { return a[i] >= 6 })
fmt.Println(i) // 输出 3（a[3]=7 是第一个 >= 6 的）

j := sort.Search(len(a), func(i int) bool { return a[i] >= 100 })
fmt.Println(j) // 输出 5（等于 len(a)，表示"没找到"，需要环绕）

复杂度：O(log n)。300 个虚拟节点只需约 9 次比较；如果线性扫描要 300 次。 回到主线：sort.Search 是 Go 里写哈希环的标准姿势。记住它的语义——找第一个满足条件的下标，找不到返回 n。

常见坑

一致性哈希 vs 普通哈希 vs 加权哈希

小收口：静态算法三大家族讲完了——轮询家族（精确但需计状态）、随机家族（无状态但短期不准）、哈希家族（有会话保持，一致性哈希还能把节点变化的迁移量压到 1/N）。它们共同的思路是"不算真实负载，靠统计学保证均衡"。下一节的动态算法，走的是完全相反的路。

3.3 动态负载均衡算法

先抛问题

静态算法"不算负载"，那么动态算法就要回答一个问题：

我能不能真的去测量每个节点当前的负载，然后选最轻的那个？

听起来很美好，但马上会遇到两个现实问题：

1. “负载"到底是什么？怎么量化？ CPU？内存？队列长度？响应时间？没有一个单一指标能完美代表负载。
2. 我在客户端，我怎么知道服务端那台机器的 CPU 是多少？

动态算法就是围绕这两个问题展开的一系列"近似方案”。

给个直觉：看病挂号

静态算法 = 医院叫号，按顺序轮到你（不管你是感冒还是要做手术）。 动态算法 = 分诊台护士看一眼每个诊室的情况：3 号诊室门口排了 20 个人，1 号诊室门口空着——“你去 1 号”。

但护士只能看到候诊区（客户端侧的情况），她看不到诊室里面医生是正在处理一个疑难杂症还是闲着刷手机（服务端真实情况）。这就是动态算法的根本局限。

3.3.1 最少连接数（Least Connections）

思路：挑选当前连接数最少的节点。逻辑很直白：连接数少 = 手头活儿少 = 应该给它派活。

实现就是"遍历找计数最小的 → 计数 +1 → 连接关闭时 -1"，与下方 3.3.2 节的最少活跃完全同构，只是把"活跃请求数"换成"连接数"。完整的工程实现见第四节第 4 步的 LeastConn（那里用的是 inflight 在途请求数）。

节点 A：10 条连接，但每条上面挂着 10 个请求  →  实际在途 100 个请求
节点 B：12 条连接，但每条只挂 4 个请求       →  实际在途 48 个请求

3.3.2 最少活跃数（Least Active Requests）

为了解决上面的问题，把指标从"连接数"换成"活跃请求数"：

活跃数 = 客户端发出去、但还没收到响应的请求数。

做法：客户端为每个节点维持一个计数器，发请求时 +1，收到响应时 -1，每次选活跃数最低的节点。

sequenceDiagram
    participant P as Pick()
    participant C as 计数器
    participant N as 节点
    P->>C: 查各节点活跃数 A=3, B=7, C=2
    P->>C: 选 C，C 活跃数 +1 → 3
    P->>N: 向 C 发请求
    N-->>C: 收到响应，C 活跃数 -1 → 2

比连接数准确得多，因为它直接衡量"这个节点欠我多少响应"。gRPC 的 leastrequest balancer 就是这么做的。

3.3.3 最快响应时间（Response Time）

思路：挑选历史响应最快的节点。

可以用的统计量：

补课胶囊 · P99 / 分位数（Percentile） 一句话：把所有请求的耗时从小到大排序，第 99% 位置的那个值就叫 P99，意思是"99% 的请求都比它快（或等）"。 类比：高考的一分一段表。平均分会被"超级学霸"拉高，也不能反映"垫底那批人"有多惨。而 P99 相当于"排名前 1% 的分数线"——它专门盯最慢的那 1%，也就是用户体验最差的那部分请求。 为什么推荐平均或 P99 而不是 P999：P999 意味着 1000 个请求里只取最慢的那 1 个，样本量不足时这个值会剧烈抖动（一个偶然的 GC 停顿就能让 P999 翻十倍），用它做选点会导致流量在两个节点之间来回横跳。 回到主线：响应时间是一个"综合指标"——它同时包含了 CPU、内存、网络、数据库慢查询等所有因素的影响，所以在动态算法里它往往是最实用的那个。

实现时通常配合滑动窗口或**指数移动平均（EWMA）**来平滑历史值，避免被单次抖动带偏。

3.3.4 微服务框架的固有局限

上面三种算法都是客户端在选择，而客户端有一个无法回避的事实：

客户端只知道自己这一侧的情况，看不到服务端的真实负载。

最后一条是致命的：你只知道你自己给节点 B 发了 5 个请求，但另外 20 个服务实例可能同时给 B 发了 500 个请求。 你以为 B 很闲，其实 B 已经快炸了。这在业内叫**“局部视角问题”（Partial View Problem）**。

要拿到服务端真实指标，有三条路：

flowchart LR
    C[客户端] -->|只知自己侧指标| L["本地计算
活跃数 / 响应时间"]
    S[服务端] -->|"① 上报 CPU/内存"| R[注册中心]
    S -->|"② 响应头附带指标"| C
    S -->|"③ 被采集"| P["Prometheus
可观测性平台"]
    R -->|通知| C
    P -->|拉取| C

3.3.5 设计自己的负载均衡算法：先回答四个问题

不管是评价别人的算法，还是要自己设计一个，都可以用这四个问题过一遍。这是本章最有迁移价值的方法论——面试官问"你设计一个负载均衡算法"时，就按这四问答：

问题 1 · 要不要考虑服务器处理能力？

• 答"不考虑" → 轮询、随机、哈希、最少连接、最少活跃这些无权重版本
• 答"要考虑" → 对应的加权版本，用权重表达处理能力

问题 2 · 选什么指标表达当前负载？

• 答"不选，靠统计" → 轮询、随机、哈希（静态算法）
• 答"选一个指标" → 连接数、活跃请求数、响应时间、错误率、CPU……
• 答"选多个指标组合" → 这就是你自己的算法了！比如 得分 = 0.5 × 归一化响应时间 + 0.3 × 错误率 + 0.2 × (1 - 活跃数/总活跃数)，选得分最高的

问题 3 · 所有请求消耗的资源一样吗？

显然不一样——大 V 的粉丝列表有 1000 万条，普通用户只有 20 条。不考虑请求消耗差异的 LB，容易出现"偶发性打爆某一台实例"。

可能的应对：对大请求做单独限流 / 单独路由到"大请求专用节点池" / 用请求预估成本（cost）作为权重。

问题 4 · 实践中选什么？

遇事不决用轮询，出了问题再换。

这是非常实在的工程建议。轮询简单、可预测、无隐藏状态，绝大多数业务用它就够了。不要一上来就上"自适应 + 多指标 + 机器学习"的复杂算法——复杂算法带来的收益往往抵不上它的调试成本和不可预测性。

小收口：动态算法用"实时指标"替代"统计学"，思路更先进，但受限于"客户端只能看到自己这一侧"，实践中反而不如静态算法用得多。业界主流做法是"静态算法打底 + 健康检查纠偏"（第四节就是这么落地的）——用轮询/平滑 WRR 保证基本分布，用连续失败剔除来兜底故障节点。

3.4 在 gRPC 中接入负载均衡

前面讲了这么多算法，现在要把它们真正接进项目。在动手前，先补一下 gRPC 的基础概念。

3.4.1 补课：gRPC 的几个关键概念

补课胶囊 · gRPC 一句话：一种高性能的 RPC 框架——让你像调用本地函数一样调用另一台机器上的函数。 类比：打电话。你拨号（调用 client.GetUser(ctx, req)），对方接起来处理（服务端执行真实的 GetUser），然后回答你（返回 resp）。中间的拨号、编码、传输、解码全由 gRPC 帮你做了，你感觉就像直接跟对方说话。 为什么微服务爱用它：用 Protobuf（一种紧凑的二进制编码格式）传输，比 JSON 小 3-10 倍、快 5-10 倍；基于 HTTP/2，天生支持多路复用和流式传输。 回到主线：第 12 章我们已经用 gRPC + etcd 让服务互相调通了，本章只关注"调用时选哪个节点"这一件事。

gRPC 客户端有三个核心抽象，必须分清：

3.4.2 gRPC 的默认行为：pick_first（本章最重要的反直觉点）

flowchart TD
    D1["默认 pick_first"] --> P1["永远选名单第一个节点
127.0.0.1:8090"]
    P1 --> R1["8091、8092：一条平躺的直线 😴"]
    D2["配置 round_robin"] --> P2["请求轮流打到
8090 → 8091 → 8092"]
    P2 --> R2["三条曲线均匀分布 ✅"]

为什么会这么设计？ 不是 gRPC 偷懒，而是因为 pick_first 有一个重要优点：它保证同一个 ClientConn 上的所有请求都打到同一个后端，这在需要连接亲和性（比如后端是有状态服务、或者你想减少连接数）的场景下反而是对的。另外 pick_first 可以省掉"为每个节点都建连"的开销。

怎么验证自己踩了这个坑？ 两个方法：

# 方法一：看连接数（只连了 1 个节点，说明是 pick_first）
netstat -an | grep ESTABLISHED | grep 909

# 方法二：看各实例的请求日志/监控 QPS 曲线
# 只有一个实例有流量 → 就是 pick_first 没换

3.4.3 使用内置的 round_robin

改法只有一行：通过 WithDefaultServiceConfig 传入一段 JSON 配置。

import (
	"google.golang.org/grpc"
	"google.golang.org/grpc/balancer/roundrobin"
)

// 注意：JSON 串很容易写错，配置名是 round_robin（下划线！）
// 常量 roundrobin.Name 的值就是 "round_robin"
conn, err := grpc.Dial(
	"etcd:///service.user",
	grpc.WithDefaultServiceConfig(`{"loadBalancingConfig":[{"`+roundrobin.Name+`":{}}]}`),
)

逐行讲解

// ❌ 错误：第二次调用覆盖第一次，retryPolicy 丢失
grpc.WithDefaultServiceConfig(retryCfg),
grpc.WithDefaultServiceConfig(lbCfg),

// ✅ 正确：合并成一个 JSON 对象
grpc.WithDefaultServiceConfig(`{
    "loadBalancingConfig":[{"round_robin":{}}],
    "methodConfig":[{"name":[{"service":"user.v1.UserService"}],"retryPolicy":{...}}]
}`)

round_robin 内部怎么实现的？ 核心就是利用原子操作更新候选节点下标——和我们 3.2.1 节写的那个 RoundRobin 是一回事，只是它操作的对象是 balancer.SubConn 数组。

3.4.4 使用内置的 weightedroundrobin

需要两步：

1. 匿名引入包 google.golang.org/grpc/balancer/weightedroundrobin，触发它的 init() 完成注册
2. 在 ServiceConfig 里指定使用 weightedroundrobin

import (
	_ "google.golang.org/grpc/balancer/weightedroundrobin" // 匿名引入，只为触发 init
	"google.golang.org/grpc"
)

conn, err := grpc.Dial(
	"etcd:///service.user",
	grpc.WithDefaultServiceConfig(`{"loadBalancingConfig":[{"weightedroundrobin":{}}]}`),
)

补课胶囊 · 匿名 import（_ "xxx"）与 init 注册模式 一句话：_ 表示"我只需要这个包的副作用（执行它的 init()），不用它的任何函数"。 类比：你去驾校报名，不是要用他们的车，而是要让他们在系统里给你登记一条"此人已报名"的记录。登记这个动作（副作用）才是目的。

为什么 Go 需要这套机制？ 因为 Go 语言**没有"插件注册中心"**这种运行时机制。于是很多库用 init() + 全局注册表来模拟：包一被 import，它的 init() 就执行，把实现按名字登记进一张全局表；后续使用方按名字去表里查。

最小示例：

// mypkg/mypkg.go
package mypkg

import "fmt"

func init() {
    fmt.Println("init 被调用了") // import 时自动执行
}

// main.go
import _ "example.com/mypkg" // 只用副作用
// 运行后输出：init 被调用了

哪些地方用了这套模式？

• 数据库驱动：_ "github.com/go-sql-driver/mysql" → 注册 mysql 驱动，你才能 sql.Open("mysql", ...)
• gRPC 的 balancer / resolver / compressor
• 各种序列化框架、插件系统

回到主线：忘了匿名引入 weightedroundrobin 包，配置里写 weightedroundrobin 就会报 unknown balancer "weightedroundrobin"。这是最高频的踩坑点之一。

3.4.5 gRPC 内置 balancer 一览

在 google.golang.org/grpc/balancer 子包下，官方提供了这些实现：

3.4.6 自定义负载均衡算法：PickerBuilder + Picker

要在 gRPC 里塞进自己的算法，需要实现两个接口：

flowchart TD
    A["grpc.Dial 建立 ClientConn"] --> B["Resolver 解析出地址列表"]
    B --> C["Balancer 为每个地址创建 SubConn 并建连"]
    C --> D["连接就绪 → 调用 PickerBuilder.Build()"]
    D --> E["生成 Picker（内含我们的算法状态）"]
    E --> F["每次 RPC → 调用 Picker.Pick()"]
    F --> G["返回 PickResult{SubConn, Done}"]
    G --> H["gRPC 用这个 SubConn 发请求"]
    H --> I["请求结束 → 回调 Done(info)"]
    I -->|"info.Err != nil"| J["上报健康检查：失败"]
    I -->|"info.Err == nil"| K["上报健康检查：成功"]
    J --> D
    K --> D

完整示例：自定义平滑加权轮询

Step 1 · 定义节点结构体和 Picker

package mywrr

import (
	"context"
	"sync"

	"google.golang.org/grpc/balancer"
)

// weightConn 把 balancer.SubConn 和权重绑在一起
type weightConn struct {
	SubConn       balancer.SubConn
	Weight        int64 // 初始权重
	CurrentWeight int64 // 当前权重
}

// Picker 实现 balancer.Picker 接口
type Picker struct {
	mu    sync.Mutex
	conns []*weightConn
}

// Pick 每次调用选一个节点（算法与 3.2.3 节完全一致）
func (p *Picker) Pick(info balancer.PickInfo) (balancer.PickResult, error) {
	p.mu.Lock()
	defer p.mu.Unlock()
	if len(p.conns) == 0 {
		return balancer.PickResult{}, balancer.ErrNoSubConnAvailable
	}
	// ① 攒分 + 累加总权重
	var total int64
	for _, c := range p.conns {
		total += c.Weight
		c.CurrentWeight += c.Weight
	}
	// ② 选 currentWeight 最大的
	max := p.conns[0]
	for _, c := range p.conns[1:] {
		if c.CurrentWeight > max.CurrentWeight {
			max = c
		}
	}
	// ③ 还债
	max.CurrentWeight -= total

	// 挂上 Done 回调：可在这里做 failover / 动态调整权重（见 3.5.3 节）
	return balancer.PickResult{
		SubConn: max.SubConn,
		Done: func(ctx context.Context, info balancer.PickDoneInfo) {
			// 作业：根据 info.Err 动态调整 max.Weight
			// 失败→降低权重；成功→提高权重；务必设上下限
		},
	}, nil
}

Step 2 · 实现 PickerBuilder

// PickerBuilder 在可用连接变化时被调用，重新构造 Picker
type PickerBuilder struct{}

func (b *PickerBuilder) Build(info base.PickerBuildInfo) balancer.Picker {
	if len(info.ReadySCs) == 0 {
		return base.NewErrPicker(balancer.ErrNoSubConnAvailable)
	}
	// 遍历所有就绪连接，取出权重
	var conns []*weightConn
	for sc, sci := range info.ReadySCs {
		// 注意：Metadata 字段已被弃用，应从 Address.Attributes 取
		// resolver 侧 attributes.New("weight", ins.Weight) 存的是 int，
		// 这里按 int 断言，再转成平滑 WRR 需要的 int64（按 int64 断言会静默失败、权重退化为 1）
		w, _ := sci.Address.Attributes.Value("weight").(int)
		if w <= 0 {
			w = 1 // 默认权重，兜底
		}
		conns = append(conns, &weightConn{SubConn: sc, Weight: int64(w)})
	}
	return &Picker{conns: conns}
}

for sc, sci := range info.ReadySCs {
    fmt.Printf("addr=%s attributes=%+v\n", sci.Address.Addr, sci.Address.Attributes)
}

Step 3 · 注册到 gRPC

package mywrr

import (
	"google.golang.org/grpc/balancer"
	"google.golang.org/grpc/balancer/base"
)

const Name = "my_smooth_wrr"

func init() {
	// 把 PickerBuilder 包成 balancer.Builder 注册进去（见 3.4.4 的补课胶囊）
	balancer.Register(base.NewBalancerBuilder(Name, &PickerBuilder{}, base.Config{HealthCheck: true}))
}

使用时：匿名引入 mywrr 包触发 init()，然后在 WithDefaultServiceConfig 里指定 "my_smooth_wrr" 即可。（服务端的权重要先通过 etcd.WithWeight(5) 之类的选项注册进注册中心，再由 Resolver 写进 Address.Attributes——第四节第 7 步会完整实现这条链路。）

逐行讲解：这三个东西到底是什么关系？

为什么要拆成 Builder 和 Picker 两个？ 因为连接列表变化是低频事件、选节点是高频操作。Builder 在低频事件时做一次性的准备工作（解析权重、建哈希环、排序），Picker 只做高频的选点计算。这个拆分让你可以把耗时的准备工作只在必要时做一次。

3.4.7 更顶级的抽象：Balancer 接口

在 Picker / PickerBuilder 之上，gRPC 还有一个更顶级的抽象 balancer.Balancer。两者的分工：

• Picker：只回答"这个请求发给哪个节点"
• Balancer：还要管理所有节点的连接与连接池状态——SubConn 的创建、连接、断开、重连、健康检查都归它管

我们前面用的 base.NewBalancerBuilder，本质就是「默认的连接管理逻辑 + 你的 PickerBuilder」打包成一个完整的 Balancer。

小收口：gRPC 的 LB 扩展点就是两个接口——PickerBuilder 管"准备"，Picker 管"选点"，连接管理交给官方的 base 骨架。记住三件事：默认是 pick_first（不均衡！）、换策略靠 WithDefaultServiceConfig 的 JSON、自定义包必须匿名引入触发 init()。

3.5 Failover：调用失败怎么办

先抛问题

即使做了负载均衡，还是会遇到失败：

• 某个节点进程崩了（Panic、OOM）
• 某个节点还在，但已经不健康（死锁、GC 卡死、磁盘打满，能连上但永远不返回）
• 某个节点刚下线，注册中心的通知还没到（租约还没过期，Resolver 还把它列在名单里）
• 网络抖动（这一秒不通，下一秒就好了）

这时候要做 Failover（故障转移）：把请求转移到别的节点上。

3.5.1 Failover 的本质：重试 + 负载均衡

gRPC 里最简单的 Failover 思路，说穿了就是一句话：

重试 + 负载均衡 —— 重试的时候再走一次 LB，自然就换了一个节点。

sequenceDiagram
    participant C as 客户端
    participant LB as 负载均衡
    participant N1 as 节点1（故障）
    participant N2 as 节点2（正常）
    C->>LB: 发起请求
    LB->>N1: 第 1 次转发
    N1-->>C: 失败（UNAVAILABLE）
    C->>LB: 重试（再次走 LB）
    LB->>N2: 第 2 次转发（换了个节点）
    N2-->>C: 成功

注意这里的精妙之处：你没有写任何"换节点"的代码——因为重试会重新调用 Pick()，而平滑 WRR 的"还债"机制会让第二次大概率选中另一个节点。重试和负载均衡天然地组合在了一起。

3.5.2 通过 methodConfig 配置重试

gRPC 的重试策略通过 ServiceConfig 里的 methodConfig 配置：

// 重试策略通过 JSON 配置，手写极易出错，仔细检查
svcCfg := `{
    "methodConfig": [{
        "name": [{"service": "user.v1.UserService"}],
        "retryPolicy": {
            "maxAttempts": 4,
            "initialBackoff": "0.1s",
            "maxBackoff": "1s",
            "backoffMultiplier": 2.0,
            "retryableStatusCodes": ["UNAVAILABLE", "RESOURCE_EXHAUSTED"]
        }
    }]
}`
conn, _ := grpc.Dial(
	"etcd:///service.user",
	grpc.WithDefaultServiceConfig(svcCfg),
)

逐行讲解

3.5.3 进阶 Failover：在 Picker 的 Done 里调整权重

配置化的重试只能处理"这次请求失败"这一件事。更复杂的场景——比如"某个节点最近一直在报错，我想让它暂时少接流量"——就需要自己实现 LB，在 PickResult.Done 回调里嵌入逻辑。

Done 回调是什么？ gRPC 在每次 RPC 结束（成功或失败）时，会调用你返回的 PickResult.Done，并把这次调用的结果放进 balancer.PickDoneInfo（里面有一个 Err 字段）。

于是你可以在这里做两件事：

Done: func(ctx context.Context, info balancer.PickDoneInfo) {
    if info.Err != nil {
        // 失败：降低这个节点的权重（甚至直接踢出可用列表）
        max.Weight = maxWeight(max.Weight/2, 1) // 减半，但不能低于 1
    } else {
        // 成功：慢慢把权重加回来
        max.Weight = minWeight(max.Weight+1, 100) // +1，但不能超过 100
    }
}

效果：一个连续报错的节点，权重会指数级衰减（100 → 50 → 25 → 12 → 6 → 3 → 1），流量自然越来越少；等它恢复了，权重又会缓慢爬升回来。这叫**“基于反馈的自适应负载均衡”**。

小收口：Failover = 重试 + 负载均衡。简单场景用 methodConfig 配重试策略（只对幂等的、可重试的错误码重试，必须配退避）；复杂场景在 Done 回调里根据错误动态调整权重（记得设上下限）。下一节看看主流框架是怎么做的。

3.6 主流框架的 LB 方案与面试亮点

3.6.1 Kratos / go-zero 一览

Kratos 支持的算法：

• WRR（默认）：平滑加权轮询，就是我们 3.2.3 节手写的那个
• P2C（Pick of 2 Choices）：随机挑 2 个节点，再从中选负载低的那个（后面细说）
• Random：随机

// Kratos：设置全局默认（注意是全局的，不是 per-service 的）
selector.SetGlobalSelector(wrr.NewBuilder())

补课胶囊 · P2C（Pick of 2 Choices） 一句话：别一个一个挑，随机抓两个出来比一比，选更好的那个。 类比：相亲。与其把 100 个人全部面试一遍（开销太大），不如随机抽 2 个人见一见，选更合适的那个。虽然不是最优解，但比随机选 1 个好很多，而且开销极小。 为什么有效：这是个有数学证明的结论——从 N 个里"随机选 1 个"的期望负载是平均负载，而"随机选 2 个取更优"能把最坏情况的负载从 O(log N / log log N) 降到 O(log log N)，提升极其显著。这就是所谓的"二选一的力量（The Power of Two Choices）"。 回到主线：P2C 通常配合"活跃数"或"响应时间"作为比较依据，是 go-zero 的默认算法。它比"全局扫描找最小的"快（O(1) vs O(n)），比纯随机准，是个很漂亮的折中。

3.6.2 三个适合面试的亮点方案

方案一 · 一致性哈希 LB + 本地缓存 + Redis 多级缓存

问题：如果直接用轮询，本地缓存会在多个节点上重复加载——3 个节点各缓存一份相同的数据，命中率 1/3、内存 3 倍。

方案：改用一致性哈希，让同一个 key 的请求必然命中同一个节点。

flowchart LR
    K["请求 key = user:42"] --> H["一致性哈希"]
    H -->|固定落点| N1["节点1
本地缓存命中 ✅"]
    H -.->|不会落到这里| N2["节点2
本地缓存命中 ✅"]
    N1 --> M["未命中才查 Redis → 再查 DB"]

效果：

• 本地缓存命中率从 1/N 提升到接近 100%（N = 节点数）
• 内存消耗降到 1/N
• 节点变化时只有 1/N 的缓存需要重建

面试定位：这是"有点高级但不至于太高级"的方案，特别适合初中级岗位——它证明你理解了一致性哈希的价值，并且能把它和缓存体系串起来讲。

方案二 · 结合熔断 / 限流 / 降级的 Failover

思路：客户端发现某个服务端触发了熔断 / 限流 / 降级时，一段时间内不选这个节点。

实现：在 Done 回调里识别特定错误码（比如服务端限流会返回 RESOURCE_EXHAUSTED），收到就把权重调到极低或直接踢出（详见第 14 章）。

效果：避免把请求继续发给一个"明确说了它扛不住"的节点，给对方喘息时间。

方案三 · 动态判定负载

思路：客户端维持每个节点的响应时间、错误率、活跃数等指标，选负载最低的节点。

关键是要能说清指标来源（3.3.4 节的三条路）：服务端上报注册中心 / 响应中附带 / 从 Prometheus 拉取。

面试话术示例：

“我们的 LB 用的是平滑加权轮询打底，权重由实例规格决定；同时客户端在 Done 回调里维护每个节点的滑动窗口错误率和 P99 响应时间，错误率超过阈值就指数降低权重。另外我加了一层健康检查，连续 3 次失败会剔除节点 10 秒，10 秒后半开放一个试探请求。这样既保证了基本分布，又能对故障节点快速反应。”

小收口：框架的 LB 万变不离其宗。面试准备的优先级是：① 手撕平滑 WRR > ② 讲清一致性哈希 > ③ 能结合业务说出一个带指标的专属方案。

四、跟着写：分步实现

上一章我们把实例注册进了 etcd，客户端也通过自定义 Resolver 拿到了"有哪些可用实例"。但 Resolver 只回答了"名单"，没回答"这一次调用发给谁"。

本章就在项目里补上这块拼图：新建 pkg/balancer/ 包，落地 5 种负载均衡算法和统一的 Balancer 接口，加上"连续失败剔除、半开恢复"的健康检查，最后注册成 gRPC 的 weighted_round_robin 与 consistent_hash 两个策略，让 post-service 调用 user-service 时实现真正的客户端负载均衡。

整体分 8 步：

# 确认项目可编译
cd ~/code/content-community && go build ./...
# 预期：无任何输出（编译通过）

第 1 步：定义 Balancer 统一接口

目标：5 种算法实现同一个接口，方便在运行时按配置切换。

节点直接复用第 12 章 pkg/registry 的 ServiceInstance——它的 Weight 字段就是为这一章准备的。Resolver 监听到实例变化时调用 UpdateInstances 全量刷新，各算法内部自己重建状态。

// pkg/balancer/balancer.go
package balancer

import (
	"errors"

	"github.com/yourname/content-community/pkg/registry"
)

// ErrNoInstance 当前没有可用实例时返回，调用方应快速失败或走降级
var ErrNoInstance = errors.New("balancer: no available instance")

// Balancer 负载均衡统一接口，本章 5 种算法都实现它
type Balancer interface {
	// Pick 选出一个实例；key 给哈希类算法用（如 user_id），轮询/随机忽略它
	Pick(key string) (*registry.ServiceInstance, error)
	// UpdateInstances 服务发现推送新列表时调用，全量替换
	UpdateInstances(instances []*registry.ServiceInstance)
}

三个设计要点：① ErrNoInstance 是统一哨兵错误，调用方用 errors.Is 判断后决定"快速失败"还是"走降级"；② Pick 为什么给轮询和随机也带 key 参数？为了接口统一，上层代码不用关心用的是哪种算法，非哈希算法忽略它即可；③ UpdateInstances 用全量替换而非"增量增删"，因为全量替换幂等且无状态泄漏，不会出现"删除消息丢了导致脏节点残留"——注册中心的 watch 本来也是推全量。

验证：

go build ./pkg/balancer/...
# 预期：无任何输出（编译通过）

第 2 步：实现轮询 RoundRobin

目标：最基础的算法，验证接口设计是否合理。

与上文 3.2.1 节的演示版相比，工程版有两点不同：节点是 ServiceInstance 而非字符串；实例列表会被 Resolver 并发刷新，要用读写锁保护切片，计数器依旧走原子操作。

// pkg/balancer/roundrobin.go
package balancer

import (
	"sync"
	"sync/atomic"

	"github.com/yourname/content-community/pkg/registry"
)

// RoundRobin 轮询负载均衡
type RoundRobin struct {
	mu        sync.RWMutex                // 实例列表会被并发更新，读多写少用 RWMutex
	instances []*registry.ServiceInstance // 候选实例
	counter   uint64                      // 原子计数器，Pick 时无锁自增
}

// Pick 按顺序依次返回实例：A → B → C → A …
func (r *RoundRobin) Pick(key string) (*registry.ServiceInstance, error) {
	r.mu.RLock()
	defer r.mu.RUnlock()
	if len(r.instances) == 0 {
		return nil, ErrNoInstance
	}
	// 原子 +1 后先减 1 再取模，保证第一次请求拿到下标 0
	n := atomic.AddUint64(&r.counter, 1)
	return r.instances[(n-1)%uint64(len(r.instances))], nil
}

// UpdateInstances 全量替换实例列表
func (r *RoundRobin) UpdateInstances(instances []*registry.ServiceInstance) {
	r.mu.Lock()
	defer r.mu.Unlock()
	r.instances = instances
}

三个关键点：① sync.RWMutex 因为实例列表读多写少，允许多个读并发；② 计数器 counter 不放在锁的保护范围内，它用自己的原子操作（原因见下方 hint）；③ defer r.mu.RUnlock() 必须用 defer，否则 22 行那个提前 return 的分支会漏掉解锁造成死锁。

验证：

go build ./pkg/balancer/...
# 预期：无输出即通过（请求分布留到第 8 步实测）

第 3 步：实现平滑加权轮询 SmoothWRR（本章核心）

目标：写出 Nginx 同款算法，并用单测把 3.2.3 节手推的 7 次序列锁进代码里。

算法步骤与 7 次推演表见 3.2.3 节，这里聚焦工程化差异：UpdateInstances 之后要重建权重状态，权重非法时要兜底。

// pkg/balancer/smoothwrr.go
package balancer

import (
	"sync"

	"github.com/yourname/content-community/pkg/registry"
)

// wrrNode 平滑加权轮询的内部节点
type wrrNode struct {
	instance      *registry.ServiceInstance
	weight        int // 初始权重，构造后不变
	currentWeight int // 当前权重，每次 Pick 都会变（可能是负数）
}

// SmoothWRR 平滑加权轮询（Nginx 同款算法）
type SmoothWRR struct {
	mu    sync.Mutex
	nodes []*wrrNode
}

// Pick 每次选 currentWeight 最大的节点
func (s *SmoothWRR) Pick(key string) (*registry.ServiceInstance, error) {
	s.mu.Lock()
	defer s.mu.Unlock()
	if len(s.nodes) == 0 {
		return nil, ErrNoInstance
	}
	// 步骤 1：所有节点 currentWeight += weight，顺便累加总权重
	total := 0
	for _, n := range s.nodes {
		total += n.weight
		n.currentWeight += n.weight
	}
	// 步骤 2：找 currentWeight 最大的节点（打平时保留先遍历到的，见 3.2.3 节）
	best := s.nodes[0]
	for _, n := range s.nodes[1:] {
		if n.currentWeight > best.currentWeight {
			best = n
		}
	}
	// 步骤 3：选中节点"还债"，扣掉总权重
	best.currentWeight -= total
	return best.instance, nil
}

// UpdateInstances 全量替换实例，并重建权重状态（见上方坑 1）
func (s *SmoothWRR) UpdateInstances(instances []*registry.ServiceInstance) {
	s.mu.Lock()
	defer s.mu.Unlock()
	s.nodes = s.nodes[:0] // 复用底层数组，减少 GC
	for _, ins := range instances {
		w := ins.Weight
		if w <= 0 {
			w = 1 // 权重缺失/非法兜底为 1，保证实例还能被选中
		}
		s.nodes = append(s.nodes, &wrrNode{instance: ins, weight: w})
	}
}

三个关键点：① weight 与 currentWeight 必须分开存（前者是"应该分多少"的声明且不变，后者每次 Pick 都变）；② 用 sync.Mutex 而非 RWMutex，因为 Pick 会修改 currentWeight，是写操作；③ 第 39 行是严格大于，改成 >= 会让打平时选后一个节点，序列变成 A A C A B A A（也对，但要和单测保持一致）。另外 s.nodes = s.nodes[:0] 是"长度归零但保留底层数组容量"的常用优化，避免每次更新都重新分配内存。

写单测：把手推的 7 次序列锁进代码

// pkg/balancer/smoothwrr_test.go
package balancer

import (
	"strings"
	"testing"

	"github.com/yourname/content-community/pkg/registry"
)

// 验证 A:B:C = 5:1:1 时，连续 7 次 Pick 的序列是 A A B A C A A
func TestSmoothWRR(t *testing.T) {
	s := &SmoothWRR{}
	s.UpdateInstances([]*registry.ServiceInstance{
		{InstanceID: "A", Weight: 5},
		{InstanceID: "B", Weight: 1},
		{InstanceID: "C", Weight: 1},
	})
	var seq []string
	for i := 0; i < 7; i++ {
		ins, err := s.Pick("")
		if err != nil {
			t.Fatal(err)
		}
		seq = append(seq, ins.InstanceID)
	}
	if got, want := strings.Join(seq, " "), "A A B A C A A"; got != want {
		t.Fatalf("序列 = %q，期望 %q", got, want)
	}
}

// 验证周期性：跑满 14 次（两个周期），A 应该恰好出现 10 次
func TestSmoothWRRPeriod(t *testing.T) {
	s := &SmoothWRR{}
	s.UpdateInstances([]*registry.ServiceInstance{
		{InstanceID: "A", Weight: 5},
		{InstanceID: "B", Weight: 1},
		{InstanceID: "C", Weight: 1},
	})
	count := map[string]int{}
	for i := 0; i < 14; i++ {
		ins, _ := s.Pick("")
		count[ins.InstanceID]++
	}
	if count["A"] != 10 || count["B"] != 2 || count["C"] != 2 {
		t.Fatalf("14 次分布 = A:%d B:%d C:%d，期望 A:10 B:2 C:2",
			count["A"], count["B"], count["C"])
	}
}

验证：

go test ./pkg/balancer/ -run TestSmoothWRR -v
# 预期：
# === RUN   TestSmoothWRR
# --- PASS: TestSmoothWRR (0.00s)
# === RUN   TestSmoothWRRPeriod
# --- PASS: TestSmoothWRRPeriod (0.00s)
# PASS
# ok      github.com/yourname/content-community/pkg/balancer

第 4 步：实现随机与最少连接

目标：补齐随机与最小连接两种算法。随机几行就够；最少连接的关键是维护每个实例的"在途请求数"：Pick 选最小的并 +1，请求结束后调用 Done 减回去。

// pkg/balancer/random.go
package balancer

import (
	"math/rand"
	"sync"

	"github.com/yourname/content-community/pkg/registry"
)

// Random 随机负载均衡
type Random struct {
	mu        sync.RWMutex
	instances []*registry.ServiceInstance
}

func (r *Random) Pick(key string) (*registry.ServiceInstance, error) {
	r.mu.RLock()
	defer r.mu.RUnlock()
	if len(r.instances) == 0 {
		return nil, ErrNoInstance
	}
	// 随机数对实例数取模，流量越大分布越均匀
	return r.instances[rand.Intn(len(r.instances))], nil
}

func (r *Random) UpdateInstances(instances []*registry.ServiceInstance) {
	r.mu.Lock()
	defer r.mu.Unlock()
	r.instances = instances
}

// pkg/balancer/leastconn.go
package balancer

import (
	"sync"

	"github.com/yourname/content-community/pkg/registry"
)

// LeastConn 最少连接：选在途请求数最少的实例
type LeastConn struct {
	mu        sync.Mutex
	instances []*registry.ServiceInstance
	inflight  map[string]int // InstanceID -> 在途请求数
}

func NewLeastConn() *LeastConn {
	return &LeastConn{inflight: make(map[string]int)}
}

func (l *LeastConn) Pick(key string) (*registry.ServiceInstance, error) {
	l.mu.Lock()
	defer l.mu.Unlock()
	if len(l.instances) == 0 {
		return nil, ErrNoInstance
	}
	// 找在途数最小的（新实例没有记录相当于 0，天然优先承接请求）
	best := l.instances[0]
	for _, ins := range l.instances[1:] {
		if l.inflight[ins.InstanceID] < l.inflight[best.InstanceID] {
			best = ins
		}
	}
	l.inflight[best.InstanceID]++ // 选中即在途 +1
	return best, nil
}

// Done 一次请求结束后必须调用，在途数 -1
func (l *LeastConn) Done(instanceID string) {
	l.mu.Lock()
	defer l.mu.Unlock()
	l.inflight[instanceID]--
}

// UpdateInstances 全量替换并重建计数，避免残留已下线实例
func (l *LeastConn) UpdateInstances(instances []*registry.ServiceInstance) {
	l.mu.Lock()
	defer l.mu.Unlock()
	l.instances = instances
	l.inflight = make(map[string]int) // 重建：旧实例的计数会永久泄漏
}

三个关键点：① Go 1.20+ 全局 rand 自动播种，Go 1.19 及更早必须在 init() 里 rand.Seed(time.Now().UnixNano())；② inflight map 必须 make 初始化，否则第一次 ++ 会 panic（nil map 不可写）；③ 读不存在的 key 返回零值 0，所以新实例天然优先被选中；UpdateInstances 里重建 inflight 是为了避免已下线实例的计数永久留在 map 里造成内存泄漏。

// 写法 1（最稳）：defer 调用，任何分支都不会漏
ins, _ := lb.Pick(key)
defer lb.Done(ins.InstanceID)

// 写法 2：挂在 gRPC 的 Done 回调里（第 7 步就是这么做的）
return balancer.PickResult{
    SubConn: c,
    Done: func(ctx context.Context, di balancer.PickDoneInfo) {
        lb.Done(id) // 成功和失败都会走到这里
    },
}, nil

// ❌ 错误写法：只在成功分支调用 → 失败时计数器泄漏
if err == nil {
    lb.Done(id)
}

验证：

go build ./pkg/balancer/...
# 预期：无输出即通过

第 5 步：实现一致性哈希 ConsistentHash

目标：实现哈希环 + 虚拟节点，并写单测验证"会话保持"。

哈希环、二分查找与虚拟节点原理见 3.2.5 节。工程版直接持有 *registry.ServiceInstance，UpdateInstances 全量重建环——实例增删只影响相邻区间的 key，这正是它能做会话保持的原因。

// pkg/balancer/consistenthash.go
package balancer

import (
	"hash/crc32"
	"sort"
	"strconv"
	"sync"

	"github.com/yourname/content-community/pkg/registry"
)

// ConsistentHash 一致性哈希，默认每个真实节点 100 个虚拟节点
type ConsistentHash struct {
	mu       sync.RWMutex
	replicas int                                  // 每个真实节点的虚拟节点数
	keys     []uint32                             // 排好序的虚拟节点哈希，供二分查找
	hashMap  map[uint32]*registry.ServiceInstance // 虚拟节点哈希 -> 真实实例
}

// NewConsistentHash replicas 传 0 或负数时用默认值 100
func NewConsistentHash(replicas int) *ConsistentHash {
	if replicas <= 0 {
		replicas = 100
	}
	return &ConsistentHash{
		replicas: replicas,
		hashMap:  make(map[uint32]*registry.ServiceInstance),
	}
}

// Pick 根据 key（如 user_id）顺时针找到第一个虚拟节点对应的真实实例
func (c *ConsistentHash) Pick(key string) (*registry.ServiceInstance, error) {
	c.mu.RLock()
	defer c.mu.RUnlock()
	if len(c.keys) == 0 {
		return nil, ErrNoInstance
	}
	h := crc32.ChecksumIEEE([]byte(key))
	// 二分找第一个 >= h 的虚拟节点（顺时针方向）
	idx := sort.Search(len(c.keys), func(i int) bool { return c.keys[i] >= h })
	if idx == len(c.keys) {
		idx = 0 // 走到环尾则绕回环首
	}
	return c.hashMap[c.keys[idx]], nil
}

// UpdateInstances 全量重建哈希环（实例增删后调用）
func (c *ConsistentHash) UpdateInstances(instances []*registry.ServiceInstance) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.keys = c.keys[:0]
	c.hashMap = make(map[uint32]*registry.ServiceInstance)
	for _, ins := range instances {
		for i := 0; i < c.replicas; i++ {
			// 虚拟节点名 = 编号 + 实例ID，确保每个虚拟节点哈希不同
			h := crc32.ChecksumIEEE([]byte(strconv.Itoa(i) + ins.InstanceID))
			c.keys = append(c.keys, h)
			c.hashMap[h] = ins
		}
	}
	sort.Slice(c.keys, func(i, j int) bool { return c.keys[i] < c.keys[j] }) // 排序后才能二分
}

写单测：验证会话保持

// pkg/balancer/consistenthash_test.go
package balancer

import (
	"testing"

	"github.com/yourname/content-community/pkg/registry"
)

// 验证同一个 key 始终落到同一个实例（会话保持）
func TestConsistentHashStickiness(t *testing.T) {
	c := NewConsistentHash(100)
	c.UpdateInstances([]*registry.ServiceInstance{
		{InstanceID: "user-service-1"},
		{InstanceID: "user-service-2"},
		{InstanceID: "user-service-3"},
	})
	first, err := c.Pick("user:42")
	if err != nil {
		t.Fatal(err)
	}
	for i := 0; i < 100; i++ {
		got, err := c.Pick("user:42")
		if err != nil {
			t.Fatal(err)
		}
		if got.InstanceID != first.InstanceID {
			t.Fatalf("同一个 key 落到了不同实例：%s != %s", got.InstanceID, first.InstanceID)
		}
	}
}

// 验证分布均匀度：1000 个 key 应该比较均匀地散在 3 个实例上
func TestConsistentHashBalance(t *testing.T) {
	c := NewConsistentHash(100)
	c.UpdateInstances([]*registry.ServiceInstance{
		{InstanceID: "n1"},
		{InstanceID: "n2"},
		{InstanceID: "n3"},
	})
	count := map[string]int{}
	for i := 0; i < 3000; i++ {
		ins, _ := c.Pick("user:" + strconv.Itoa(i))
		count[ins.InstanceID]++
	}
	t.Logf("分布：n1=%d n2=%d n3=%d", count["n1"], count["n2"], count["n3"])
	// 每个实例至少分到 300 个（理想是 1000 个，一致性哈希允许偏差，但不能太离谱）
	for _, n := range []string{"n1", "n2", "n3"} {
		if count[n] < 300 {
			t.Fatalf("实例 %s 只分到 %d 个请求，数据倾斜严重", n, count[n])
		}
	}
}

验证：

go test ./pkg/balancer/ -run TestConsistentHash -v
# 预期：
# === RUN   TestConsistentHashStickiness
# --- PASS: TestConsistentHashStickiness (0.00s)
# === RUN   TestConsistentHashBalance
#     consistenthash_test.go:xx: 分布：n1=1032 n2=978 n3=990
# --- PASS: TestConsistentHashBalance (0.00s)
# PASS

第 6 步：健康检查：连续失败剔除 + 半开恢复

目标：实现一个状态机——连续 3 次调用失败（超时或 5xx）就剔除该实例，10 秒后进入"半开"状态只放一个试探请求，成功即恢复。

它是第 14 章熔断器的雏形，因此单独封装成 HealthChecker，供第 7 步的 Picker 复用。

补课胶囊 · 健康检查与"半开"状态 一句话：自动发现"连得上但已经不工作"的节点，暂时把它踢出名单，过一会儿再试探它恢复没有。 类比：你给一个朋友打电话，连着 3 次都没人接。你会想"他可能在忙，我过 10 分钟再试"——而不是每秒重拨一次，也不是从此永远不打了。10 分钟后你拨了一次，通了，说明他没事了，恢复正常联系频率。

三个状态：

状态	行为	类比
健康（Closed）	正常接流量	正常联系
剔除（Open）	完全不接流量，持续 10 秒	决定"他现在不方便，别打了"
半开（Half-Open）	只放 1 个试探请求，成功则恢复健康，失败则重新进入剔除	“我打一次试试，通了就恢复正常”

回到主线：半开状态是熔断器的精髓。第 14 章会把它扩展成完整的熔断 / 限流 / 降级体系。

// pkg/balancer/health.go
package balancer

import (
	"sync"
	"time"

	"go.uber.org/zap"
)

const (
	failThreshold = 3                // 连续失败 3 次判定不健康
	coolDown      = 10 * time.Second // 剔除 10 秒后进入半开
)

// nodeHealth 单个实例的健康状态
type nodeHealth struct {
	consecutiveFails int       // 连续失败次数
	unhealthyUntil   time.Time // 非零值表示被剔除，过了该时间点进入半开
	probing          bool      // 半开状态下是否已放出试探请求
}

// HealthChecker 实例健康状态机：正常 →（连续 3 次失败）→ 剔除 →（10 秒）→ 半开 → 成功则恢复
type HealthChecker struct {
	mu     sync.Mutex
	states map[string]*nodeHealth // key 用 InstanceID 或节点地址
}

func NewHealthChecker() *HealthChecker {
	return &HealthChecker{states: make(map[string]*nodeHealth)}
}

// Allow 判断实例当前能否被选中；半开时只放行一个试探请求
func (h *HealthChecker) Allow(id string) bool {
	h.mu.Lock()
	defer h.mu.Unlock()
	st, ok := h.states[id]
	if !ok || st.unhealthyUntil.IsZero() {
		return true // 没有记录或处于健康状态
	}
	// 冷却期已过且还没放试探请求：放一个进去
	if time.Now().After(st.unhealthyUntil) && !st.probing {
		st.probing = true
		return true
	}
	return false
}

// ReportSuccess 调用成功：清空状态，实例完全恢复
func (h *HealthChecker) ReportSuccess(id string) {
	h.mu.Lock()
	defer h.mu.Unlock()
	delete(h.states, id)
}

// ReportFailure 调用失败：连续 3 次则剔除 10 秒
func (h *HealthChecker) ReportFailure(id string) {
	h.mu.Lock()
	defer h.mu.Unlock()
	st := h.states[id]
	if st == nil {
		st = &nodeHealth{}
		h.states[id] = st
	}
	st.consecutiveFails++
	if st.consecutiveFails >= failThreshold {
		st.unhealthyUntil = time.Now().Add(coolDown)
		st.probing = false       // 重置试探标志，准备下一轮半开
		st.consecutiveFails = 0  // 重置计数，避免下次失败立刻又剔除
		zap.L().Warn("节点被暂时剔除",
			zap.String("instance", id),
			zap.Duration("retry_after", coolDown))
	} else if st.probing {
		// 半开试探请求失败：立即重新剔除。否则 probing 卡在 true，
		// Allow 永远拒绝、consecutiveFails 永远攒不到 3，节点永久"假死"
		st.unhealthyUntil = time.Now().Add(coolDown)
		st.probing = false
		st.consecutiveFails = 0
		zap.L().Warn("节点半开试探失败，重新剔除",
			zap.String("instance", id),
			zap.Duration("retry_after", coolDown))
	}
}

逐行讲解

冷却期结束
   ↓
第 1 个请求进来 → probing 从 false 变 true，放行 ✅
第 2 个请求进来 → probing 已是 true，拒绝 ❌
第 3 个请求进来 → probing 已是 true，拒绝 ❌
   ↓
试探请求返回
   ├─ 成功 → ReportSuccess → 删除记录 → 完全恢复 ✅
   └─ 失败 → ReportFailure → 立即重新剔除（重新进入冷却期）

验证：

go build ./pkg/balancer/...
# 预期：无输出即通过（剔除效果第 8 步实测）

第 7 步：注册为 gRPC 负载均衡策略

目标：把前面写的算法接进 gRPC，注册两个策略名，并让健康检查与 Picker 联动。

Picker 骨架与 3.4.6 节相同，这一步补齐工程细节：

• 注册 weighted_round_robin 和 consistent_hash 两个策略名
• 权重从 Address.Attributes 读（Address.Metadata 已弃用，见 3.4.6 的坑）
• 一致性哈希的 key 从 metadata 的 x-user-id 取
• Done 回调接健康检查

先给第 12 章的 Resolver 做一处增量修改，把权重随地址带给 Picker：

// pkg/registry/resolver.go —— resolve() 内的增量修改
// === 新增/修改开始 ===
// 原来是：addrs = append(addrs, resolver.Address{Addr: ins.Addr()})
addrs = append(addrs, resolver.Address{
	Addr:       ins.Addr(),
	Attributes: attributes.New("weight", ins.Weight), // 权重随地址带给 Picker
})
// === 新增/修改结束 ===
// import 区新增："google.golang.org/grpc/attributes"

先看一眼权重的完整旅程：从 etcd 里躺着的 Weight 字段，到真正被挑中发请求的那条连接，要经过下图这几棒接力——正文的每一段代码，都在给图上的某条边补实现。

flowchart LR
    subgraph ETCD["注册中心 etcd"]
        E["/services/user/*
实例信息含 Weight 字段"]
    end
    subgraph RES["Resolver（第 12 章改造）"]
        RV["watch 实例变化"] --> RA["resolver.Address
Attributes 携带 weight（int）"]
    end
    subgraph BAL["Balancer（本章核心新文件）"]
        BC["buildConns
按 int 断言取出权重"]
        WRR["平滑加权轮询 Picker"]
        CH["一致性哈希 Picker
key = x-user-id"]
        HC["健康检查
Done 回调上报失败"]
    end
    SC["SubConn 发起真正的 RPC"]
    E -->|"变更推送"| RV
    RA -->|"PickerBuildInfo"| BC
    BC --> WRR
    BC --> CH
    WRR --> SC
    CH --> SC
    SC -.->|"请求结束"| HC
    HC -.->|"连续失败剔除节点"| BC

这张图怎么读：权重沿实线正向传递——etcd 里 /services/user/* 的 Weight 字段经「变更推送」到达 Resolver 的 watch，Resolver 把它塞进 resolver.Address 的 Attributes（int 类型），再随 PickerBuildInfo 交给 Balancer 侧的 buildConns 按 int 断言取出；随后分两路：平滑加权轮询 Picker 和一致性哈希 Picker（key 取自请求里的 x-user-id）各自选出节点，交给 SubConn 发起真正的 RPC。虚线是失败回路：请求结束后由 Done 回调向健康检查上报结果，连续失败的节点被剔除并反馈给 buildConns，下一轮构建 Picker 时它就不再参与选择。本步之后的代码，就是在逐条实现这些边。

然后是本章的核心新文件：

// pkg/balancer/picker.go
package balancer

import (
	"context"
	"hash/crc32"
	"sort"
	"strconv"
	"sync"

	"google.golang.org/grpc/balancer"
	"google.golang.org/grpc/balancer/base"
	"google.golang.org/grpc/metadata"
	"google.golang.org/grpc/resolver"
)

const (
	// WRRName 平滑加权轮询策略名，客户端 ServiceConfig 里填它
	WRRName = "weighted_round_robin"
	// ConsistentHashName 一致性哈希策略名
	ConsistentHashName = "consistent_hash"
)

func init() {
	// 连接管理交给 gRPC 官方 base 骨架，我们只提供 Picker（分工见 3.4.7 节）
	balancer.Register(base.NewBalancerBuilder(WRRName, &wrrPickerBuilder{}, base.Config{HealthCheck: true}))
	balancer.Register(base.NewBalancerBuilder(ConsistentHashName, &chPickerBuilder{}, base.Config{HealthCheck: true}))
}

// connInfo 把 SubConn、地址、权重绑在一起
type connInfo struct {
	conn   balancer.SubConn
	addr   resolver.Address
	weight int
}

// buildConns 从就绪连接里取权重（Resolver 已写入 Attributes）
func buildConns(info base.PickerBuildInfo) []*connInfo {
	conns := make([]*connInfo, 0, len(info.ReadySCs))
	for sc, sci := range info.ReadySCs {
		w := 1 // 默认权重
		if v, ok := sci.Address.Attributes.Value("weight").(int); ok && v > 0 {
			w = v
		}
		conns = append(conns, &connInfo{conn: sc, addr: sci.Address, weight: w})
	}
	return conns
}

// doneFunc 两个 Picker 共用的 RPC 结束回调：失败上报健康检查，成功则恢复
func doneFunc(h *HealthChecker, id string) func(context.Context, balancer.PickDoneInfo) {
	return func(ctx context.Context, di balancer.PickDoneInfo) {
		if di.Err != nil {
			h.ReportFailure(id)
			return
		}
		h.ReportSuccess(id)
	}
}

// pkg/balancer/picker.go（续）—— 策略一：平滑加权轮询
// ---------- 策略一：平滑加权轮询 ----------

type wrrPickerBuilder struct{}

// Build 在就绪连接变化时被调用，重建 Picker 的同时重置 currentWeight（见第 3 步的坑）
func (b *wrrPickerBuilder) Build(info base.PickerBuildInfo) balancer.Picker {
	conns := buildConns(info)
	if len(conns) == 0 {
		return base.NewErrPicker(balancer.ErrNoSubConnAvailable)
	}
	return &wrrPicker{
		conns:   conns,
		current: make([]int, len(conns)), // 与 conns 下标对齐的 currentWeight
		health:  NewHealthChecker(),
	}
}

type wrrPicker struct {
	mu      sync.Mutex
	conns   []*connInfo
	current []int
	health  *HealthChecker
}

func (p *wrrPicker) Pick(info balancer.PickInfo) (balancer.PickResult, error) {
	p.mu.Lock()
	defer p.mu.Unlock()
	// 步骤 1：先用健康检查过滤，活着的节点 currentWeight += weight
	idxs := make([]int, 0, len(p.conns))
	total := 0
	for i, c := range p.conns {
		if !p.health.Allow(c.addr.Addr) {
			continue // 被剔除的节点不参与选择
		}
		idxs = append(idxs, i)
		total += c.weight
		p.current[i] += c.weight
	}
	if len(idxs) == 0 {
		return balancer.PickResult{}, balancer.ErrNoSubConnAvailable
	}
	// 步骤 2：选 currentWeight 最大的节点
	best := idxs[0]
	for _, i := range idxs[1:] {
		if p.current[i] > p.current[best] {
			best = i
		}
	}
	// 步骤 3：选中节点扣掉总权重（"还债"）
	p.current[best] -= total
	id := p.conns[best].addr.Addr
	return balancer.PickResult{SubConn: p.conns[best].conn, Done: doneFunc(p.health, id)}, nil
}

// pkg/balancer/picker.go（续）—— 策略二：一致性哈希
// ---------- 策略二：一致性哈希 ----------

type chPickerBuilder struct{}

func (b *chPickerBuilder) Build(info base.PickerBuildInfo) balancer.Picker {
	conns := buildConns(info)
	if len(conns) == 0 {
		return base.NewErrPicker(balancer.ErrNoSubConnAvailable)
	}
	p := &chPicker{health: NewHealthChecker(), ring: make(map[uint32]*connInfo)}
	for _, c := range conns {
		for i := 0; i < 100; i++ { // 每个连接 100 个虚拟节点，解决数据倾斜
			h := crc32.ChecksumIEEE([]byte(strconv.Itoa(i) + c.addr.Addr))
			p.keys = append(p.keys, h)
			p.ring[h] = c
		}
	}
	sort.Slice(p.keys, func(i int, j int) bool { return p.keys[i] < p.keys[j] })
	return p
}

type chPicker struct {
	mu     sync.RWMutex
	keys   []uint32             // 排好序的虚拟节点哈希
	ring   map[uint32]*connInfo // 虚拟节点哈希 -> 连接
	health *HealthChecker
}

func (p *chPicker) Pick(info balancer.PickInfo) (balancer.PickResult, error) {
	// 一致性哈希的 key 从请求 metadata 取（业务侧提前 set 进 x-user-id）
	key := ""
	if md, ok := metadata.FromOutgoingContext(info.Ctx); ok {
		if v := md.Get("x-user-id"); len(v) > 0 {
			key = v[0]
		}
	}
	p.mu.RLock()
	defer p.mu.RUnlock()
	// 步骤 1：key 落环，二分找顺时针第一个虚拟节点
	h := crc32.ChecksumIEEE([]byte(key))
	idx := sort.Search(len(p.keys), func(i int) bool { return p.keys[i] >= h })
	// 步骤 2：从命中点顺时针扫描，跳过刚被健康检查剔除的节点
	for n := 0; n < len(p.keys); n++ {
		c := p.ring[p.keys[(idx+n)%len(p.keys)]]
		if p.health.Allow(c.addr.Addr) {
			return balancer.PickResult{SubConn: c.conn, Done: doneFunc(p.health, c.addr.Addr)}, nil
		}
	}
	return balancer.PickResult{}, balancer.ErrNoSubConnAvailable
}

逐行讲解（挑最关键的三处）

客户端接入（post-service）

只需匿名引入 + 指定策略名：

// cmd/post-service/main.go —— 修改：匿名引入 + 指定策略
import (
	_ "github.com/yourname/content-community/pkg/balancer" // 只为触发 init() 注册两个策略

	"google.golang.org/grpc"
)

conn, err := grpc.Dial(
	"etcd:///user-service",
	grpc.WithDefaultServiceConfig(`{"loadBalancingConfig":[{"weighted_round_robin":{}}]}`),
)

验证：

go build ./...
# 预期：无输出即通过

第 8 步：起两个实例实测

目标：用真实流量验证权重分布、会话保持、故障转移三个特性。

策略名放进配置（viper 读取，换算法不用改代码）：

# configs/post-service.yaml —— 新增配置项
grpc:
  balancer: weighted_round_robin # 想验证会话保持就换成 consistent_hash

// cmd/post-service/main.go —— 策略名从配置读，替换第 7 步的硬编码
import (
	"fmt"

	"github.com/spf13/viper"
)

policy := viper.GetString("grpc.balancer")
if policy == "" {
	policy = "weighted_round_robin" // 兜底默认值
}
svcCfg := fmt.Sprintf(`{"loadBalancingConfig":[{%q:{}}]}`, policy)
conn, err := grpc.Dial("etcd:///user-service",
	grpc.WithDefaultServiceConfig(svcCfg),
)

{"weighted_round_robin":{}}

实测流程

# 终端 1/2：起两个 user-service 实例，权重分别 5 和 1
# （weight 随注册进 etcd，见第 12 章）
go run ./cmd/user-service -port 9090 -weight 5
go run ./cmd/user-service -port 9091 -weight 1

# 终端 3：跑本章全部单测
go test ./pkg/balancer/... -v
# 预期：TestSmoothWRR、TestSmoothWRRPeriod、
#       TestConsistentHashStickiness、TestConsistentHashBalance 全部 PASS

# 终端 3：post-service 连发 7 次调用，观察两个实例各自打印的请求日志
go run ./cmd/post-service
# 预期：7 次请求约 5 次落在 9090、2 次落在 9091
#       且 9090 不会被连续打满（这就是"平滑"的意义）

# 把配置换成 consistent_hash 再跑：
# 预期：同一个 user_id 的请求只会出现在其中一个实例的日志里

# 故障演练：kill 掉 9090 的进程
# 预期：实例下线的场景，约 10 秒（etcd 租约到期 + Resolver 推送）后流量全到 9091
#       实例还在但连续报错的场景，3 次失败即被健康检查剔除，秒级转移