2. 负载均衡的流量模型与性能指标

负载均衡系统的容量规划，本质上是在回答一个问题：在给定业务SLA的前提下，需要多少台后端服务器、多大的入口带宽、多高的新建连接处理能力，才能让用户感知到的服务质量稳定达标。要回答这个问题，必须先建立一套统一的流量模型和性能指标体系，否则“够不够用”只能靠感觉判断。

一、六个核心指标的定义与观测位置

负载均衡的性能指标必须绑定观测点，否则同一名称在不同位置含义不同。以下指标均以负载均衡器（LB）为观测主体，区分“入口侧”和“后端侧”。

• 吞吐量（Throughput）：单位时间内成功转发的有效载荷，通常用 Mbps 或 Gbps 表示。注意区分“七层吞吐”和“四层吞吐”：四层吞吐只统计转发字节，七层吞吐还要扣除 TLS 加解密和 HTTP 解析开销，同一硬件两者可能相差数倍。
• 并发连接数（Concurrent Connections）：某一时刻 LB 上处于 ESTABLISHED 状态的连接总数。它决定内存占用，因为每条连接都要维护会话表项、缓冲区、定时器。长连接业务（如 WebSocket、gRPC 流）的并发连接数会远高于短连接业务。
• 新建连接速率（CPS，Connections Per Second）：每秒成功建立的新连接数。它考验的是 CPU 中断处理、TLS 握手、会话表插入能力，而不是带宽。短连接业务（如 HTTP/1.1 无 keep-alive）的 CPS 压力极大。
• 时延（Latency）：从客户端发出请求到收到响应的总时间。在 LB 视角可拆为：入队时延、转发时延、后端处理时延、回程时延。P99 时延比平均值更能反映用户体验，因为平均值会被大量快请求拉低。
• 丢包（Packet Loss）：LB 因队列满、后端不可用或健康检查失败而丢弃的报文比例。丢包会触发 TCP 重传，直接放大时延，是 SLA 中最敏感的指标之一。
• 后端健康度（Backend Health）：健康后端数量占总后端数量的比例，以及健康检查的探测周期与失败阈值。健康度下降会直接减少可用容量，是容量估算中必须预留的冗余因子。

二、从业务SLA推导负载均衡目标

SLA通常由业务方以“可用性、时延、错误率”三个维度给出，例如“核心接口可用性 99.95%，P99 时延不超过 200ms，错误率低于 0.1%”。这些是端到端承诺，不能直接当作 LB 的配置目标，需要做一次分解。

以可用性 99.95% 为例，全年允许不可用时间约为 4.38 小时。这 4.38 小时要分配给 LB 自身故障、后端故障、依赖服务故障、发布变更等多个环节。工程上通常给 LB 层分配不超过 20% 的预算，即约 52 分钟。这意味着 LB 集群必须做到多可用区部署、健康检查秒级生效、故障实例自动摘除，且单点故障不能导致整体不可用。

时延目标同样需要分解。若端到端 P99 为 200ms，其中网络往返约 30ms、后端处理约 120ms，则留给 LB 的转发与排队时延预算约 50ms。这个数字直接约束了 LB 的队列深度和调度策略：队列过长会推高排队时延，队列过短会丢包。实际调优时，常把 LB 的 P99 转发时延控制在 10ms 以内，为后端抖动留出余量。

错误率 0.1% 对应每 1000 个请求最多 1 个失败。LB 层的错误来源主要是：健康检查误判导致请求打到故障后端、连接池耗尽、TLS 握手失败。因此健康检查的失败阈值和探测间隔必须与错误率预算匹配——探测间隔过长会延长故障暴露时间，过短则可能因瞬时抖动误摘健康节点。

三、容量估算：从峰值QPS到实例数

容量估算的起点是业务峰值 QPS，而不是平均值。通常取日常峰值的 2～3 倍作为设计峰值，或直接使用历史最高值的 1.5 倍。假设某业务设计峰值为 8000 QPS，平均请求大小 15KB，平均连接时长 2 秒（keep-alive 场景），则：

吞吐量需求 = 8000 QPS × 15 KB × 8 = 960 Mbps ≈ 1 Gbps
并发连接数 = 8000 QPS × 2 s = 16000 条
新建连接速率 = 8000 CPS（若 keep-alive 命中率高，实际 CPS 可降至 800～1600）

得到这三个数字后，再对照单台 LB 的实测能力做除法，并叠加冗余系数。冗余系数要考虑两部分：一是健康度冗余，若要求任意一台后端故障不影响容量，则后端实例数至少为 N+1；二是突发冗余，通常取 1.3～1.5。例如单台 LB 实测可承载 5000 CPS、20000 并发连接、2Gbps 吞吐，则按 CPS 瓶颈计算需要 8000/5000×1.4≈2.24，向上取整为 3 台；按并发连接计算需要 16000/20000×1.4≈1.12，取 2 台。最终取最大值 3 台，并确保这 3 台分布在不同可用区。

四、压测指标选取与结果判读

压测不是把 QPS 打到最高就结束，而是要验证“在 SLA 约束下能承载多少”。因此压测指标必须与 SLA 指标对齐，至少采集以下五组：

压测执行时采用阶梯加压：从设计峰值的 50% 开始，每 3 分钟增加 25%，直到 P99 时延超过 SLA 预算或错误率突破 0.1%。记录每个阶梯的指标值，绘制“QPS—P99 时延”曲线。曲线的拐点就是当前配置下的实际容量上限。若拐点远低于设计峰值，需要定位瓶颈：是 LB 的 CPU 打满、会话表满，还是后端处理能力不足。定位方法是对比入口侧和出口侧的 CPS 与并发连接数——若入口 CPS 高但出口 CPS 低，说明 LB 转发环节有丢包或队列溢出；若两侧接近但后端错误率高，则瓶颈在后端。

五、健康度对有效容量的影响

后端健康度不是独立指标，它直接折损有效容量。若健康检查探测间隔为 5 秒、失败阈值为 3 次，则一个后端从故障到被摘除最长需要 15 秒。在这 15 秒内，部分请求仍会被调度到故障节点，产生错误。若业务错误率预算为 0.1%，而故障节点占比 1/10，则这 15 秒内错误率可能达到 10%，远超预算。因此高可用业务通常把探测间隔缩短到 1～2 秒、失败阈值降到 2 次，并配合被动健康检查（根据真实请求的失败率快速摘除）。

容量估算时，有效后端数应按“健康后端数”计算，而不是“总后端数”。若要求任意一台故障不影响容量，则设计容量必须由 N-1 台健康后端承担。这就是为什么容量估算的最后一步总是：用设计峰值除以单台后端能力，再除以（1 - 冗余比例），向上取整。

把上述指标、推导链和估算方法固化为一张容量规划表，每次业务变更时重新填写，就能让负载均衡容量从“经验判断”变成“可复核的工程计算”。