企业官网建设流程全解析

我们在生产环境里跑过几十台节点的集群，也折腾过从几百 QPS 到几万 QPS 的流量变化，负载均衡这块我踩过的坑比看过的文档多得多。很多人一开始以为负载均衡就是把请求轮询发到几台机器上，等真正上了集群才发现，连接不均衡、数据倾斜、故障误判、会话丢失，每一个问题都能让你从凌晨三点排查到天亮。

这篇文章以我在多个集群项目里的实操经验为基底，把集群负载均衡的几个关键环节拆开讲：均衡策略选型、健康检查设计、故障转移链路、分层架构搭配，以及数据集群和 AI 算力集群里的特殊处理。文章不会只讲理论，每个部分都会给出可落地的参数、配置思路和排查路径，对正在搭 Hadoop、Redis、Kafka、Doris 或微服务网关集群的工程师都有参考价值。

1. 从单机到集群：负载均衡要解决的三个本质问题

先想清楚一个问题：我们做负载均衡，到底在均衡什么？流量？连接？数据？还是计算资源？

如果只理解为“把请求分到不同机器”，那写一个轮询脚本就够了，根本不需要研究集群负载均衡。实际上，集群环境下的负载均衡比单机时代复杂得多，核心要解决三个本质问题。

1.1 请求分散只是表面，状态一致性才是深层约束

集群最大的优势是水平扩展，但一旦引入多节点，状态一致性问题就来了。举个最简单的例子：一个 Web 应用用 Session 保存用户登录态，单机时代 Session 就在本机，随手可取。上了集群之后，用户的请求轮流打到 A、B、C 三台机器，Session 在 A 机器上，下次请求打到 B 机器，如果 B 机器没有 Session，用户就被踢下线了。

这就是为什么负载均衡策略里会有“会话保持”这个选项。常见的做法有几种：

• 源地址哈希：根据客户端 IP 做哈希，同一个 IP 固定打到同一台后端节点。实现简单，但只解决了“会话保持”，没解决“数据均衡”——如果一个公司 NAT 出口就一个 IP，那这个 IP 下所有用户全挤到一台机器上。
• Cookie 会话保持：七层负载（比如 Nginx、网关）在用户请求里写入 Cookie，后续请求根据 Cookie 路由到对应节点。比源地址哈希更精准，但要求负载均衡器能解析七层协议。
• 共享会话存储：把 Session 放到 Redis 这类外部存储里，节点本身无状态，负载均衡器随便轮询都没问题。这是最干净的方案，代价是引入 Redis 集群的额外复杂度，Redis 集群本身又要做负载均衡和数据分片。

我在实际项目中强烈推荐“共享会话存储 + 无状态节点”的方案。表面上看多做了一层 Redis，但收益很大：节点可以随时扩缩容，负载均衡策略可以从“会话保持”的束缚里解放出来，自由使用最均衡的算法。会话保持本质上是把单机故障的恢复时间等于最终用户感知的时间，太痛了。

1.2 吞吐、延迟与可用性，三者如何取舍

一个集群做负载均衡，不可能同时做到三个极致：吞吐量最大、延迟最低、可用性最高。这像极了数据结构里的 CAP 定理——你必须在三者之间做取舍。

以 Kafka 消费端为例。Kafka 的消费组本身就是一种负载均衡机制：一个分区的数据只会被组内一个消费者拉取，所以消费者数量和分区数量的匹配非常重要。如果消费者多于分区，多余的消费者完全空闲，吞吐没提升反而增加了 Rebalance 开销；如果消费者少于分区，一个消费者要处理多个分区，单点压力就上来了。

这种场景下“负载均衡”就不是简单把请求轮询发出去，而是根据后端处理能力做适配。Kafka、Redis Cluster、Doris 这类数据集群的负载均衡，核心是数据分片和副本分布，请求层面的负载均衡只是入口层的事情。

在生产环境里，我的经验是先把可用性底线画出来，再谈吞吐和延迟。可用性靠的是健康检查和故障转移，吞吐靠的是合理的分片和并行度，延迟靠的是最短路径和缓存。三者的优先级不能乱。

2. 负载均衡算法选型：轮询、一致性哈希与“等开销”策略的适用边界

算法是负载均衡的“大脑”。大部分集群项目里，真正能用好的算法不超过四个：轮询、最少连接、一致性哈希、以及结合后端负载状况的自适应策略。但这四个不是互相替代的关系，而是适用于完全不同的场景。

