负载均衡器干了10年脏活，API网关一进场就抢走了C位

2024年某电商大促，凌晨2点流量洪峰突至。运维团队盯着监控屏，负载均衡器（负载均衡器）健康检查全绿，后端服务器却陆续返回502。故障复盘时他们发现：攻击者用伪造Token刷爆了用户服务，而负载均衡器对这种"合法流量里的恶意请求"毫无感知——它只管分蛋糕，不管蛋糕里有没有毒。

这个价值千万的教训，戳中了两个常被混淆的基础设施。

负载均衡器：交通警察，只管车流量

负载均衡器的核心KPI只有一个：别让任何一台服务器累死。它站在客户端和后端之间，像高速公路收费站，把HTTP/HTTPS请求均匀分发到多个服务器实例。

它的能力边界很清晰：健康检查探测宕机节点，故障转移把流量切走，L4层按IP端口路由、L7层能看懂HTTP头做更细的分流。但仅此而已。它不关心请求里带了什么参数，不验证你是谁，不限制你一分钟调用多少次。

打个比方：负载均衡器是餐厅叫号系统，只管把客人分配到空闲座位，不管客人有没有预约、是不是来闹事的。

这种"无脑分发"在单体架构时代完全够用。但当微服务拆出几十个服务、每个服务又有几十组实例时，问题变了——你需要的不再是"把请求丢给某台机器"，而是"把请求丢给某个功能的某个版本，并且先验明正身"。

API网关：大堂经理，要认人、限流、改菜单

API网关（应用程序编程接口网关）同样接收来自Web、移动端、物联网设备的HTTP/HTTPS请求，但它做的是"智能预处理"。

速率限制（速率限制）防刷爆，接口聚合把5个后端调用包成1个给客户端，可观测性埋点用于日志监控，身份验证与授权在请求触及业务代码前就拦截非法访问，请求响应转换还能把客户端的JSON改成后端需要的Protobuf格式。

继续用餐厅类比：API网关是站在门口的大堂经理，检查预约信息、限制高峰时段用餐人数、把"我要吃海鲜"翻译成"清蒸石斑+蒜蓉扇贝"、还能把后厨的出餐状态实时同步给等位的客人。

关键区别：负载均衡器处理的是"连接"，API网关处理的是"意图"。前者看的是TCP握手是否成功，后者看的是这个请求想干什么、有没有资格干。

生产环境的真实站位：网关在前，均衡器在后

成熟的架构里，两者不是二选一，而是分层协作。

流量先进API网关，在这里完成鉴权、限流、路由决策——比如识别出"/payment/v2"要转发到支付服务的v2版本。然后网关把请求发给负载均衡器，由后者在支付服务v2的十几个实例之间做最后的流量分配。

这种分层让职责清晰：网关应对业务逻辑层面的威胁（Token伪造、接口滥用），均衡器应对基础设施层面的故障（实例宕机、网络抖动）。

混用两者的代价很真实。曾有人把JWT验证塞到负载均衡器里，用Nginx Lua脚本硬写，结果每次升级证书都要重启所有均衡节点；也有人让API网关直接裸奔在公网，省掉了前面的均衡层，单点故障时整个入口瘫痪。

那MCP又是什么新变量？

文章里还埋了一个值得关注的点：Anthropic推出的模型上下文协议（模型上下文协议），一个开源标准，让Claude这类AI模型能直接连数据库、API、文件系统，不用为每个集成写定制代码。

它采用客户端-服务器架构。这听起来和网关有点像？但MCP解决的是"AI工具调用"的标准化，而非流量治理。可以把它理解为AI时代的ODBC——当年数据库连接靠它统一，现在AI模型靠MCP统一接外部世界。

当MCP服务器遍地开花，API网关可能会新增一层职责：做MCP协议的流量治理。毕竟模型调用的成本远高于普通HTTP请求，一次Claude Tool调用可能触发后端十几个MCP服务器，这时候限流、缓存、成本分摊的策略会比现在更复杂。

ByteByteGo的第五期AI工程师课程今天开课，课程设计有个细节挺实在：强调"构建真实世界的AI应用"而非纯理论。这对应了一个行业现状——懂Transformer架构的人越来越多，但能把它和现有系统基础设施（网关、均衡器、缓存、队列）拧在一起的人还是稀缺。

回到开头那个凌晨2点的故障。如果当时API网关在前，伪造Token会在第一层就被拒掉，负载均衡器只会收到干净的流量，后端服务器或许能撑过那个夜晚。

基础设施的选型，本质是"在哪个环节解决哪类问题"的决策。负载均衡器把这个问题回答了二十年，现在轮到API网关回答更复杂的版本——而AI正在把问题本身改写成我们还没完全理解的模样。

你的生产环境里，网关和均衡器的边界划在哪？有没有遇到过"本该网关做的事，被迫下沉到均衡器"的坑？