压测报告很漂亮：goroutine 十万级、QPS 破万、P99 个位数毫秒。测试环境往往是单服务、单库、池子没上限——和生产的拓扑差一个数量级。上线第三周，订单服务在晚高峰把 PostgreSQL 的 max_connections 打满，Inventory 熔断器全线打开，链路追踪在 Jaeger 里断成三截——监控上看起来像是「三个独立故障同时发生」，值班群却找不到「第一个坏掉的人」。这类组合在拆服第一年周报里反复出现（典型合成场景，非单一客户事故）。

这类故事在单体拆微服务的第一年太常见。团队往往对 Go 的并发模型有信心——go test -race 过了、 pprof 里 goroutine 曲线平——却对进程边界之外的四件事缺手感：服务间协议怎么分层、trace 怎么传、熔断怎么配、连接池在多副本下怎么算预算。单体时代这些问题被「一个进程、一个连接池、一条调用栈」藏起来了；拆成十几个 Deployment 之后，它们变成乘法。

这篇不重复「该不该拆微服务」（同系列已发），也不展开 RPC 与 HTTP 的选型辩论。只回答一个问题：Go 微服务在峰值到来前，你要算清什么、配什么、先验什么。 本文交付的是治理链 + 四预算思维模型 + 检查表 + 可复现实验，不是按服务逐步部署的 step-by-step 教程。

峰值问题几乎总是乘法——副本 × 连接 × 链深度 × 超时 × 采样率。Go 解决的是单机并发效率，乘法在集群拓扑里。正文含 4 组本地 sleep/算术实验（🟢）、2 项推演（🟡）、2 条 staging 验收清单（🟢）；连接池 churn 归入连接预算子问题。详细分层见附录。

治理链：一条请求的四道安检

治理链（Governance Chain）——我用来指一条用户请求从进来到落地数据库，必须经过的四层约束。缺任何一层，平常流量下都可能「看起来没问题」，峰值或故障时一起爆。

1. 入口协议层：对外 HTTP/JSON，对内 gRPC/Protobuf；BFF 与核心域服务分开。
2. Context 传播层：W3C traceparent 写入 context.Context，出站调用必须带出。
3. 出站韧性层：超时、重试（幂等才重试）、熔断、限流——都在 client 侧，不指望「下游会好起来」。
4. 数据层预算层：(副本数 × MaxOpenConns) × 服务数 ≤ DB max_connections × (1 - 预留率)（conn-budget 代码里可用比例 0.8，即预留 20% 给运维会话）。

用一张简图记：Client → Gateway(HTTP) → BFF → gRPC 域服务 A → gRPC 域服务 B → DB，每一跳箭头都要能回答：协议是什么、ctx 传了吗、timeout 多少、breaker 名是什么、这一 hop 占几条 DB 连接。新服务评审就按这五问走，五问清单可在评审会上逐项签字。

重点在排障顺序：P99 飙高时，按链路的四层从上往下查，避免同时改五个 YAML。

你团队如果在立项阶段只做了「选型 gRPC + 上 OTel + 引 gobreaker」，但四层之间没有串联验收，治理链是一条验收路径：每加一个新服务，问它在这四层上接上了没有。

入口协议：对内 gRPC contract-first，对外 HTTP/JSON 或 gRPC-Gateway，BFF 与核心域分离（详见峰值教训（上）教训 1）。Context 传播：otelhttp/otelgrpc 只解决当前 hop；验收方法见峰值教训（上）教训 2。出站韧性：超时、熔断、限流在 client 侧配齐，重试只对幂等开放。数据层预算：第二章展开，前三层配错最终会体现在 WaitCount 和 too many connections 上。

Mesh 与进程内治理的边界：Sidecar 代理 hop，连接池仍在本进程，不会替你算 PostgreSQL 总连接数。Mesh 适用边界见第六章。

四个隐形预算：扩副本之前先算清

拆服之后，有四个「预算」在平常流量下几乎看不见。它们不像 CPU 利用率那样直观，却在峰值夜一次性结账。下面每个预算给出算式与验法。

预算 1：数据库连接数

Go 的 database/sql 默认 MaxOpenConns=0，意思是不限制。🟢 官方文档行为。对单进程开发很友好，对多副本微服务是陷阱——每个 Pod 都能无上限开连接，PostgreSQL 却在另一头数 max_connections。