2.1 轮询与加权轮询：什么时候“最公平”反而是“最不公平”

轮询（Round Robin）是最简单的算法，把请求按顺序轮流发到后端。加权轮询（Weighted Round Robin）给每个节点配置一个权重，让性能好的机器多分流量。

这个算法在“所有节点能力一致、所有请求耗时一致”的假设下是最公平的。但生产环境里这个假设几乎不成立：

• 集群里有旧机器和新机器，CPU 核数和内存不一样；
• 某些请求本身很重（比如报表查询），某些请求很轻（比如健康检查）；
• 节点上有其他任务在跑，瞬时负载不可控。

轮询的致命问题是它不感知后端状态。有一次我们在生产环境用纯轮询，后端有一台机器因为磁盘 IO 异常变慢了，轮询照样给它发相等比例的请求，结果这台慢机器上的请求堆积，反过来加剧了磁盘负担，形成恶性循环。集群的整体延迟从 20ms 飙到了 2s，而负载均衡器一点感知都没有。

所以我的结论是：如果后端节点能力不一致、请求处理时间波动大，不要用纯轮询。Kubernetes 的 Service 默认是轮询，在普通场景够用，但如果你在 K8s 里跑 Redis 集群或者计算密集型的 Spark 任务，建议把负载均衡策略在 Ingress 或 ServiceMesh 层改成别的方式。

2.2 一致性哈希：数据集群和数据分片的黄金搭档

一致性哈希（Consistent Hashing）解决的核心问题是：当节点增减时，尽量少地迁移已有的映射关系。

最典型的使用场景是缓存集群。假设你用 5 台 Redis 做缓存，用 hash(key)%5 决定数据落在哪台机器。当集群扩容到 6 台，hash(key)%6 的结果和以前完全不同，几乎所有 key 都“跑”到了新机器上，缓存全部穿透，数据库被击穿，这就是生产事故。

一致性哈希的做法是把哈希值空间组织成一个环，每个节点根据哈希值分布在环上，每个 key 顺时针找到最近的节点。当节点增减时，只有该节点附近的 key 需要迁移，其他 key 的映射保持不变。

但一致性哈希有个新问题：如果节点少，分布可能严重不均。3 台机器在哈希环上可能挤在一起，导致一台机器承担 80% 的流量。解决办法是引入“虚拟节点”——每个物理节点映射出 100~200 个虚拟节点散落在环上，让分布趋向均匀。

“等开销负载均衡”这个词在搜索里经常被关联到集群，它实际上是一种更精细的目标：让每个节点的负载（考虑 CPU、内存、IO、带宽等多维资源）尽量相等。一致性哈希只保证了 key 的分布均匀，不能保证每个 key 的访问频率和访问成本相等。所以生产里做 Redis 集群，除了用一致性哈希做分片，还要关注热点 key 的问题：某个 key 访问量巨大，哈希落到一台机器上，那台机器就是热点。

2.3 最少连接、动态加权与自适应：后端感知型策略

最少连接（Least Connections）算法会把请求发给当前并发连接数最少的节点。它比轮询聪明一点，因为它感知到了后端的“忙闲”程度——只要后端能承受的请求数是有限的，并发连接数就能近似反映压力。

但我在实际测试里发现，最少连接有一个隐蔽的坑：它假设“每个连接的耗时相近”。如果有一台机器处理请求特别慢，它上面的并发连接数会一直很高，新请求自然会避开它。这看起来很好，慢节点被边缘化了。可是如果问题出在负载均衡器而不是后端节点呢？我遇到过 Nginx 和后端之间 keepalive 连接池分配不均的情况，导致某些后端的连接数异常偏高，最少连接反而把流量都导到了其他节点，那几个节点也被拖垮。

更现代的做法是动态加权。负载均衡器定期采集后端节点的实时负载指标（CPU、内存、请求队列深度、最近响应时间），计算一个综合负载分数，调度时把流量尽量分给分数最低的节点。Sentinel 在做 Spring Cloud 网关流量控制时就用到了类似的思路——它可以基于 QPS、线程数、响应时间做熔断和流控，本质上就是一种自适应负载均衡。

我的建议是：

• 请求类型单一、后端能力一致，用加权轮询 + 健康检查；
• 有状态服务或缓存，用一致性哈希 + 虚拟节点；
• 后端处理能力波动大或请求类型复杂，用最少连接或动态加权；
• 追求极致的系统，在负载均衡器之外再加一层自适应流控（比如 Sentinel 的熔断降级），不要指望单一算法解决所有问题。

