多通道负载均衡到底是怎么做的？通道配置、健康检查和自动切换在请求分发里各自起什么作用？

多通道负载均衡是指把同一类上游请求按规则分散到两条及以上可独立承载的通道上，并在通道异常时把流量切走的调度机制。这里的通道可以是不同供应商的同能力接口，也可以是同一供应商的不同线路或不同区域节点。它不适用于只有一条通道、或请求必须绑定到某一特定通道才能完成的情况，比如依赖某条通道私有能力的调用。 通道配置是负载均衡的全部输入，配置里没写清楚的字段，调度器就无法做出正确决策。一条通道至少要登记协议类型、能力边界（支持哪些模型或哪些接口）、并发上限、超时阈值、成本单价以及是否支持流式返回。缺少并发上限，调度器会按权重无限放量，把一条通道直接打到限流。 通道配置还包含启用状态与优先级，它决定一条通道是主用、备用还是只在特定时段参与。主备模式适合成本差异大、容量差异大的场景，平时只用主通道，主通道不可用时才切到备通道。对等模式适合通道能力接近、需要摊平并发压力的场景，两条通道平时都在承接流量。 请求分配的第一层是权重，权重表达的是这条通道应该承担多大比例的流量。常见的分配算法有加权轮询、加权随机、最少连接数和最小响应时间几类。加权轮询实现简单、流量分布可预测，适合通道性能接近的情况；最少连接数会向空闲通道倾斜，适合单请求耗时差异大的情况。 请求分配的第二层是会话粘性，多轮对话、依赖上下文缓存的请求不能随机换通道。随机分配会导致上下文在通道之间错位，或者缓存反复失效、成本和延迟同时上升。常见做法是对会话标识或用户标识做哈希，把同一会话固定到同一条通道，并在该通道不健康时才允许漂移。 健康检查分主动探测与被动统计两种，两者解决的问题不同。主动探测由调度器按固定间隔向通道发轻量请求，连续失败达到阈值就把通道摘除，优点是不依赖真实流量、故障发现快。被动统计基于真实请求的成功率、超时率和首字节延迟判断，优点是不额外消耗额度，缺点是流量低谷时样本不足、反应偏慢。 健康检查最容易出错的地方，是把不该摘除的响应当成故障。参数错误返回的 400 类状态码说明请求本身有问题，换通道也一样失败，不应该触发摘除；返回 429 说明通道活着但被限流，正确动作是退避并降低该通道权重，而不是直接摘掉。真正需要触发摘除的是连接失败、超时和 500 类错误。 自动切换不等于把失败请求原样重发，重试策略必须考虑幂等性和重试放大。对幂等的查询类请求可以在失败后切到其他通道重试，对写操作或计费敏感的请求要谨慎重试，避免一次调用被记成多次。同时要限制重试次数和重试窗口，否则一条通道的抖动会在全局放大成数倍流量。 流式请求的自动切换是最难处理的部分，因为响应一旦开始返回就不可能完整重放。对已经开始输出内容的流式请求，通常只做连接层的中断处理，不做内容层重试；只有在首字节返回之前发生的失败，才适合切换到其他通道重新发起。这条规则决定了调度器必须能区分首字节之前和之后的失败。 通道被摘除后如何回归，决定了系统会不会反复抖动。合理的做法是先进入半开状态，放少量探测流量过去，观察一段时间成功率达标后再逐步恢复权重，而不是立刻恢复满额流量。没有渐进恢复，一条时好时坏的通道会不断被摘除又恢复，造成持续的流量波动。 没有按通道维度统计的观测数据，负载均衡就无法调优。至少要记录每条通道的请求量、成功率、超时率、限流比例和延迟分位值，并把这些指标和摘除、切换事件关联起来。只看整体成功率会掩盖问题，整体成功率不变但某条通道持续失败的情况很常见，原因是调度器已经把流量挪走了。 多通道负载均衡的边界很明确，它解决的是通道级的可用性和压力分配，不解决单条通道内部的容量不足。当所有通道同时限流或同时故障时，切换没有意义，此时需要的是排队、降级或限流，而不是继续找下一条通道。把负载均衡当成万能容错手段，反而会掩盖上游容量规划本身的缺口。