我跑了一个纯算术模型（evidence/code/conn-budget，Go 1.24）：PostgreSQL max_connections=100，预留 20% 给运维会话，可用上限 80。三个服务——order 4 副本、inventory 4 副本、payment 3 副本——各配 MaxOpenConns=25：

275 对 80，还没算连接泄漏，预算已经爆表。🟢 conn-budget 算术可复现。完整五列表（含 MaxOpen 单列）见下图；手机端读上表三列即可。

连接池四参数要一起配，不要只改 MaxOpenConns：

db.SetMaxOpenConns(25)
db.SetMaxIdleConns(25)              // 与 MaxOpen 对齐，减 churn
db.SetConnMaxLifetime(30 * time.Minute)
db.SetConnMaxIdleTime(5 * time.Minute)

所有查询走 QueryContext(ctx, ...)，ctx 必须携带 Gateway 透传的 deadline（或 context.WithTimeout(parent, remaining)）。单池排队机理见同系列《连接池里的队伍》；本篇只强调多服务乘法——全集群 Σ(replicas × MaxOpenConns) 必须 ≤ DB 上限 × 0.8。

预算 2：连接池 churn

MaxIdleConns 远小于 MaxOpenConns 时，负载下 idle 连接会被频繁回收再重建。真实 PG 上还有 TCP 握手 + 认证成本；本实验用 sleep driver（evidence/code/pool-churn）隔离 idle 回收效应，不测波形 idle→突刺，也不测握手延迟。

先看 MaxIdleClosed 与 WaitCount：MaxOpen=20，并发 40、200 请求（每 query sleep 20ms）：

两组在过载下 WaitCount 都是 180，瓶颈仍是池相对并发太小。warm 组 MaxIdleClosed=0，说明 idle 上限对齐后不会在负载下额外关连接。本实验不以 P99 作主张依据：churn 组 P99 略低来自排队形态差异，读数应看 MaxIdleClosed；波峰切换叠加握手成本需 staging 或真实 PG 补证。

内网 steady 负载下，建议 MaxIdleConns = MaxOpenConns，并设 ConnMaxLifetime 小于上游 LB/代理的空闲杀连接时间。Spiky 负载若刻意缩小 idle，应配合 ConnMaxIdleTime 渐进释放。

预算 3：跨服务超时链

一层 client timeout 3s，三层串行最坏是 timeout 相加得 9s——常见误配是以为只有 3s。🟡 逻辑推演（见 evidence/data/timeout-chain.md），非压测，但和线上「Gateway 30s、中间 10s、下游 5s」叠出来的怪延迟一致。

200 并发请求若都卡在 9s 窗口里，单进程就挂 200 个 goroutine 等下游。Go 扛得住，但你的 SLA 扛不住，而且占满 HTTP/2 stream、gRPC channel 和 DB 池 slot——超时链和连接预算会联动爆。

常见误配：每层各自「给宽裕一点」，没有人做加法。改法是在 Gateway 写死用户可见 deadline（例如 2s），向内逐层递减；client timeout 应小于剩余 deadline。并行 outbound 取 max，串行路径取 sum；清单应按调用图 DAG 算最坏路径。

幂等与 retry：POST 下单除非有 Idempotency-Key，否则 client 不应自动 retry。读请求可以 retry 一次，但必须带同一 ctx deadline 的剩余时间。

内网 sync 调用 client timeout 常见量级 500ms–1s（同 AZ）；fan-out / GraphQL 等多 outbound 路径按调用图 DAG 单独算 worst case。

预算 4：Trace 采样内存

OpenTelemetry 全量 head sampling 在高 QPS 下有 OOM 报告（open-telemetry/opentelemetry-go #7748）。🟡 社区案例，本篇未跑本地 RSS 对比——但 span 对象、属性、事件在 End() 前都占堆，采样率是 trace 成本的第一杠杆。

Go 侧最小初始化（与 breaker-trip 同级可直接抄）：

tp := sdktrace.NewTracerProvider(
    sdktrace.WithSampler(sdktrace.ParentBased(
        sdktrace.TraceIDRatioBased(0.1),
    )),
    sdktrace.WithBatcher(exporter),
)
otel.SetTracerProvider(tp)

