一文读懂：什么是API网关

我在企业架构评审桌上坐了十几年，被问得最频繁的问题之一，就是 API 网关到底是个什么东西，跟手上正跑着的系统有什么关系。我的回答一直很朴素：它是所有外部请求进入你系统之前必须经过的那道门，门上的规矩由它来定。认证怎么验、哪个调用方有权访问哪个接口、一分钟最多调多少次、后端服务挂了拿什么兜底、调用日志留多久、返回的手机号和身份证号要不要脱敏，这些事全在门口处理完，不让它们渗进每一个业务模块里。这么干的直接好处是，写业务代码的人不用再操心 token 怎么校验、灰度怎么切流量、超时怎么重试，横切关注点集中在一层解决，改一次全生效。

把它理解成一道”门”其实还是低估了。成熟的做法里，网关承担的是接口生命周期的一部分：注册、发布、灰度、下线、版本切换、调用方授权、配额管理，都能在这一层找到痕迹。没有网关的系统不是跑不起来，而是回答不了”这个接口还有谁在用”这个问题。我做过一次接口盘点，一个跑了四年的老系统里挂着六百多个接口，其中一百多个已经半年没人调用，可没人敢下掉，因为不清楚断掉会牵连到谁。这就是入口没人管的代价，平时看不出来，一到审计或者故障复盘就全暴露了。

还有一点我常提醒团队：网关装上不等于治理完成，它更像一套需要长期执行的纪律。工具上线只是开头，接口命名怎么统一、版本怎么演进、新调用方怎么审批、老接口怎么公告下线，这些人和流程的部分才是真正难啃的骨头。下面这张表是我做架构评审时一定会逐项对照的能力清单，缺哪一项，后面都会以故障或者返工的形式补回来。

前几年微服务拆分的时候，网关几乎是标配，后来有些团队拆得过细，网关跟着一起挨骂。真正起变化的是最近两三年：接口从”系统内部的东西”变成了”要对外交付的资产”。这个身份一变，要求就完全不同了。

我接触的制造、能源、金融客户里，越来越多的场景是这样：订单要给经销商查、库存要给渠道平台查、设备运行数据要给合作伙伴用、企业的数据要开放给外部做分析。接口一旦对外，它就不再是几个开发之间的事，而是一份有边界、有配额、有审计要求的服务契约。谁签的、能看哪些字段、每月调用多少次，都得说得清。

另一股推力来自数据要素和 AI。企业把数据整理成接口供内部系统甚至大模型调用，接口数量往往从几十个涨到几百上千个。网关在很多项目里已经不只是技术组件，它是接口资产的登记口和计量口：进来的每一个调用留下记录，出去的每一份数据能追到源头。这事在合规检查的时候价值最大，平时不觉得，被问到的时候就知道有没有了。

我的判断是，只要你的系统开始对外提供接口，或者内部调用方超过三五个，这件事就绕不过去，无非是早做还是晚做。晚做的成本通常更高，因为要在一堆已经跑起来的接口上补台账、补鉴权、补版本策略。

这四个词经常在同一场会上被混着用，我每次都得先掰扯清楚，不然方案没法往下谈。它们解决的不是同一层问题，硬凑到一起只会让架构图越来越厚。

我的经验是：反向代理解决的是”怎么把包送到”，网关解决的是”该不该送、送多少、送完记什么账”。这两件事可以叠在一起做，但不能互相替代。ESB 那一代产品喜欢把编排、转换、路由全塞进一个中心，结果运维复杂度上去了，我在一些老项目里见过一个集成平台上挂了两百多个流程，改一处要停半天。

服务网格管的是服务与服务之间的通信，对外的入口它管不着，把入口的事交给它属于用错工具。所以架构图里怎么摆，我心里有杆秤：入口层放网关，管身份、管配额、管审计；服务之间用轻量通信加治理；需要跨系统编排的，尽量下沉到业务服务里，别都堆在中间件上。

坑一，默认内网可信。我见过一个项目，网关只配了路由没配鉴权，理由是”这些接口只有内网调”。后来一台测试机被入侵，攻击者顺着内网把能扫的接口全扫了一遍。内网不是信任边界，”只有内网调”从来不是不鉴权的理由。

坑二，路由靠人工维护。接口改名、换端口，网关配置没人同步，等到上线后 404 报警才发现。我的做法是让接口注册先于网关发布，路由从注册信息自动生成，人只审批不下手改。