3. 健康检查与故障转移：集群稳定性的守门员

负载均衡算法决定流量怎么分，健康检查决定哪些节点“有权分到流量”。这部分在项目里最容易被低估。很多刚搭集群的团队，负载均衡配上就完了，健康检查参数用默认值，结果故障转移要么迟迟不触发，要么误杀健康节点，比不做还糟糕。

3.1 主动探测与被动探测的搭配逻辑

主动探测是负载均衡器每隔几秒主动向后端发送探测请求（比如 TCP 连接、HTTP GET 一个健康检查接口），探测成功就标记为健康，失败就摘除。被动探测是在真实请求过程中统计超时、连接失败、5xx 错误次数，超过阈值就把节点标记为不健康。

两者必须搭配用。只做主动探测的典型问题是：探测接口写得太简单，只返回一个 200，没检查依赖的数据库、缓存、磁盘空间。结果后端业务逻辑已经因为依赖故障而龟速运行了，健康检查还显示“非常健康”，流量照常打过去，用户界面一片报错。

我踩过类似的坑。当时一个集群里某个节点的磁盘满了，业务接口写不进去数据，但健康检查只探测了一个静态页面的 HTTP 状态，永远返回 200。从负载均衡器看这个节点健康得很，实际上已经半瘫痪了。

正确的健康检查应该做到：

• 探测接口返回当前节点关键依赖的状态，比如能否连上本机 Redis、能否读取数据库连接池、磁盘剩余是否低于阈值；
• 主动探测的间隔不能太长，我一般设 3~5 秒，超时 1~2 秒，连续失败 3 次才摘除；
• 被动探测作为兜底，只要真实请求连续超时比例超过某个阈值，立即强制摘除。

3.2 熔断、慢启动与摘除恢复：避免雪崩的细节

故障转移不只是“把坏节点摘掉”，更关键的是“怎么摘”和“恢复时怎么加回来”。

先说摘除。如果一个节点因为瞬时 CPU 飙高导致响应慢，被动探测连续秒失败，负载均衡器就直接摘除它。这一步要小心“拆东墙补西墙”：A 节点故障，流量切到 B 和 C，B 和 C 本来就接近满载，新的流量一压，B 和 C 也超时了，然后 B 和 C 也被摘除，雪崩就是这么来的。

自我保护的办法是给每个节点设一个最大并发上限（比如 MaxConns），流量超过上限后，新请求直接排队或者返回 503，而不是无限地塞给后端。Sentinel 的“线程数隔离”就是干这件事的。

再说恢复。后端节点从故障里恢复后，不要立刻把它加回来满负荷转发。原因很简单：它的缓存是冷的、连接池是空的、依赖的本地资源刚刚重建，一下子接收大量流量，非常容易再次挂掉。正确做法是慢启动（Slow Start）：新恢复的节点在 1~2 分钟内，权重从 10% 慢慢增加到 100%，这期间它一边处理流量一边把缓存和连接池暖起来。

3.3 跨集群迁移中的负载均衡：以 CDH 到 CDH 为例

搜索热词里有“把数据从一个 CDH 集群迁移到另一个 CDH 集群”，我顺便说说这个场景里的负载均衡问题。

CDH 之间的数据迁移，常见工具是 DistCp（分布式拷贝）或者 Replication Manager。迁移过程会产生大量的 MapReduce 任务，这些任务的调度本身就是集群负载均衡的一部分。我遇到的典型问题是：迁移任务的 vCore 和内存资源没有设置上限，把目标集群的计算资源全部占满，业务查询完全跑不动。

解决办法：

• 给迁移任务单独设置资源池（YARN Capacity Scheduler 的队列），限制最高资源使用率；
• 迁移时错峰，避开业务高峰；
• 在迁移前先测试两个集群之间的带宽（后面第 5 节细说），确认不会把网络打满。

迁移完成后的数据校验也要注意负载均衡。MapReduce 校验任务如果并发太高，同样会压垮集群，建议限制校验任务的 Map 并行度在合理范围。

4. 分层负载均衡：从四层入口到数据层调度的完整链路

一个复杂的集群系统，负载均衡不会只发生在某一层，而是从用户入口到数据存储，层层递进。每一层的目标和选型都不同。

4.1 四层 LVS 与七层 Nginx：链路中的分工

