拆微服务的时候很痛快，拆完才发现麻烦在后头：客户端要记十几个地址、每个服务各写一遍鉴权、改个服务名客户端全得跟着改、出了问题不知道卡在哪一环。这篇讲清楚网关到底替你收走了哪些活、几种形态怎么选，以及它现在多出来的一份新工作——给 AI 请求当统一入口。
一、微服务一拆，入口就成了灾难
单体应用的时候，入口只有一个：一个域名，一个端口，完事。
拆成微服务之后，假设你有八个服务——用户、订单、库存、支付、消息、搜索、推荐、风控。这时候问题来了：
- 客户端要记八个地址。前端同学写代码的时候得维护一张地址表，改一个服务名，客户端跟着改。
- 鉴权写八遍。每个服务都要重复实现一遍"这个 token 是谁、有没有权限"。写得多了，总有一两个服务写得不一样——而安全这件事，最怕的就是"不一样"。
- 限流各做各的。A 服务限 100 QPS，B 服务限 500 QPS，加起来到底会不会把数据库打挂？没人说得清。
- 出了问题查不动。一个请求跨了四个服务，日志分散在四处，得靠人肉对时间戳。
- 协议不统一。有的是 HTTP，有的是 gRPC，有的还是老的内部协议，客户端得分别适配。
这些问题的共同点是：它们都不是业务逻辑，但每个服务都得做一遍。
二、API 网关是什么：让所有流量从同一个门进
网关的思路很直白：在客户端和后端服务之间加一道门。
所有请求先到网关，由网关决定转发给谁；所有响应也从网关回去。客户端只需要知道一个地址。
这一道门带来的直接变化：
- 客户端只记一个域名，后端怎么拆、怎么改名、怎么扩缩容，客户端无感
- 鉴权、限流、日志这些横切逻辑，从"八个服务各写一遍"变成"网关写一遍"
- 出问题时，网关是天然的观测点——谁在调、调了几次、慢在哪，一目了然
三、它到底替你收走了哪几件事
1. 路由
把 /api/order/* 转到订单服务，/api/user/* 转到用户服务。后端地址变了只改网关配置。
2. 鉴权
统一校验身份，通过后才转发。后端服务不再各自实现一遍。支持 JWT、OIDC 这类标准体系，也支持自定义鉴权和黑白名单。
3. 限流和熔断
统一的流量管控。某个接口被刷了，在网关层就挡住，不会压到后端。
4. 协议转换
对外暴露 HTTP，对内可以转 gRPC 或其他协议。客户端不用关心后端用什么。
5. 可观测
调用量、耗时、错误率、访问日志——这些在网关上是天然集中的，不用去八个服务里捞。
6. 灰度发布
把一小部分流量切到新版本，观察没问题再全量。这件事放在网关层做，比在每个服务里做要省事得多。
四、形态怎么选
阿里云这边主要有几种形态，判断起来不复杂：
云原生 API 网关 —— 主力形态，兼容 K8s Ingress 标准，支持微服务、函数计算等多种后端，也支持 K8s、Nacos 等服务发现。传统的服务暴露和流量管控用它。
AI 网关 —— 专门面向 AI 场景，统一代理大模型 API 和 MCP Server。有包年包月和 Serverless 两种，后者按用多少付多少，门槛更低。
Serverless 实例 —— 用多少付多少，适合流量不稳定或者刚起步的场景。
选的时候想一件事：你的流量稳不稳、量有多大。 稳定且量大，包年包月的实例更划算；波动大或者刚起步，Serverless 起步成本更低。具体规格和价格以官方页面的实时展示为准。
五、它现在多了一份新工作：给 AI 请求当入口
这两年网关的活变多了。以前它管的是"你的服务被调用"，现在还得管"你去调别人家的大模型"。
这件事的麻烦在于：大模型的调用是散的。业务 A 直接调一个模型，业务 B 又调另一个，各写各的 API Key，各记各的用量。到月底想知道"token 都花在哪了"，基本靠猜。
AI 网关做的事情是把这些收口：
- 统一代理 —— 不管后端是哪家的大模型，对外提供统一的访问方式（比如 OpenAI 兼容），换模型不用改业务代码
- 二次 API Key 签发 —— 业务拿的是网关签发的 key，真正的 key 不散落在各处
- Token 治理 —— 每个请求谁在用、用在哪个场景、花了多少，可观测也可管控
- 内容安全 —— 输入到外部模型的数据做隐私保护，模型输出给用户的数据做内容过滤
- LLM 负载均衡与智能路由 —— 多个模型之间做调度
还有 MCP Server 的统一代理和认证——这块是新兴场景，但思路一样：别让每个业务各接一套。
说白了，网关管 AI 流量这件事，跟它当年管微服务流量是一个道理：散着做一遍，不如收口做一遍。
六、什么时候该上，什么时候别上
该上：服务超过三四个且还在增加、需要统一鉴权和限流、要跨服务做灰度、开始有多个团队共用一个入口、AI 调用散落在多个业务里。
别急：就一个单体应用，一个域名搞定——那网关是给自己找活干。网关带来的是集中管控的能力，代价是多一层网络和一套要维护的配置。服务没到那个数量级，这一层是负担不是收益。
七、避坑清单
- 网关成了单点 —— 收口的同时也集中了风险，高可用和容量规划要做好（SLA 和性能指标看官方说明）。
- 把业务逻辑写进网关 —— 网关该做的是横切逻辑。业务规则一旦混进去，它就会变成新的"大泥球"。
- 超时时间没对齐 —— 网关超时比后端短，会莫名出现大量 504。各层超时要理一遍。
- 限流配得太乐观 —— 限流值不是拍脑袋定的，得按后端真实承载能力来。
- 不做灰度就全量切 —— 网关的价值之一就是能灰度，白放着不用可惜。
- 日志只记不看 —— 网关是最集中的观测点，配了告警才算真的用上。
小结
网关收口的是重复劳动：路由、鉴权、限流、日志、灰度——这些活每个服务都写一遍，不如统一写一次。
拆微服务拆到一定程度，网关不是可选项，是必需品。但别为了上网关而上网关——就一个服务的时候，它是纯负担。
如果你的服务已经开始变多、或者 AI 调用散得收不住了，可以从API 网关开始，先把鉴权和限流这两件最该统一的事收进来，再逐步把路由、灰度、观测加上去。一次性设计得大而全，往往是迈不动的第一步。
