API 网关:微服务的统一入口 —— 别让客户端挨个去敲几十扇门

单体拆成微服务，几十个服务散在各处——客户端难道要挨个去调？ 每个服务还得自己做一遍鉴权、限流、跨域、日志？解法是在所有服务前面架一道统一大门——API 网关：请求只认这一个入口，家家都要做的事统一在门口办完。这篇讲清楚它能做什么、以及哪些东西千万别往门里塞。

---

一、是什么:所有外部请求的统一入口

是什么。 API 网关(API Gateway)是所有外部请求进入系统的唯一入口。客户端不再直接连后端的某个具体服务,而是统一把请求打到网关;网关根据请求(路径、域名、Header 等)决定转发给哪个后端服务,拿到结果再返回给客户端。一句话——

API 网关 = 统一入口 + 路由转发 + 把"家家都要做的横切关注点"从各服务下沉到门口。

这里的关键词是横切关注点(cross-cutting concern):像鉴权、限流、熔断、日志、跨域处理这类逻辑,几乎每个服务都要做一遍,却又跟具体业务(下单、支付)没什么关系。它们横切在所有业务之上,与其让每个服务各写一份、各踩一遍坑,不如统一抽到网关这一层集中处理。

打个不太严谨但好懂的比方:网关就像写字楼大堂的前台兼安保。访客不用挨家挨户去敲每个公司的门——先到大堂,前台查证件(鉴权)、控制人流(限流)、登记进出(日志),确认没问题了再指路到对应楼层(路由转发)。每家公司自己不用再单独养一个前台。

注意一个边界:网关只管"门口的事",不管"屋里的业务"。 它负责把请求正确、安全、可控地送到该去的服务,但下单的金额怎么算、库存怎么扣,这些业务逻辑是各服务自己的事,网关不掺和。这条边界后面第五节会专门展开——它是网关用好用坏的分水岭。

二、为什么:没有网关,痛点全压在客户端和每个服务身上

为什么需要它? 因为微服务拆开之后,如果不收口,有三类痛点会立刻浮出来,而且越拆越痛。

痛点 1:客户端要知道所有服务的地址。 没有网关,App / 浏览器就得自己记住"用户服务在哪、订单服务在哪、支付服务在哪"。服务一旦扩容、迁移、改端口,所有客户端都得跟着改——而客户端(尤其是已经发出去的 App)是最难推动升级的一方。等于把后端的拓扑变化,直接捅到了最不该承受它的地方。

痛点 2:每个服务都重复实现鉴权、限流。 鉴权要不要做?要。限流要不要做?要。跨域(CORS)要不要处理?要。于是每个服务都把这套逻辑抄一遍——抄得不一致是迟早的事:这个服务校验了 Token、那个忘了;这个限了流、那个裸奔。一旦鉴权规则要改(比如换个 Token 校验方式),得挨个服务去改一遍,改漏一个就是一个安全口子。

痛点 3:协议转换、跨域、日志……散落得到处都是。 外部用 HTTPS,内部服务之间可能用别的协议;前端要的字段格式,和后端服务吐出来的未必一致。这些"适配"工作如果不收口,就会东一块西一块地散落在各个服务里,没人说得清全貌。

网关的核心价值,就是把这些"家家都要做、又跟业务无关"的事收口到一处。 客户端只认一个入口(地址变化对它透明),鉴权限流只在门口做一遍(规则统一、改一处生效),协议和跨域的适配集中管理。拆微服务带来的散乱,被网关重新收成了一个清晰的入口。

三、网关都干什么:六类典型活儿

实际场景。 把网关在生产里真正承担的活儿摊开,大致是下面六类。前几类是"门卫本职",后几类是"顺手能干、且最适合在门口干"的事。

