Charles Shao
Go back

负载均衡：四层与七层、算法选型与生产实践

–views

系统要扛更高并发，最先想到的往往不是换更贵的机器，而是把请求分摊到多台机器上。负载均衡就是干这件事的：单体也好、微服务也好，几乎都会用到。

本篇是高性能系列开篇：先分清服务端与客户端负载均衡、四层与七层差异和软硬件选型，再过一遍轮询、加权、最少连接、一致性哈希等常见算法与适用场景，配齐 Nginx upstream、一致性哈希、客户端 LB 与健康检查代码。后面的缓存、冷热分离、数据库扩展、CDN、Nginx、异步削峰、连接模型、批处理与性能测试，都建立在「流量怎么分」这条地基上。

TL;DR

Table of contents

Open Table of contents

1. 负载均衡要解决什么

负载均衡指的是将用户请求分摊到不同服务器上处理，以提高系统整体的并发处理能力和可靠性。负载均衡可以由专门的软件或硬件来实现——一般情况下，硬件性能更强，软件成本更低。

负载均衡是一种有效且实施相对简单的提升并发与可靠性的手段，不论是单体架构还是微服务架构几乎都会用到。

2. 服务端与客户端、四层与七层

负载均衡可以简单分为服务端负载均衡和客户端负载均衡两种。

2.1 服务端负载均衡

服务端负载均衡主要应用于系统外部请求与网关层之间，可以使用软件或硬件实现。

硬件负载均衡通过专用硬件设备（如 F5、A10、Array）来实现。优势是性能强劲且稳定；代价是采购与维护成本较高，适合对可用性要求极严苛、流量规模极大的场景——中小规模团队用软件方案通常已经足够。

软件负载均衡通过软件（如 LVS、Nginx、HAProxy）实现，成本远低于专用硬件，覆盖了绝大部分工程场景。

根据 OSI 模型，服务端负载均衡还可细分为二层、三层、四层、七层负载均衡，其中最常见的是四层和七层，本文重点介绍这两种。

Nginx 官网对两者有更细的说明：

四层与七层负载均衡对比示意：四层基于 IP+端口转发，七层基于 URL/Cookie 等内容做路由

四层看 IP+端口转发，七层读 URL/Cookie 等内容再路由。

七层负载均衡比四层消耗更多计算资源，但更灵活，支持基于内容的路由、缓存、压缩、加密等能力。

一句话：四层性能强，七层功能强——对绝大多数业务，两者的性能差异基本可以忽略。

以下摘自 Nginx 官网对四层负载均衡的说明：

Layer 4 load balancing was a popular architectural approach to traffic handling when commodity hardware was not as powerful as it is now, and the interaction between clients and application servers was much less complex. It requires less computation than more sophisticated load balancing methods (such as Layer 7), but CPU and memory are now sufficiently fast and cheap that the performance advantage for Layer 4 load balancing has become negligible or irrelevant in most situations.

工程中，通常使用 Nginx 做七层负载均衡，LVS（Linux Virtual Server，内核级四层负载均衡）做四层负载均衡。LVS 在超大规模流量场景下有突出的吞吐量优势；一般业务以 Nginx 为主。

2.2 客户端负载均衡

客户端负载均衡主要用于系统内部不同服务之间的调用，借助负载均衡组件在客户端侧实现。

客户端自己维护一份服务器地址列表，发请求前根据负载均衡算法选择具体目标机器。均衡器与服务跑在同一进程中，无额外网络开销。缺点是实现与编程语言耦合，如 Spring Cloud LoadBalancer 只适用于 Java。

Java 领域主流微服务框架 Dubbo、Spring Cloud 等均内置客户端负载均衡实现。Dubbo 默认自带；Spring Cloud 通过组件形式支持，目前推荐使用官方维护的 Spring Cloud LoadBalancer（Ribbon 已弃用）。

Spring Cloud LoadBalancer：只需引入依赖并给 RestTemplate/WebClient 打上 @LoadBalanced，调用时用服务名（而非具体 IP），负载均衡在客户端进程内完成，默认策略为轮询：