在典型的 Web 集群架构里，负载均衡一般是两层：LVS（四层）在前面扛高并发，Nginx（七层）在后面做反向代理和业务路由。

四层负载均衡工作在网络层和传输层，只处理 IP 和 TCP/UDP 头，不解析 HTTP 报文，所以转发速度极快，性能上限高。LVS 的 DR 模式性能尤其好，数据包进来后直接改写 MAC 地址转发到后端，响应包由后端直接返回客户端，不经过 LVS，避免了“单点流量回程”的瓶颈。

七层负载均衡能感知 HTTP 协议，可以做路径路由、Cookie 会话保持、HTTPS 卸载、请求头改写。但代价是每次请求都要解析完整的 HTTP 报文，性能比四层低不少。

在生产环境里，这两层必须结合用：

• LVS 负责把流量均匀分发到一组 Nginx；
• Nginx 负责按 URL 路径、域名路由到具体的业务集群；
• 业务集群内部再做一次负载均衡（比如 Spring Cloud 的 LoadBalancer 或者 RPC 框架的服务发现）；
• 最终数据访问由数据集群自己的分片机制决定落到哪个节点。

千万别想着只用一层搞定所有事。只用 Nginx，高并发下 Nginx 会成为瓶颈；只用 LVS，你没法做 HTTP 路由和灰度发布。

4.2 网关层的流量治理：Spring Cloud Gateway 与 Redis 集群的联动

微服务架构里，Spring Cloud Gateway 是七层负载均衡和流量治理的关键节点。它不是简单地把请求转发给下游服务，而是要做认证、限流、熔断、动态路由。

有一个非常典型的场景：网关做限流和熔断，状态数据放到 Redis 集群里。这个方案的负载均衡问题非常隐蔽。

Redis 集群本身有分片，从网关视角看，你配置一个 Redis 集群地址，客户端连接会通过集群的代理或者直接和多个分片通信。如果 Redis 集群节点负载不均，比如某个分片的 key 特别集中，那这个分片的网络和 CPU 都会成为瓶颈，网关的限流数据读写也会变慢。因为网关是同步等待 Redis 响应的，Redis 慢了，网关就慢了，整个请求链路都拖慢了。

我当时的做法是：

• 给网关的 Redis 限流数据单独使用一个小的 Redis 集群，和业务数据完全隔离；
• 限流数据的 key 设计上要避免热点，比如以“网关节点 ID + 用户 ID + 秒级窗口”为维度做分布式限流，这样每个 key 的访问频率都相对均匀；
• 网关本身多节点部署，前端再挂一层负载均衡，避免网关成为单点。

从架构演进来看，Spring Cloud Gateway 里的路由规则还可以从配置中心动态加载，这样发布新服务或者改动负载均衡权重时不需要重启网关，对集群的运维体验提升很大。三个网关节点做滚动更新，始终保持至少两个节点在服务，流量无损切换，这就是负载均衡在发布场景中最朴素但也最关键的作用。

4.3 数据集群的负载均衡差异：Redis、Kafka、Doris、Hadoop 各自怎么做

不同数据集群有各自的 Sharding 和 Replication 机制，负载均衡的切入点完全不同。我按这些年实际用过的集群逐个说一下：

Redis Cluster的数据分片基于哈希槽（Slot），总共有 16384 个槽位，每个节点负责一部分槽位。集群的负载均衡核心是槽位的分配均匀，以及当节点增减时槽位的自动迁移。Redis 集群的请求分发可以走客户端直连（聪明客户端根据 key 计算节点），也可以走集群代理（Predixy、Codis 等）。客户端直连少一跳，延迟低，但客户端要维护集群拓扑变化；代理模式对客户端透明，适合客户端种类繁杂的团队。

Kafka的负载均衡重点在分区分配和消费者组 Rebalance。生产端要把消息均匀分发到多个分区，不能都用默认的粘性分区——有些业务场景下部分 key 特别多，只按 key 哈希会积压到个别分区。消费端要注意最多消费者数量不超过分区数量，否则消费者白白空转，还可能导致频繁 Rebalance 把集群搞抖。新的 Kafka 客户端在 Rebalance 时支持静态成员组（Static Membership），可以避免因为 GC 停顿导致的成员频繁进出。