1. 路由转发(本职)。 这是网关的立身之本:根据请求的路径前缀、域名或 Header,把请求转给对应的后端服务。比如 /api/user/* 转给用户服务、/api/order/* 转给订单服务。配合后面会讲的服务注册发现,网关还能动态拿到服务实例列表,自动做负载均衡,某个实例挂了就不再往它身上转。

2. 统一鉴权。 在门口统一校验身份与权限:验 Token 是否合法、是否过期、这个用户有没有权限访问这个接口。校验通过后,网关通常会把解析出的用户身份(用户 ID、角色等)透传给后端服务,后端就不必再各自验一遍 Token。

Token 怎么签发与校验(JWT / OAuth)、权限模型怎么设计(RBAC),是鉴权专题讲的事。网关是这套机制最常见的落地位置——把鉴权专题里的逻辑,统一放在门口执行一遍。

3. 限流与熔断。 在入口处控制流量:对单个用户、单个 IP 或整个接口设阈值,超过就拒绝(标准是返回 429 Too Many Requests),保护后端不被打垮——不管是恶意刷还是调用方写了死循环。再配合熔断:某个后端服务持续出错或超时,网关暂时不再往它转发,直接快速失败,避免拖垮整条调用链。

限流的算法(令牌桶、漏桶、滑动窗口)、熔断降级的策略,是**「高并发三板斧」篇**(缓存、限流、降级)的主场。网关是限流最理想的执行点之一——流量还没进到业务里,就在门口被拦下来了。

4. 协议转换。 外部统一走 HTTPS / HTTP,内部服务之间可能用更高效的协议(如 gRPC)。网关在中间做一层翻译,让外部客户端不必关心内部用什么协议;也能在这一层做请求/响应格式的轻度适配。

5. 灰度发布 / 流量调度。 上新版本时,可以让网关先把一小撮流量(比如 1% 的用户、或带某个标记的内部用户)导到新版本服务,其余仍走老版本,确认稳定再逐步放量。这种"灰度发布 / 金丝雀发布"很适合在网关这层做,因为流量分配的开关本来就握在入口手里。

6. 日志与监控入口。 所有外部请求都从网关过,这里天然是统一记录访问日志、采集指标(QPS、延迟、错误率)、串联链路追踪 ID 的好位置。它是观测整个系统对外服务质量的"第一现场"。

链路追踪、指标采集这些怎么做,属于**「跑得稳」专题**(可观测性)的范畴;网关只是其中一个关键的埋点入口。

四、业界怎么做:主流网关 + BFF 模式

业界主流方案(客观罗列,不是推荐)。 API 网关是个非常成熟的领域,开源和商业方案都很多,选型时大致绕不开下面这几类:

• Nginx:很多人最早接触的"网关"其实就是它。本职是高性能反向代理 / 负载均衡,加上 Lua 扩展(OpenResty)后能做鉴权、限流等。轻量、性能强,但纯靠它做复杂网关逻辑要写不少配置和脚本。
• Kong:基于 Nginx / OpenResty 之上做的插件化网关,鉴权、限流、日志等都做成插件,装上即用,带管理 API 和控制台。生态成熟,是云原生网关里被提及很多的一个。
• APISIX:同样是云原生方向的开源网关,以动态配置、热更新、高性能著称,插件生态也比较活跃。和 Kong 常被放在一起对比。
• Spring Cloud Gateway:Java / Spring Cloud 体系里的官方网关,和 Spring 全家桶(注册发现、配置中心)无缝衔接。如果后端就是 Spring Cloud 微服务,它是顺理成章的选择。

还有一个常被和网关一起提的概念:BFF(Backend For Frontend)。 直译是"为前端服务的后端"。它解决的是另一个问题——不同端(Web、App、小程序)需要的数据形态不一样:App 屏幕小、想要精简字段、最好一次请求就把首页要的几块数据都拿回来;Web 端可能要更全的数据。如果让每个端都直接拼调好几个后端服务,前端会很累。

BFF 的做法,是为每类前端单独搭一层"专属后端":它面向某一个端,聚合(把多个后端服务的数据拼到一起)、裁剪(只返回这个端要的字段)、适配(转成这个端方便用的结构)。前端只跟自己的 BFF 打交道,复杂的聚合逻辑收在 BFF 里。

BFF 和网关什么关系? 简单说:网关是"通用大门",BFF 是"为某个端定制的接待"。网关做的是所有请求都通用的事(路由、鉴权、限流),不关心你是哪个端;BFF 做的是某个端专属的数据聚合和裁剪。两者常常配合——请求先过网关(统一鉴权限流),再到对应的 BFF(按端聚合数据),BFF 背后才是真正的微服务。不过 BFF 也有代价:端多了,BFF 层也会跟着变多、各自要维护,别为了一个端就轻易加一层。

五、注意事项:别让大门变成瓶颈,也别把业务塞进门里

注意事项。 网关用好是利器,用歪了反而成新的麻烦源。几条最关键的:

• 网关绝不能是单点。 所有外部流量都从它过——它一挂,整个系统对外就全断了。所以网关自己必须高可用 + 可水平扩展:部署多个网关实例,前面再架一层负载均衡(或云厂商的 SLB / ALB)把流量分到各实例。把全部鸡蛋放进一个网关进程,是最危险的反模式。
• 警惕网关变成性能瓶颈。 所有请求都经它中转,它的延迟会叠加到每一个请求上。所以网关上的逻辑要尽量轻、快:鉴权、限流这类校验要高效,别在网关里做重计算、读大量数据、调一堆下游再聚合(那种重聚合是 BFF 该干的,不是通用网关)。
• 别把业务逻辑塞进网关。 这是最常见、也最隐蔽的坑。网关一旦"什么都能拦一道",就容易被顺手塞进各种业务判断——"这个接口顺便在网关算个折扣""那个顺便在网关查个库存"。塞着塞着,网关就变成了一个谁也不敢动的巨型单体,彻底背离了拆微服务的初衷。网关只做横切的、与具体业务无关的事;业务逻辑永远归各自的服务。
• 想清楚网关层和服务层的职责边界。 一个好用的判断标准:这件事是不是"家家都要做、且和具体业务无关"? 是(鉴权、限流、路由、日志)→ 适合放网关;不是(订单金额怎么算、库存怎么扣)→ 留在服务里。边界一旦模糊,网关迟早膨胀失控。
• 网关也要纳入观测和容量规划。 它是全站流量的咽喉,它的 QPS、延迟、错误率必须被重点监控;扩容时也别忘了它——后端服务都扩了,网关没跟上,瓶颈就卡在门口了。

六、AI 时代的网关:LLM 网关

网关"统一入口 + 横切下沉"这套思路,在 AI 应用里长出了一个专门的变种——LLM 网关(LiteLLM、One API 这类)。一个稍微正经点的 AI 应用,往往要同时调好几家大模型(OpenAI、Claude、自建的开源模型),每家的接口、计费、限流都不一样;要是让每个业务模块自己去对接,又是一遍"家家重复"的老毛病。LLM 网关就是把这些收口到门口:

• 统一接入。 把各家大模型五花八门的 API 抹平成一套统一接口,业务侧只调网关,不关心后面到底是哪家。
• Key 管理与计费。 各家的 API key 统一托管,按调用方统计 token 消耗、做配额和成本核算——这正是网关"统一鉴权 + 日志计量"的翻版(钱的部分见《成本》篇)。
• 限流与降级。 大模型又贵又有速率限制,网关在门口按调用方限流;某家模型挂了或超时,自动切到备用模型——就是「高并发三板斧」的熔断降级,搬到了模型调用上。

说白了,LLM 网关没发明新东西:还是那道"统一大门",只不过门后从一个个微服务,换成了一个个大模型。网关这套老思想,在 AI 场景里照样成立。

七、一张表

先看网关的核心职责,再看主流网关的横向对比——把这一篇收进两张小表:

网关的核心职责(以及它"该干 / 不该干"什么)

职责	干什么	关联篇目
路由转发	按路径/域名转给对应服务,做负载均衡	服务注册发现
统一鉴权	门口校验身份与权限,透传用户信息	鉴权专题
限流熔断	入口控流、超限返 429、下游故障快速失败	「高并发三板斧」篇
协议转换	外部 HTTPS ↔ 内部协议(如 gRPC)适配	——
灰度发布	按比例/标记把流量导到新版本	——
日志监控入口	统一记访问日志、采指标、串链路 ID	「跑得稳」专题(可观测性)
业务逻辑	❌ 不该放——业务归各自的服务	——

主流网关横向对比(客观,非推荐)

方案	定位	特点	适合
Nginx	反向代理 / 负载均衡	轻量、性能强;复杂逻辑靠 Lua 扩展	简单路由、起步阶段
Kong	插件化云原生网关	基于 Nginx,鉴权限流即插即用	想要现成插件生态
APISIX	云原生网关	动态配置、热更新、高性能	看重动态能力
Spring Cloud Gateway	Spring 体系官方网关	与 Spring 全家桶无缝衔接	后端是 Spring Cloud

---

名词解释

• API 网关(API Gateway):所有外部请求进入系统的统一入口,承担路由转发,并把鉴权、限流、日志等横切关注点从各服务下沉到此处集中处理。
• 路由(Routing):根据请求的路径、域名或 Header,决定把它转发给哪个后端服务。
• 横切关注点(Cross-cutting Concern):像鉴权、限流、日志这类几乎每个服务都要做、却与具体业务无关的逻辑;横切在所有业务之上,适合统一抽到一层处理。
• 反向代理(Reverse Proxy):代客户端把请求转发给后端服务、再把结果带回的中间层;网关的路由转发本质上就是一种反向代理。
• 熔断(Circuit Breaker):某个下游服务持续出错/超时时,暂时停止向它转发请求、直接快速失败,避免拖垮整条调用链。
• 协议转换:在网关层把外部协议(如 HTTPS)翻译成内部服务使用的协议(如 gRPC),让客户端不必关心内部实现。
• 灰度发布 / 金丝雀发布(Canary Release):先把一小部分流量导到新版本,验证稳定后再逐步放量的发布方式。
• BFF(Backend For Frontend):为某一类前端(Web / App / 小程序)单独搭的专属后端层,负责按这个端的需要聚合、裁剪、适配数据;与"通用大门"式的网关分工不同。
• 429 Too Many Requests:限流触发时返回的标准 HTTP 状态码,表示请求过多、已被限流。
• 单点(Single Point of Failure):系统中"一挂全挂"的关键节点;网关若不做高可用与水平扩展,就会成为这样的单点。

---

本文是《研发都要懂的事》·服务端架构设计系列的一篇——讲微服务拆开之后,怎么用一道统一大门把入口收口。门口要做的鉴权细节见鉴权专题,限流熔断见**「高并发三板斧」篇**,接口本身怎么设计见 API 设计专题。