ParentBased 保证下游跟上游决策一致。BatchSpanProcessor 队列满时丢 span、不阻塞业务。Tail sampling 需 Collector 侧更大内存，第一年通常用不到。Collector 侧从 memory limiter + batch 起步；大规模实践常见做法是限制 head ratio + 控制 export batch，而非第一天堆多层 processor。

dev 环境可 100% 采样，prod 用 TRACE_SAMPLE_RATIO 环境变量区分；CI lint prod manifest 不允许 1.0 head ratio。

峰值教训（上）：协议分层与 trace 断裂

拆服团队问得最多的两个通信问题：「全 gRPC 行不行？」「Jaeger 上了但查不到完整链路」。协议选错增加协作成本，trace 断掉则把多 hop 变回「多个单点 mystery」。下面两节各给一条可在 staging 当场执行的验收动作，不替代同系列 RPC 文的契约深度，但够你在发布前挡住 80% 的「查不到链」类工单。

教训 1：内网 gRPC、对外 HTTP，中间要有 BFF

边缘 HTTP/JSON（或 gRPC-Gateway）；核心域 gRPC + Protobuf。RPC 契约与韧性见同系列 RPC 文。落地检查：PR 模板加「对外协议？」「是否经 BFF？」；禁止核心域直暴露 HTTP 给 App。

教训 2：Trace 断在 context 没传下去

峰值夜要先定位慢在哪一跳。漏传 context 一次，Jaeger 里就是三条 unrelated trace。

验收：staging 固定 trace id 打一次端到端，Export 到 Jaeger，hop 数等于调用深度。示例：Gateway 注入 traceparent，对 BFF 打 curl -H 'traceparent: 00-{fixed-id}-01' https://staging/api/order/{id}，在 Jaeger 按 trace id 搜索，数 span 条数是否等于 Gateway→BFF→Order→Inventory 四跳。出站 gRPC 用 otelgrpc，HTTP 用 otelhttp，Kafka 注入 W3C header。🟢 我未在本地复现三服务截图，传播是机械动作，对了 staging 一次就能验。

高频断点：middleware goroutine 用 Background()；channel worker 没存 trace ctx；gRPC interceptor 漏装；DB 查询没用请求 ctx。slog/zap 注入 trace id，日志与 trace 互跳。

峰值教训（中）：熔断误配与连接池打满

服务治理里最容易「配了等于没配」的两项：熔断把业务错误当宕机，连接池把 WaitCount 当成 SQL 慢。两者在监控上的症状都是 P99 升高，但解法完全不同——前者改 IsSuccessful，后者改预算或池大小。

教训 3：熔断器把 NotFound 当成宕机

gobreaker 默认把非 nil error 都记失败。gRPC 的 NotFound 是业务语义，应视为成功调用。

我写了 20 次连续 NotFound 的对比（evidence/code/breaker-trip）：

误 trip 之后，正常业务错误会把 dependency 人为判死刑，高峰期等于自杀。IsSuccessful 必须区分 client error 与 server/unknown error，是 gRPC client 上线 checklist 第一项。

实验代码里 ReadyToTrip 设为连续 5 次失败打开；open 后调用方收到 gobreaker.ErrOpenState fast-fail，half-open 才放探测请求。生产里还要调 Interval、Timeout 探活频率。

和 retry 的关系：4xx 不应 retry；5xx 有限 retry 必须带 backoff 和总 deadline。熔断 open 时直接走降级/cache，别在 breaker 外再套一层 blind retry。

下面这段 IsSuccessful 写法与实验 breaker-trip 一致，可直接放进 gRPC client 包装：

IsSuccessful: func(err error) bool {
    if err == nil {
        return true
    }
    st, ok := status.FromError(err)
    if !ok {
        return false
    }
    switch st.Code() {
    case codes.InvalidArgument, codes.NotFound, codes.AlreadyExists,
        codes.PermissionDenied, codes.Unauthenticated:
        return true // 业务/客户端错误，不累计失败
    default:
        return false
    }
},

PermissionDenied / Unauthenticated 是否计失败取决于团队策略：默认计成功是为避免鉴权配置抖动误 trip，但应对 403/401 配独立告警，而非指望 breaker 替你发现。

教训 4：三跳链共享小池，WaitCount 比慢查询先爆