Doris部署成集群时，FE（Frontend）节点负责查询解析和规划，BE（Backend）节点负责数据存储和计算。Doris 的负载均衡可以放在 FE 前面，用四层负载或者 JDBC 连接串里配置多个 FE 地址，让连接分摊到不同 FE。但在查询重、数据倾斜明显的场景下，单靠连接层均衡是不够的，还需要在表设计的时候制定分桶策略，让数据均匀分布到 BE 上。

Hadoop/YARN集群的负载均衡主要体现在任务调度上。YARN 的 Capacity Scheduler 和 Fair Scheduler 都在做“计算资源的负载均衡”。容量调度器按队列划分资源，公平调度器按任务动态调剂资源。分布式集群里如果多个部门共用一套 Hadoop，必须把资源队列划清楚，不然一个大任务就能把整个集群的计算能力吃光，其他任务全部排队。

Spark 集群的负载均衡在 Driver 把 Task 分发给 Executor 这一层。Executor 的数量决定了并行度，Task 分配到 Executor 的策略在 Spark 内部实现，用户能控制的是分区数（partitionBy、repartition）、并行度参数（spark.sql.shuffle.partitions）。我在 Spark 调优时发现，shuffle 分区数如果设置过小（小于 Executor 总数），肯定有部分 Executor 空闲；设置过大，又会增加 shuffle 写入的寻址开销。合理值公式没有，但可以从“分区数 ≈ Executor 核数的 2~3 倍”起步，观察任务执行时间再调整。

5. 集群间流量调度、带宽测试与 AI 算力集群的负载均衡

5.1 如何测试两个集群之间的真实带宽

“如何测试集群之间的带宽”是很多集群建设初期都会遇到的问题。迁移数据、跨集群备份、联邦查询，都依赖集群之间的网络带宽，而网络设备标称的带宽和实际能跑出来的带宽往往差距很大。

最精准的办法是用 iperf3 做 TCP 吞吐测试：

在集群 A 的一个节点上启动服务端：

iperf3 -s

在集群 B 的节点上启动客户端：

iperf3 -c <集群A节点IP> -P 8 -t 60

-P 8表示用 8 个并行连接，能够测出接近全速的吞吐；-t 60测 60 秒，避免短时间测试受慢启动影响。

但要注意几个实际问题：

• 集群之间如果有防火墙或安全策略，iperf3 的默认端口会被拦截，需要先放行；
• 如果两个机房跨地域（尤其是跨运营商），TCP 窗口大小会影响吞吐，需要调大内核 socket 缓冲区参数net.core.rmem_max和net.wmem_max；
• 测出的带宽是一对节点的带宽，不是整集群的带宽。要估算全集群带宽，需要做多节点并行测试。
• 测试时要避开业务高峰，避免把生产带宽打满，拖垮线上业务。

更贴近大数据场景的测试方法是直接用 Hadoop 自带的TestDFSIO工具。它可以模拟大量文件写入和读取，测试 HDFS 集群的吞吐能力，结果比 iperf3 更符合真实数据迁移场景。

5.2 AI 算力集群的构成、架构与调度负载均衡

AI 算力集群和传统大数据集群有本质区别。传统集群主要处理数据，瓶颈在磁盘 IO 和网络吞吐；AI 集群主要跑 GPU 训练任务，瓶颈在 GPU 算力、显存容量和 GPU 之间的互联带宽。这里的负载均衡场景主要体现在两个层面：训练任务的分配和GPU 资源的调度。

一个典型的 AI 推理集群，硬件层是 GPU 服务器 + 高速互联（如 InfiniBand 或 RoCE），软件层是 Kubernetes + GPU 调度插件（如 Volcano、Kueue）。这里说的负载均衡指的是：如何把不同 Size 的推理任务和训练作业分配到不同的 GPU 节点上，尽量让每张 GPU 卡的利用率接近。

我建议从三个维度设计 AI 集群的调度：

• 显存维度：任务声明需要的显存大小，K8s 调度器根据节点可用显存做过滤和打分。这个如果没做好，一张 32G 的卡上可能堆了 20 个只用到几百 MB 的小任务，而其他节点完全空闲。
• 拓扑亲和：多卡训练任务最好把同一台机器上的卡分配在一起，避免跨节点通信。因为 NVLink 带宽远高于以太网，跨节点通信会成倍增加训练时间。
• 时间片和抢占策略：推理任务通常在白天多，训练任务在夜间多。AI 集群如果支持时间片复用和优先级抢占，就可以在一天的维度上让 GPU 资源利用率更平滑。

5.3 集群故障转移的演练：如何验证负载均衡真的“扛得住”