@Configuration
public class LbConfig {
    @Bean
    @LoadBalanced // 拦截以服务名发起的请求，在客户端做负载均衡
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

@Service
public class BidService {
    private final RestTemplate restTemplate;

    public BidService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public BidResponse queryBudget(String campaignId) {
        // budget-service 是注册中心里的服务名，不是 IP：
        // 客户端从实例列表中按 LB 策略选一台，无额外网络跳
        return restTemplate.getForObject(
            "http://budget-service/budget/" + campaignId, BidResponse.class);
    }
}

切换策略只需覆盖 ReactorLoadBalancer Bean，例如把默认轮询换成随机：

public class CustomLbConfig {
    @Bean
    public ReactorLoadBalancer<ServiceInstance> randomLoadBalancer(
            Environment env, LoadBalancerClientFactory factory) {
        String name = env.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
        return new RandomLoadBalancer(
            factory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
    }
}

Dubbo 则通过注解或配置项声明策略，内置 random（默认加权随机）、roundrobin（平滑加权轮询）、leastactive（最少活跃）、consistenthash（一致性哈希）等：

// 消费端指定：最少活跃调用，天然向低负载节点倾斜，适合 RPC 长连接
@DubboReference(loadbalance = "leastactive", timeout = 80)
private BidService bidService;

// 需要会话粘滞时用一致性哈希，按首个参数（如 userId）路由
@DubboReference(loadbalance = "consistenthash")
private FrequencyControlService fcService;

客户端 LB 与后端间通常是长连接池，选点算法（尤其 leastactive）的效果与连接/IO 模型强相关，详见 连接与 I/O 模型。

3. 常见算法与适用场景

3.1 随机

随机法是最简单直接的负载均衡算法。

不配置权重时，所有服务器被访问到的概率相同；配置权重时，权重越高的服务器被访问的概率越大。

随机算法有一个概率层面的缺陷：短时间内某些节点可能无法被选中，导致负载分布不均，轮询法可弥补这一不足。

3.2 轮询与加权轮询

轮询法按时间顺序依次将请求分发到各服务器，同样支持配置权重。

加权轮询的进阶版本是平滑加权轮询算法，可避免集中连续地将请求打到某个高权重节点，分布更均匀。该算法最早由 Nginx 实现（相关 commit），Dubbo 的加权轮询策略亦借鉴并优化了该思路。

适用场景：机器同质、无需感知实时负载的场景用无权重轮询，实现最简单；异构集群（新旧机型混部）用加权轮询，按算力比例分配权重即可，是绝大多数网关和 upstream 配置的默认选择。

负载均衡架构示意：客户端请求经负载均衡器分发到多台后端真实服务器

请求经负载均衡器分发到多台后端，算法决定落到哪一台。

3.3 两次随机

两次随机法在随机法的基础上多选出一个候选节点，再根据两个节点的负载等情况选出最合适的一台。

相比单次随机，两次随机能更好地动态均衡各节点负载，减少热点积累，适合节点数量较多、负载差异明显的场景。

3.4 哈希

将请求的某个参数（如客户端 IP、用户 ID）经哈希函数映射为哈希值，再据此决定路由到哪台服务器。

服务器数量不变时，相同参数的请求总落到同一台服务器，天然支持会话粘滞（session affinity）。缺点是一旦节点数量变化，哈希值会全量重新映射，原有路由关系被打乱。

3.5 一致性哈希

一致性哈希在哈希法基础上解决了「节点增减导致全量重映射」的问题。

核心思路：将数据与节点都映射到同一个哈希环上，请求按哈希值顺时针找到最近节点。当增删节点时，只有相邻区间受影响，其余映射关系保持不变，缓存命中率的下降得到有效控制。

一致性哈希负载均衡示意：请求按哈希映射到哈希环上的节点，节点增减时影响面可控

数据与节点都落在哈希环上，增删节点只扰动相邻区间。

适用场景：分布式缓存、带状态的长连接等对路由稳定性敏感的场景——节点增减时命中率的下降必须可控，而不是全量重新分布。

虚拟节点（Virtual Nodes） 解决的是节点数量少时哈希环分布不均匀的问题：当真实节点只有 3–5 个时，三者在哈希环上位置难以做到均匀分布，导致某些节点承担过多请求。虚拟节点的做法是：为每个真实节点在哈希环上映射多个虚拟节点（工程中常见每个真实节点扩展为 100–200 个虚拟节点），请求先命中虚拟节点，再从虚拟节点映射到对应真实节点。虚拟节点数量越多，环上分布越均匀，节点增减时影响面越小。

工程上一致性哈希环通常用有序结构（如 Java 的 TreeMap）实现——环即「哈希值 → 节点」的排序映射，路由就是「取大于等于 key 哈希的第一个节点，找不到则回绕到环首」：

public class ConsistentHashRouter {
    // 哈希环：哈希值 -> 真实节点，TreeMap 天然有序，便于顺时针查找
    private final SortedMap<Long, String> ring = new TreeMap<>();
    // 每个真实节点对应的虚拟节点数，工程常用 150+
    private final int virtualNodes;