限定：本实验在单进程、单连接池内连续三次 QueryContext（evidence/code/chain-pool），隔离「链深度 × 池上限」，不模拟三 Pod 各持一池。串行三查 vs 跨服务并行占槽是两种预算模型；后者需按调用图叠加同时 in-flight。多 Pod 场景见上文连接预算表。

实验条件：MaxOpen=5，并发 30，每请求 3 次查询（每次 sleep 15ms）：

P99 半秒级，但 WaitCount 353、WaitDuration 累计约 26s 说明大量时间在等连接，SQL 本身仅 ~45ms。15ms × 3 与 549ms P99 差一个数量级，池排队是主导项。慢查询优化之前，先看 db.Stats().WaitCount 是否长期大于零。

峰值教训（下）：OTel 采样与「峰值夜」剧本

可观测性在立项书里往往排最后——「功能上线后再接」。结果是 peak 来了，指标只有 CPU 和 QPS，trace 要么全采样把 Pod OOM，要么采样太低抓不到慢请求。教训 5 讨论的是观测本身的预算；后面的剧本则把五条教训串成一次 drill。

教训 5：可观测性先保命，再求全

采样与内存预算见第二章「预算 4」——ParentBased 10%、SDK/Collector 分工、无本地 RSS benchmark。峰值 drill 额外强调：指标别踩高基数坑（user_id/order_id 进 span attribute 会让 cardinality 爆炸）；保留 service.name、http.route、gRPC method 就够排障，用户关联走日志 trace id。

第一年最小集：OTLP export + BatchSpanProcessor + ParentBased 10% + 结构化日志带 trace id。Metrics（RED/USE）与 trace 互补。

峰值夜剧本（场景模拟）

把五条教训串起来，一个合理的故障注入顺序是（合成演练剧本，非单一真实事故）：

1. 20:00 促销流量 3 倍，Gateway timeout 仍 3s×3 层
2. 20:07 Inventory DB 池 wait 升高，P99 尚未报警（阈值只看 CPU）
3. 20:12 某次发布漏传 trace context，值班在三个服务各查 40 分钟
4. 20:25 用户 id 不存在激增，熔断误 trip，Inventory 假死
5. 20:40 PG too many connections，全站只读

值班若按「三个独立故障」并行拉人，会在 20:40 才发现根因其实是 20:00 的超时链 + 20:07 就开始的 pool wait。按治理链排障顺序有助于避免并行误判：超时链/deadline → 连接预算 → trace 是否断 → breaker 状态 → SQL explain。

合成剧本，用于 table-top：按时间线念剧本，团队写「第 N 分钟看哪个指标、改哪条配置」。演练产出物：① 连接预算表 diff；② outbound timeout 清单更新；③ trace 抽检记录（hop 数 vs 预期）。

和单体时代的习惯对照

拆服要把上面这张对照表的每一行都工程化一遍。Go 让 goroutine 很便宜，前几列才是第一年学费。

上线前：一张表收束

下面这张表可以直接贴进 wiki。每一项都应能指到 owner 和验证命令（例如 curl staging trace、db.Stats() 导出、连接预算 spreadsheet）。

Service Mesh：什么时候才值得

Istio/Linkerd 适合服务数量多、语言杂、合规强的阶段。Go 单栈团队用进程内 gobreaker + otelgrpc 往往更快落地。Mesh 是组织复杂度到了必须抽离时的工具，治理链四层在 Mesh 前后都成立，只是第三层部分能力换实现位置。

Go 的 goroutine 让你敢开并发，但微服务的峰值往往在进程外：连接、context、熔断、采样。连接预算表、timeout 清单、breaker 配置应在 staging soak 里验过（2× QPS、10 分钟，看 WaitCount 与 trace 完整性）。发布先单 AZ、单副本池变更，观察 30 分钟再全量。

如果团队正在拆第一刀，欢迎留言你们的连接预算表长什么样。

附录：实验代码和原始数据

本文含 4 组本地实验 + 2 项推演 + 峰值夜剧本（anchor_2 口径）。代码和结果已开源：

GitHub：zhiyulab-evidence/go-microservices-production

每个 code/* 目录可 go run . 复现（pool-churn/chain-pool 为 sleep driver，无需真实 PG）。环境：breaker-trip 需 Go 1.25+ toolchain；其余 1.24+。

原文发布于 止语Lab