故障转移的代码一个小时就能写完，但验证它有效要花一两周。我见过太多集群，配置了故障转移，但从来没真正触发过，生产一挂就出问题。

建议每季度做一次故障演练，至少覆盖几个场景：

• 停掉一台应用节点，观察负载均衡器是否在健康检查超时窗口内摘除它，存量请求是否被平滑切走；
• 停掉一台 Kafka Broker，观察生产者是否感知到元数据变化，分区 Leader 是否快速切换；
• 停掉一个 Redis 主节点，观察哨兵或 Cluster 协议是否完成主从切换，客户端是否能够自动重连；
• 给某个节点制造 CPU 过载，观察负载均衡算法能否自动把流量导向其他节点。

演练之前要通知到所有相关团队，最好在凌晨低峰期做，准备好回滚方案。记录每次演练的“摘除耗时”和“恢复耗时”，连续两次演练如果耗时差异超过 50%，说明你的健康检查参数可能需要调整。

6. 生产环境落地负载均衡的细节与排查链路

最后一节讲几个我反复踩的、文档里很少写清楚的细节。这些问题每一个都能让集群在关键时刻“掉链子”。

6.1 负载均衡器自身的瓶颈与高可用

很多人关注后端节点的高可用，却忘了负载均衡器自己也是单点。Nginx 只有一台，它挂了，整个集群就完了；LVS 只有一台，Keepalived 没配好，VIP 漂移失败，流量就断了。

生产环境的配置建议：

• LVS 必须用 Keepalived 做主备，两个节点之间用 VRRP 协议共享一个 VIP，主节点挂了，备节点在 2~3 秒内接管；
• Nginx 至少部署两台，前面的 LVS 或云负载均衡做流量分发；
• 负载均衡器本机的资源（连接数、句柄数、内存）要纳入监控。Nginx 的连接数打满之前通常是worker_connections或者系统ulimit先到上限，提前调好这两个参数。

6.2 超时、重试与幂等：负载均衡中最容易被忽略的三角关系

请求超时了怎么办？负载均衡器通常会重试。但重试是有风险的：如果请求不是幂等的（比如下单、转账），重试会导致重复扣款或重复下单。

在负载均衡层配置重试时，不能只写“失败就重试”，必须考虑：

• 重试的对象是哪个节点：如果原节点超时，重试打到另一个节点；如果是因为原节点处理慢但没挂，打到另一个节点反而可能增加另一个节点的压力；
• 重试的次数上限：我建议最多重试 1 次，重试太多会在后端故障时把流量放大几倍，直接把其余节点拖垮；
• 请求幂等性：写操作最好在业务层做幂等，或者在网关层先识别出不能重试的请求。

超时时间的设计也有讲究。假设后端接口 P99 延迟是 800ms，负载均衡器的响应超时就不能设成 1s，否则大量正常请求会被误判为超时。建议先通过监控拿到真实延迟分布，把超时设置为 P99 的两倍左右，再结合被动探测的阈值做动态调整。

6.3 一套完整的异常排查链路

最后给一套排查负载均衡异常的处理思路。集群出问题时，不要瞎猜，按顺序查：

1. 先看指标，再翻日志，优先确认是接入层、服务层还是存储层的异常；
2. 检查负载均衡器的后端列表，确认哪些节点被摘除、哪些异常恢复，这部分直接把流量分散情况和节点健康状态对得上；
3. 检查后端节点的连接数、CPU、内存、磁盘 IO，判断是后端被流量打满还是后端本身有故障；
4. 对比负载均衡器上的请求量和实际到后端的请求量，如果差距很大，说明负载均衡器层丢请求了，要么是连接池打满了，要么是超时被丢弃了；
5. 看响应时间曲线，如果 P99 和 P50 差距突然拉大，通常是少量慢请求占满了线程池，导致快速请求也在排队。

我按照这套路径排查过至少十几次集群事故，多数情况下原因都出在“健康检查太乐观 + 重试策略太激进 + 后端没有自我保护”这三件事上。把这三个点稳住，集群的稳定性能提升一大截。

负载均衡的最终目的不是“把流量均匀分发出去”，而是“让集群里的资源各司其职，系统在故障面前还能稳稳地向外提供服务”。这需要你把算法、健康检查、故障转移、架构分层和运维演练全部考虑到位，而当这些都到位之后，你会发现集群真正的价值才体现出来——扩容可以很小步，故障可以很优雅，流量可以很平滑。