两年前校招面试的时候，背过不少所谓的“八股文”，负载均衡也是其中一个。当时的理解其实挺粗糙的，大概就是：
客户端的请求不会直接打到真实服务器，而是先到一个中间层，这个中间层再把请求转发到后端的某一台机器。
因为客户端并不知道后端真实服务器的存在，所以这种方式叫反向代理，用来和正向代理做区分。
面试官听完之后，问了我一句：
负载均衡是工作在哪一层的？
当时脑子是空的。
不是没听过 OSI 七层模型，而是根本没把这两个东西联系起来。后来查了不少资料，也一直没找到一个让我觉得“哦，原来是这么回事”的解释。
直到最近看《凤凰架构》里讲多级透明分流系统，才突然意识到，当年那个问题其实并不复杂，只是我当时根本不知道该从哪个角度去理解。
“第几层”这个问题，本身就有点误导
负载均衡并不是只能工作在某一层，它本身就有不同的实现方式。
常见的区分，其实是 四层负载均衡 和 七层负载均衡，这里的“层”，指的就是 OSI 模型里的层。
换句话说，面试官真正想问的，并不是一个标准答案，而是你知不知道这两种东西的区别。
四层负载均衡：更像“转发器”
四层负载均衡工作在传输层，面对的是 TCP / UDP 连接。
它并不关心你发的是 HTTP 还是 HTTPS，也不会去看 URL、Header 这些东西。对它来说，请求只是一个连接，根据 IP、端口这些信息，把连接转发到某一台后端服务器。
一个很关键的点是：
TCP 连接的另一端，依然是后端的真实服务器，而不是负载均衡器本身。
负载均衡器只负责把请求“送过去”，并不会真正参与业务处理。
具体实现上，大概可以分两种思路：
- 通过修改 MAC 地址，把请求直接送到目标服务器；
- 也有通过修改 IP 地址来完成转发的方式。
不管哪种，核心思想都一样：
请求最终还是由真实服务器来接，负载均衡器本身尽量不成为链路中的“重节点”。
这也是为什么四层负载均衡性能通常很好，延迟也低。
七层负载均衡：已经是“应用的一部分”了
七层负载均衡就完全不一样了。
它工作在应用层，理解 HTTP 语义，请求到了这里，TCP 连接会直接终止在负载均衡器上。然后由它再向后端服务器发起新的请求。
从这个角度看，七层负载均衡其实已经是一个完整的应用服务器了。
也正因为它理解应用层协议，才能做很多四层做不了的事情，比如：
- 根据 URL 或 Header 做路由
- 在入口直接缓存静态资源
但代价也很明显：
所有请求和响应都要经过负载均衡器本身，它既要接客户端的数据，又要收后端的返回，很容易在高并发场景下成为瓶颈。
回过头再看那次面试
如果现在再有人问我：
负载均衡工作在哪一层？
我大概会先反问一句：
你指的是四层，还是七层？
然后再从“TCP 连接在哪终止”“负载均衡器到底参与了多少事情”这个角度展开讲，而不是急着给一个标准答案。
现在回头看，当年答不上来并不是因为问题有多难，而是自己对这些概念的理解还停留在“名词层面”，没有真正顺着数据流去想。
一点个人感受
很多基础概念，刚开始看都觉得自己懂了，直到被问到“它到底在干什么”“请求是怎么走的”，才发现其实并没想清楚。
负载均衡对我来说就是这样一个例子。
它不是突然学会的，而是在某个时间点，把零散的知识拼到了一起，才慢慢变得清晰。
如果这篇文章能帮你少走一点我当年走过的弯路，那就值了。
