为什么你的系统一压测就挂？可能是在流量入口

在构建高可用、高性能的分布式系统中，负载均衡是不可或缺的关键组件。它不仅关乎如何将流量分发到后端服务器，更涉及如何根据业务需求和系统状态做出最智能的决策。本文将基于常见的负载均衡架构，从业务层面的技巧和底层通用算法两个维度进行解析。

一、业务负载均衡技巧

在很多复杂的应用场景下，负载均衡不仅仅是简单的“分发”，还需要根据业务属性进行“定向路由”。这通常用于灰度发布、A/B测试或多租户隔离等场景。

为了实现这种精细化的流量控制，负载均衡器通常会提取请求中的特定特征作为判断依据：

基于 Cookie

应用：通过识别用户 Cookie 中的特定标识（如 UserID 或 SessionID），将特定用户群体的流量引导至指定服务器集群。这在保持用户会话粘性或进行小范围用户测试时非常有效。

基于自定义 HTTP Header

应用：客户端（App或Web）可以在请求头中携带特定的元数据（如版本号X-App-Version、渠道号等）。负载均衡器根据 Header 内容，将流量分流到不同版本的后端服务，实现平滑升级。

基于 URL Query String

应用：根据 URL 中的查询参数（例如?region=beijing或?source=marketing）进行路由。这种方式灵活且直观，常用于特定的营销活动页或根据地域参数进行逻辑分片。

二、通用负载均衡算法

当请求通过业务规则筛选后，最终需要分发到具体的物理服务器上。此时，我们需要选择合适的负载均衡算法。根据算法的复杂度、对服务器状态的感知能力以及适用场景，主要分为以下几类：

1. 简单轮询类

这类算法的核心特点是实现简单，但不具备“服务器状态感知”能力（即不管服务器是忙是闲，还是已经挂了，只要连接还在，就会发请求）。

轮询

机制：按顺序将请求依次分配给每台服务器。

优点：实现极其简单，公平性好。

缺点：不会判断服务器状态。如果某台服务器负载很高或处理很慢，轮询依然会把请求发过去，可能导致“雪崩”。

随机

机制：随机选择一台服务器发送请求。

优点：实现简单，在大流量场景下，理论上分配会趋于均匀。

缺点：同样不会判断服务器状态，不可控性略高于轮询。

2. 静态权重类

加权轮询

机制：在轮询的基础上，给性能强的服务器配置更高的权重，分配更多的请求。

优点：可以根据服务器性能来分配请求，解决了异构服务器（配置高低不同）的负载问题。

缺点：实现相对复杂；依然属于静态策略，不会判断服务器的实时状态。

3. 动态状态感知类

这类算法更加智能，但实现难度和资源消耗也更高。它们依赖于实时监控后端的健康状况。