第1章负载均衡概述

1. 负载均衡概述

各位好，我是老张。在交换网络里摸爬滚打了十几年，今天咱们聊聊负载均衡这个话题。说实话，这玩意儿看着简单，但坑是真不少。我刚开始接触交换架构时，总觉得负载均衡不就是把流量分一分嘛，有什么难的？后来被现实狠狠教育了一顿。

先给个最直白的定义：负载均衡就是把网络流量合理地分配到多条链路上。你想想看，一条路走的人多了就会堵，那我们就多修几条路，让大家分散着走。交换架构里的负载均衡，干的就是这个活。

具体来说，当一台交换机有多个上行链路或者多个等价路径时，它需要决定每个数据包走哪条路。这个决策过程，就是负载均衡。我习惯把它比作交通指挥——不是随便指个方向，而是要根据实时路况来调度。

核心要点：负载均衡不是简单的"轮流发牌"，而是要综合考虑带宽利用率、会话一致性、故障切换等因素。

这里我画了一张图，帮你快速理解负载均衡在交换架构中的位置：

这个问题我问过不少刚入行的朋友，答案五花八门。有人说为了带宽叠加，有人说为了冗余备份。都对，但都不全面。

我给大家列几个真实场景：

带宽瓶颈：单条链路带宽有限，比如10G口不够用了，你得上40G或者100G。但升级硬件成本太高，不如用4条10G链路做负载均衡。我在一个数据中心项目里，就是靠4条25G链路捆在一起，撑住了100G的业务流量。
链路冗余：一条链路断了，业务不能断。负载均衡配合链路检测，能在毫秒级把流量切到其他链路上。我记得有一次深夜割接，一条主干光纤被施工队挖断了，还好负载均衡自动切换，用户完全没感知。
流量优化：不同链路的延迟、成本可能不一样。负载均衡可以根据策略把关键业务流量调度到低延迟链路上，把大文件备份这种非实时流量扔到便宜链路上。

一个小经验：别等到链路跑满了才想起做负载均衡。我见过太多案例，平时链路利用率30%，觉得没必要。结果业务一上线，瞬间飙到95%，整个网络都卡死了。提前规划，永远比事后补救强。

说白了，负载均衡要干三件事：

均匀分配：让每条链路或每个处理单元的负载尽量均衡。别让一条链路累死，其他链路闲死。
会话保持：同一个会话的数据包必须走同一条路径。否则TCP连接会断开，应用会报错。这个坑我踩过——早期用简单的轮询算法，结果用户登录后下一页请求跳到另一条链路，session丢了，被运维同事追着骂了一周。
快速收敛：链路或节点故障时，能迅速把流量切换到健康路径上。收敛时间越短，业务中断越小。

这三个目标有时候是互相矛盾的。比如均匀分配和会话保持，如果哈希算法选得不好，可能某些链路负载特别高。这时候就需要权衡了。我个人习惯是：优先保证会话一致性，再追求负载均衡的均匀度。毕竟业务稳定比带宽利用率更重要。

注意：别以为负载均衡是万能的。它解决的是流量分发问题，不是带宽扩容问题。如果总流量已经超过了所有链路的总和，那负载均衡也救不了你。该升级带宽还是得升级。

嗯，关于负载均衡的基本概念，今天就聊到这儿。这些是后面所有内容的基础，理解透了，后面学哈希算法、ECMP、动态负载均衡这些才会轻松。我曾经带过一个团队，就是因为基础概念没吃透，上线后出了不少幺蛾子。所以，别嫌啰嗦，基础打牢了，后面才能走得稳。