坑三，限流阈值拍脑袋，而且配的是全局。有一次客户做活动，一个调用方流量涨了十倍，把整个池子占满，其他合作方全被拒。正确做法是按调用方、按接口、按时间段分别设配额，再留一条紧急降级通道。

坑四，只看网关自己的日志。请求进了后端才报错，网关这边记的是 200，业务真实结果其实在响应体里的错误码。可观测要一路打通到后端，否则排障就是猜谜。

坑五，版本策略失控。有人直接改了线上接口的参数结构，下游静悄悄地报错。灰度发布、小版本并存、下线公告，这些是基本纪律，不是流程负担。这几个坑的共同点是把人想得太自觉，纪律靠自觉守不住，得让工具默认就把口子收住。

我不主张见系统就上网关。判断的维度其实就几个，按重要性排一排，答案基本就出来了。

接口数量是第一个。几十个接口、一两个人维护，配个反向代理加一份命名规范文档，短期内能撑住。过了两三百个接口，还在用文档管，一定会出问题。

调用方数量是第二个，也最关键。只要出现了”外人”——外部合作方、其他部门、第三方终端——就需要一套统一的身份和配额机制，网关在这里没有替代品。

数据敏感度是第三个。涉及个人信息、经营数据的接口，审计要求天然更高，脱敏、留痕、申请审批这些能力必须在入口处有落点。

后端协议是否异构是第四个。HTTP 和 RPC、消息混着用，网关做协议适配和收敛的价值就大；如果全是同一种协议，收益会小一些。

我的取舍原则很简单：先看调用方是不是”外人”，再看数据是不是”敏感”，这两个问题只要有一个是肯定的，网关这件事就别拖。两样都否定，内部三五个服务互调，框架层面的轻量治理就够，硬塞一个网关进来只是多一个要运维的组件。另外团队规模也得看，运维只有半个人的话，别选需要自己拼装和长期调优的方案，选带控制台和生命周期管理的产品，人省下来的时间比省下的授权费值钱。

业务接口的网关只管请求进出，数据类接口还得多管几件事：这条数据从哪个库、哪张表出来的；字段里有没有个人信息；谁申请、批了哪些字段；返回的是脱敏后的还是全量的。这些问题答不上来，接口开放就是给自己埋雷。

我自己的做法是把网关当成数据资产对外的唯一出口：任何一份数据要离开治理范围，先在资产目录里登记，再通过网关开放。普元这套组合里的分工我一般是这样安排的：普元数据资产平台把资产、血缘和权限管清楚，Primeton Data Workshop 负责把数据加工成可发布的接口和数据集，Primeton MDM 保证主数据口径不打架，BI 平台和普元 AI 问数解决人和分析工具的消费，高质量数据集平台给模型训练这类场景准备一份干净、可追溯的数据来源。

这么做的结果，是网关不再是一个孤立的转发组件，而是数据从”被管理”走到”被使用”的那道闸门。谁来申请、批了哪些字段、调用了多少次，全部回到同一本账上。

去年我跟一个装备制造企业的数据团队配合过一轮，状况挺典型。他们内部近九十个系统，接口关系靠一份 Excel 台账维护，更新全靠人记；外部经销商想查订单进度，只能打电话给 IT 部门，IT 再找业务系统的人手动导数；每接一家新合作方，从提需求到能调接口，差不多两周。

我们做的事情不算复杂，但顺序很讲究。先用普元数据资产平台把指标、数据表、责任人和使用情况盘了一遍，哪些数据能开放、哪些只能内部用，一次性说清楚；再用 Primeton Data Workshop 把高频的查询场景做成标准接口和数据服务，发布到统一入口；主数据这边用 Primeton MDM 把客户、物料的口径收口，避免同一个客户在三套系统里有三个编码；面向业务人员的即席查询走普元 AI 问数，能少发一批接口就少发一批。

跑下来几个月，新合作方接入时间从两周压到两天左右，接口台账从 Excel 搬到了平台上，哪个接口没人用一目了然，下线终于有了依据；合规检查要调用记录，直接导出来就是完整的。这件事让我更确信一个判断：网关的价值不在于转发得多快，而在于它让”谁在用数据、用在哪儿”变得可见。可见之后，治理才有抓手。

API 网关和微服务网关是同一个东西吗？

严格说不是一个概念，但实际项目里经常被混着叫。微服务网关通常是随微服务框架一起长出来的那一层，主要服务于内部服务之间的调用，比如某个业务服务调用另一个服务的接口，它更多解决的是服务发现、负载均衡、局部熔断这些事。API 网关站的位