    public ConsistentHashRouter(List<String> nodes, int virtualNodes) {
        this.virtualNodes = virtualNodes;
        nodes.forEach(this::addNode);
    }

    public void addNode(String node) {
        for (int i = 0; i < virtualNodes; i++) {
            // 为每个真实节点在环上放 virtualNodes 个虚拟点，打散分布
            ring.put(hash(node + "#" + i), node);
        }
    }

    public void removeNode(String node) {
        for (int i = 0; i < virtualNodes; i++) {
            ring.remove(hash(node + "#" + i));
        }
    }

    public String route(String key) {
        if (ring.isEmpty()) return null;
        long h = hash(key);
        // 顺时针找第一个不小于 h 的节点；越过环尾则回绕到环首
        SortedMap<Long, String> tail = ring.tailMap(h);
        Long target = tail.isEmpty() ? ring.firstKey() : tail.firstKey();
        return ring.get(target);
    }

    // 用 MurmurHash / FNV 等分布均匀的哈希；避免直接用 hashCode
    private long hash(String s) {
        return Hashing.murmur3_128().hashString(s, StandardCharsets.UTF_8).asLong();
    }
}

加减节点时，只有环上被移除/新增虚拟点所覆盖的那段 key 需要重新落位，其余映射不变——这正是一致性哈希「影响面可控」的来源。

一致性哈希在分布式缓存（如 Redis Cluster 的槽位机制、Memcached 客户端分片）中尤为重要：节点扩缩容时，只有相邻区间的缓存 key 需要重新映射，其余缓存仍然有效，命中率下降幅度可控，参见 缓存机制。

3.6 最少连接

新请求到来时，遍历节点列表，选取当前连接数最少的一台。连接数相同时可辅以加权随机。

最小连接法基于「连接数越多，负载越高」这一假设。实际上连接数不等于负载——某些连接计算量极低，某些连接消耗大量 CPU，需结合业务特性评估是否适用。

适用场景：长连接场景（WebSocket、RPC 持久连接）尤为合适——短连接下各节点连接数瞬间归零、参考意义有限；长连接下「当前挂了多少个连接」能较真实地反映节点负荷。若请求耗时差异悬殊，最少活跃法（见 3.7）通常是更精确的替代。连接数为何能近似反映负载、长短连接与线程/事件模型的关系，参见 连接与 I/O 模型。

3.7 最少活跃

以活跃请求数（正在处理中的请求数）而非连接总数为指标来选择节点。活跃数越低，说明该节点处理能力相对更强，优先分配更多请求；活跃数相同时辅以加权随机。

相比最小连接法，最少活跃法的指标更贴近瞬时负载，在请求耗时差异较大的场景下更具参考价值。

3.8 最快响应

以历史响应时间为指标，每次请求选择响应最短的节点；响应时间相同时辅以加权随机。

优点是请求倾向于被处理速度最快的节点承接；缺点是高性能节点容易长期过热，其余节点长期空闲，造成资源浪费。适合集群节点性能差异显著、响应时间波动有规律的场景。

4. 七层落地：DNS 与反向代理

两种常用的七层负载均衡实现方案：DNS 解析和反向代理。HTTP 重定向也可用于负载均衡，但复杂度较高，工程中较少采用。

4.1 DNS 多记录轮询

DNS 解析是早期常见的七层负载均衡实现方式。原理是在 DNS 服务器中为同一个主机名配置多条 A 记录，各 A 记录指向不同服务器；当用户请求域名时，DNS 服务器以轮询方式返回其中一条 IP，实现流量分散。

轮询负载均衡算法示意：请求按顺序依次分发到后端服务器

无权重时请求按顺序轮流落到各后端。

现代 DNS 解析通常支持权重配置，可在异构集群中做更合理的流量分配。DNS 方案简单易用，但更新生效受 TTL 限制，故障切换时延较长，灵活性有限。

4.2 反向代理与 Nginx upstream

客户端将请求发送到反向代理服务器，由反向代理选择目标服务器转发，获取响应后再返回客户端。对外暴露的是反向代理地址，真实服务器 IP 对客户端不可见。

Nginx 是最常用的反向代理服务器，核心配置都在 upstream 块里。以下把四种常见策略放在一起对照（更完整的 Nginx 调优见 Nginx 配置实践）：

http {
    # ① 默认：轮询（不写任何指令即为 round-robin）
    upstream backend_rr {
        server 10.0.0.11:8080;
        server 10.0.0.12:8080;
        server 10.0.0.13:8080;
    }

    # ② 加权轮询：按算力比例分配（新机型给更高权重），Nginx 内部为平滑加权轮询
    upstream backend_weighted {
        server 10.0.0.11:8080 weight=5;   # 高配
        server 10.0.0.12:8080 weight=3;
        server 10.0.0.13:8080 weight=1;   # 旧机
        keepalive 256;                    # 与后端保持长连接池，省去反复握手
    }

    # ③ 最少连接：新请求投给当前活跃连接最少的节点，适合长连接/耗时不均
    upstream backend_least {
        least_conn;
        server 10.0.0.11:8080;
        server 10.0.0.12:8080;
    }

    # ④ ip_hash：按客户端 IP 哈希固定落点，做会话粘滞（NAT 环境慎用）
    upstream backend_iphash {
        ip_hash;
        server 10.0.0.11:8080;
        server 10.0.0.12:8080;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend_weighted;
            proxy_http_version 1.1;
            proxy_set_header Connection "";   # 复用 upstream keepalive 的必要设置
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

若需要按业务 key（如用户 ID、URL）做一致性哈希，用 hash ... consistent——增删后端时只扰动相邻区间，而非全量重映射：

upstream backend_chash {
    # consistent 启用一致性哈希（Nginx 内部使用虚拟节点），扩缩容时命中率下降可控
    hash $arg_uid consistent;   # 按 URL 参数 uid 路由；也可用 $request_uri 等
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.13:8080;
}

加权轮询示意：按服务器权重比例分配请求

权重越高的机器拿到的请求比例越大。

5. 云原生 ALB

随着云原生架构普及，主流云厂商均提供了开箱即用的应用型负载均衡（ALB，Application Load Balancer），如 AWS ALB、阿里云 ALB、腾讯云 CLB 的七层模式等。

与自建 Nginx 相比，云 ALB 的主要优势在于：

在具备弹性需求或已上云的团队，ALB 通常是七层负载均衡的优先选项；自建 Nginx 在需要深度定制、混合部署或离线环境的场景下更具优势。

6. 四层与七层怎么选

维度四层（L4）七层（L7）
选节点依据IP + 端口（连接级别）URL、请求头、Cookie 等
协议TCP / UDP（非 HTTP）HTTP / HTTPS / WebSocket
吞吐量极高（内核态转发，如 LVS）较高（用户态解析，如 Nginx）
内容感知路由不支持支持（路径路由、A/B 测试、金丝雀）
TLS 终止不支持（需穿透或在节点终止）支持
典型选型游戏服务器 UDP、数据库连接代理绝大多数 Web / API 场景

决策建议：

7. 健康检查、慢启动与会话粘滞

7.1 健康检查与慢启动

健康检查（Health Check） 是 LB 可靠性的核心机制，分主动和被动两类：

准确性提醒：开源 Nginx 并没有主动健康探针。health_check、slow_start、动态 upstream reload 都是 Nginx Plus（商业版） 特性。开源版只有被动检查，通过 max_fails / fail_timeout 实现；要主动探测需借助第三方模块（如 nginx_upstream_check_module）或用 LVS + Keepalived 在四层补齐。这一点在选型时极易被官方文档误导。

开源 Nginx 的被动健康检查配置：

upstream bidder_gw {
    # fail_timeout 内累计 max_fails 次失败 → 标记不可用，fail_timeout 后再试探
    server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=10s;
    server 10.0.1.13:8080 backup;     # 仅当主节点全部不可用时才启用
}

# 判定失败的条件：连接失败、超时，以及被视为失败的响应状态码
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_connect_timeout 1s;
proxy_read_timeout    2s;

四层侧常用 LVS + Keepalived：Keepalived 既做 VIP 漂移（LB 高可用），又对 real server 做主动探活，失败即从转发表摘除：

virtual_server 203.0.113.10 443 {
    delay_loop 2                 # 每 2s 探活一次
    lb_algo wlc                  # 加权最少连接（weighted least-connection）
    lb_kind DR                   # Direct Routing，回包不经 LVS，吞吐极高
    protocol TCP

    real_server 10.0.1.11 443 {
        weight 5
        TCP_CHECK { connect_timeout 1; retry 2; }   # 主动探活，失败即摘除
    }
    real_server 10.0.1.12 443 {
        weight 3
        TCP_CHECK { connect_timeout 1; retry 2; }
    }
}

慢启动（Slow Start）：节点故障恢复后，若立即承接全量流量，可能因 JVM JIT 未预热、连接池未充满等原因造成响应时间骤升。慢启动机制让新上线或刚恢复的节点权重从低值逐步爬升至目标值（如 slow_start=30s），给节点预热时间，避免「刚恢复就被打死」。注意 slow_start 同样是 Nginx Plus 特性；开源侧可用云 ALB 的预热、服务网格（Envoy slow_start_config）或客户端 LB 的权重爬升替代。

7.2 会话粘滞（Session Affinity）

会话持久性（也称粘性会话，Sticky Session）指将同一客户端的多次请求始终路由到同一后端节点，常见于有状态服务（购物车存储在本地 Session）。

常见实现：

缺点与风险：

8. 生产陷阱

8.1 负载均衡器自身成为单点

在 Nginx/HAProxy 前没有任何冗余时，LB 自身故障即全站故障。解法：

8.2 节点权重配置不当

场景：运维忘记更新权重配置，新扩容的高配节点与旧节点权重相同，高配机器利用率偏低；或某台节点实际性能下降，权重未及时降低，持续收到大量请求雪上加霜。

应对：在监控看板中为每台后端节点接入 CPU/内存/连接数指标，定期对照流量分布是否与权重预期吻合；有条件时接入动态权重调整（如 Nginx Plus 或 Envoy xDS）。

8.3 下线节点未排水（Drain）

场景：直接将后端节点从 LB 列表摘除或关机，正在处理中的长连接或 HTTP 请求立即被切断，客户端收到连接重置错误。

应对：优雅下线前先将该节点权重降为 0 或触发 LB 的「排水（Drain）」功能，待活跃连接数降至 0 后再关机；Kubernetes 的 graceful termination 与云 ALB 的连接排水功能均内置此逻辑，自建 Nginx 则通过 nginx -s quit 信号配合 worker_shutdown_timeout 实现。

小结

系列其他篇：

参考

–views
Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email
Previous Post
数据冷热分离：边界划分、迁移与查询路由
Next Post
数据中心选型：全球枢纽、云区域与广告流量部署