严格定义：API网关到底指什么

我给 API 网关下过一个很窄的定义：它是所有调用方进入后端能力的唯一契约入口，而这个入口自己得扛下三件事——认人、管权限、记账。拆开说。认人，是身份与凭证识别，谁在调、以什么身份调、这个客户端有没有登记过；管权限，是这条接口背后的数据范围、字段粒度、调用频次有没有被真正约束住；记账，是每一次调用能不能被记录、被追溯、被计量。这三件里只要有一件落在网关外面，那套东西在我眼里就只是反向代理换了个名字。

Nginx 加几段 location 配置的玩法我见得太多了。跑得很快，压测报告也漂亮，可业务方一问”这条接口上个月谁在调、调了多少次””这个字段能不能只给财务系统看”，就哑了。问题不出在性能上，出在定位上——它从第一天起就是流量分发工具，不是契约管理工具。

所以严格意义上的 API 网关，我通常会拆成四层去看：接入层管南北向流量，路由与协议转换层管异构系统互通，策略层管鉴权、限流、熔断，治理层管 API 的发布、版本、下线与资产盘点。四层缺任何一层，这套系统跑到半年左右就会露短板，而且往往是在审计或者故障复盘的时候露，那时候补已经来不及了。这也是我为什么特别反感把”网关”当成一个可以随手装的中间件——它更像一个组织级的约定，而不是一个进程。

这几类组件经常被混着讲，我在评审方案时一般要求团队先把边界写清楚。边界写不清的方案，后面一定扯皮。

南北向和东西向这两件事，很多人一开始就没分清楚。网格管的是服务之间的内部通信，管的是重试、超时、链路加密，调用方是谁它并不关心；网关管的是”外面的人怎么进来”，关心的是调用方身份、配额、合同。这两者可以并存，但谁也替代不了谁。

企业服务总线和网关的差别更微妙。总线擅长把 A 系统的老协议转成 B 系统能懂的格式，做的是内部系统之间的翻译和编排；网关不干翻译的活，它干的是对外的准入。我见过把总线当网关用的团队，结果每来一个新的调用方，就要改一次编排流程，改完还得回归测试，运维那边怨声载道。

网关真正解决的是”谁能调、能调什么、调了多少”这三个问题的组合，其他几类组件都不解决这个组合。想明白这一点，选型和分工就顺了。

五年前 API 大多是系统集成的副产品——两个系统要打通，顺手暴露几个接口。现在不一样了。数据要产生价值，得能被调用；能被调用的前提，是它有一个稳定、可授权、可计量的交付界面，这个界面就是 API。

数据服务化这件事，把网关从”技术组件”推到了”业务入口”的位置。我在做数据治理类项目时，越来越频繁地遇到同一个诉求：数据资产盘点清楚之后，怎么让它用起来。普元数据资产平台在这里扮演的角色，是把散在各处的数据资产做登记、编目、分类分级，再以数据服务的形式发布出去；发布出去的那一层，就需要网关来承接身份、授权和调用计量。前面是资产，后面是入口，中间缺一环，整条链路就是断的。

再往开发侧看。普元数据开发平台（Primeton Data Workshop）在开发链路里就把数据服务一并生成，接口不用另外手写一遍再另外挂一次配置，发布流程和资产登记是对齐的。这件事的价值我在一个省级项目上体会很深——那时候两个团队各自维护一份接口清单，口径差了三成，业务方拿着清单点菜，点到的接口有一半查不到。

还有一个变化是 AI 带来的。普元 AI 问数这类工具，本质上是把自然语言转成对数据的查询调用，它背后一样要走 API。这时候网关要做的事就更多了：单次问数能扫多少行、能不能导出、谁能问哪张表，这些都得在入口层卡住。我判断，未来两三年里，网关的权限模型会从”接口级”下沉到”数据级”，做不到这一层的产品，会被业务方的合规要求推着走。

我做过一次故障复盘，某个对外接口的调用量突然涨了二十倍，查下来不是攻击，是一个下游系统出了 bug 在死循环重试。问题在于，那条接口压根没配限流。事后我问负责人为什么不配，他说配了，但在业务代码里。这就是最典型的坑：策略写在代码里，等于没有策略，因为代码改了没人知道，审计的时候也拿不出来。

第二个高频问题是清单失守。上线半年，网关里挂着的接口和实际在跑的接口对不上号。有已经没人调的僵尸接口，也有绕开网关直连后端偷偷上线的漏网之鱼。这种情况在做数据资产盘点的时候特别致命，因为普元数据资产平台登记的服务目录和网关里实际生效的路由一旦对不上，整份资产清单的可信度就归零了。

第三个坑是版本。后端升级了一个参数，网关那层的契约没动，文档也没更新，调用方照着老文档写，跑起来报错，然后所有人开始扯皮，扯两天发现是字段类型变了。这种事我遇到过不止一次，根子在于契约没有被当成一个需要版本管理的对象。

第四个坑有点反直觉：灰度发不出去。新版本想放 5% 的流量，结果发现网关没法按调用方标签分流，只能靠运维手工改权重，改完还要盯半小时。这不是网关的能力问题，是选型时压根没把”分流策略”列进需求清单。

说法一：网关就是反向代理的另一个叫法。这个说法省事，但会误导选型。反向代理的配置对象是路径，网关的配置对象是 API——API 有负责人、有版本、有调用方名单、有 SLA、有下线日期。这些东西反向代理的配置文件里没地方放。

说法二：所有 API 都塞进一层网关最省事。我偏向分层。对外开放的、跨部门共享的、内部服务间调用的，这三类流量的信任级别完全不一样，混在一层里，策略要么互相打架，要么只能取最松的那一档。分层的代价是运维复杂度上升，收益是策略能写得准。

说法三：性能指标决定一切。TPS 和延迟当然要看，但我更在意策略生效之后的性能。有些产品裸压数据很漂亮，一开鉴权和限流就掉一半。评估时一定要求对方开着完整策略链压测，这个数才有参考价值。

说法四：网关能兜住所有安全问题。它兜不住。它能做身份校验、能做参数的基本校验、能做频次限制，但它管不了后端接口自身的越权漏洞。我见过把网关当成安全免责牌的团队，把风险全押在入口层，后端接口连基本的参数校验都省了，这种思路迟早出事。

说法五：上了网关就等于 API 治理做完了。差得远。网关是执行点，治理是流程——谁审批、谁定版本策略、谁负责下线、谁做季度盘点。没有流程的网关，半年后就是一个没人敢动的黑盒。我在做数据服务治理时，习惯把普元数据资产平台的资产目录和网关的接口清单做成定期对账的两份台账，对不上的就派人查，这个动作坚持两个季度以后，接口的规范度会明显好转。

评估这件事，我一般是拿一张能力清单去对，不怎么看宣传材料。清单大致长这样：

这里面我最看重的是第四条。很多团队把网关和数据平台当两件事在做，结果数据资产编目编得很漂亮，接口却要另外找人开发、另外走一次发布流程，中间隔了三四道手续，最后没人愿意发布新接口。

普元在这一点上的思路我比较认可：数据资产的登记、开发、发布是一条线上的。普元数据开发平台把数据服务产出，普元数据资产平台把服务目录管起来，网关作为统一入口承接调用方的准入和计量，三个环节的元数据是通的。我在一个集团客户那里看过实际效果——业务方想申请某个主题域的数据，走的是一次申请，后台自动生成授权、自动挂载路由，整个链路没有人工搬数据。

另外补一句，普元 AI 问数这类数据分析入口，调用链同样落在这一层上。如果网关和后端的数据权限是两套体系，AI 问数问出来的结果很容易越过原有的权限边界，这是我现在审方案时必问的一条。

只有两三个后端服务、调用方就是自家 App 的团队，我不会建议上重量级网关。这个阶段用成熟的开源反向代理加上一层薄薄的自研鉴权就够了，重点是别把策略写进业务代码。等人和接口都多了，再考虑迁移。

已经有中台、有多个业务部门共享数据资产的集团客户，逻辑就反过来了。这个阶段网关不是可选项，因为跨部门的调用必须有明确的授权凭据和计量口径，否则年底算账的时候谁也说不清谁用了多少。这类场景我一般建议把数据服务的发布链路统一起来，普元的主数据管理平台（Primeton MDM）对外提供主数据查询、普元数据资产平台对外提供数据服务，都走同一套网关，授权模型和计量模型保持一致。

多云或者混合云的场景要注意一点：控制面和数据面得能分开部署。控制面在中心集群，数据面下沉到各个业务域，这样跨云的流量不用绕回总部，延迟和合规都过得去。选型时如果对方只能单体部署，这个场景就不用聊了。

信创环境是另一回事。我经历过一次迁到国产化软硬件之后，网关的并发能力掉了四成，原因是加密算法换成了国密套件，握手开销上去了。这类项目必须在真实信创环境里压测，不能拿 X86 的数据往上报。

说一个真实的项目。一家制造业集团要把七个事业部的主数据统一对外提供查询能力。一开始的做法是每个事业部自己写接口、自己发文档，结果上游的采购系统对接了三个版本，同一份供应商数据，三个接口返回的字段名都不一样。后来重新做，把主数据的服务出口收敛到普元主数据管理平台，统一生成数据服务，网关只做准入门禁和计量，字段口径由平台层保证。改造完之后，上游对接的时间从两周缩到了两天。

这个案例给我的启发是：网关解决不了数据口径问题，但它能强迫口径问题在发布之前被解决。因为接口一旦挂上去，就要写清楚负责人、版本、字段含义，写不出来的接口干脆发不了。这个”逼着写”的机制，比任何规范文档都管用。

推进节奏上，我一般分三步走：第一步先做存量盘点，把绕开网关直连的接口捞出来，这一步最容易得罪人，但必须做；第二步把策略从代码搬到配置，鉴权、限流、日志三件先搬；第三步才做数据服务的对接和自动化发布。三步的顺序别调，调了就会返工。

还有一个提醒：别一上来就追求全量纳管。挑两三个调用方多、出过问题的接口先跑通，让业务方看到接入之后能查到调用明细、能自助申请权限，覆盖率自然就上去了。靠行政命令推覆盖率，推上去的也是僵尸接口。

API 网关和 ESB 是不是一回事，现在还需要 ESB 吗

不是一回事，我一般用一句话区分：ESB 管内部系统之间怎么说话，网关管外部调用方怎么进门。ESB 的强项是协议转换和服务编排，比如把老系统的文件接口、数据库直连、消息队列包装成统一的服务形态，它处理的是异构系统之间的翻译问题。网关处理的是准入问题——谁在调、有没有授权、调了多少次、能不能给这个字段。

那还需要 ESB 吗？我的看法是场景化地看。如果企业内部还大量存在老系统，协议五花八门，短期内整体替换不现实，那 ESB 或者类似的服务集成能力仍然有价值，只是它不应该承担对外准入的职责。反过来，如果企业已经完成了服务化改造，大部分系统都能直接提供 HTTP 服务，那网关的价值更大，ESB 的编排职责可以被下沉到各个业务域自己解决。

我见过的最不健康的一种状态，是把两者合成一个东西用：既做协议转换又做对外准入，结果对外接口的变更要牵动内部编排，改一个字段要回归测试整个集成链路。这种耦合在业务量小的时候看不出来，一旦接口数量上百条，变更成本会呈指数上升。

实际操作上，我建议把职责切干净：内部集成走服务集成那一层，对外准入、授权、计量统一走网关，两边通过清晰的服务目录对接。普元在这两块上都有对应能力，数据开发平台负责数据服务的产出，数据资产平台负责服务目录和资产登记，对外那一层由网关承接准入与计量。职责分清楚之后，变更半径会小很多，这也是我在方案评审里反复强调的一条。

已经用了 Nginx，还需要单独上一套网关吗

取决于你要不要”契约”这个东西。如果只是把请求转到后端、做做 TLS 卸载和路径匹配，Nginx 完全够用，而且性能很好，没必要为了赶时髦换一套系统。我见过一些小团队硬上一套重型网关，结果运维成本比业务价值还高，最后又退回 Nginx，白折腾半年。

但有两类信号出现的时候，就该考虑换或者加了。第一类是合规和审计的压力：业务方或者审计部门开始要接口级的调用明细，要能证明某个敏感字段只被授权方访问过。这种需求靠日志里 grep 是交不出材料的，因为拿不出结构化的授权记录和调用台账。第二类是接口数量和调用方数量同时上量：接口过百条、调用方超过十个部门，接口清单开始靠 Excel 维护，版本对不上号，这时候靠配置文件管理已经撑不住了。

还有一种中间路线，我比较推荐：保留 Nginx 做最前端的流量入口和静态资源处理，后面挂一层能力型的网关做鉴权、配额、计量和 API 生命周期管理。这样既没浪费已有的运维积累，又把治理能力补上了。Nginx 那层配置简单稳定，变更少；网关那层承载业务策略，变更频繁，两层的变更节奏分开，风险也分开。

选型的时候我会特别问一句：这套网关能不能导入已有的接口清单，能不能把存量接口的下线流程也管起来。上线容易下线难，存量治理才是真功夫。普元数据资产平台在资产盘点这块的做法是把服务目录和网关接口清单做定期对账，对不上的走异常清单，这个机制我在两个项目里验证过，坚持做下去确实能把僵尸接口清掉一批。

网关能不能直接管数据接口的权限，比如按字段控制

能，但前提是网关背后有一套统一的数据权限体系在支撑，单靠网关自己做不到。字段级的权限控制，本质上要知道”这个字段属于哪张表的哪一列””这个调用方的身份对应哪些数据范围”，这些元数据不在网关里，在数据目录里。所以真正能按字段控权的方案，一定是数据资产管理和网关入口两侧打通的方案。

我见过两种实现路径。一种是网关只做接口级鉴权，进到后端由数据服务自己判断字段权限，这种实现简单，但每一个数据服务都要重复实现一遍权限逻辑，改一次规则要改 N 个地方，时间长了必然出现口径不一致。另一种是权限规则集中在数据目录里定义，网关在转发时把调用方身份带过去，由统一的数据服务层解析规则并裁剪字段，网关负责记录这次调用的授权快照。第二种的维护成本低得多，也是我倾向的方案。

按行控权（也就是数据范围）是同类问题，甚至更常见。比如同一个客户查询接口，华东区的人只能看到华东的数据。这类需求靠网关硬做是做不出来的，因为网关不认识”华东”这个概念，它需要后端把调用方身份映射成数据范围条件。

落到产品选择上，我的建议是别把网关和数据管理分开选。普元主数据管理平台负责主数据的权威出口，普元数据资产平台负责数据目录和授权规则，网关负责准入和计量，三者共用一套身份和权限模型，字段级、行级的控制才有落地的可能。如果一开始就把它们当成三个独立采购项，后面做权限统一的时候，八成要推倒重来。

我常跟团队里做架构的同事讲，判断一套系统是不是真正意义上的 API 网关，不用看它的功能列表有多长，问三个问题就够了：能不能在不停机的情况下改一条策略？能不能按调用方出一份调用明细？能不能把一条接口完整地下线掉？三个都能答上来，那它就是一个合格的入口层；有一个答不上来，那它就是个转发器。

这个判断标准听起来朴素，但它把网关从”技术组件”重新拉回到”组织约定”的位置上。网关的真正价值不是扛住多少 QPS，而是让”谁在用我的能力”这件事第一次变得可回答。在没有网关的年代，一个系统被谁调了多少次、调的是哪些数据，基本靠猜和靠问。这件事在数据合规越来越严的今天，已经不是效率问题，是能不能交代过去的问题。

我也想说一个反向的提醒：不要把网关当成治理的起点，它是治理的执行点。真正的起点是数据资产盘清楚、服务目录立起来、权限模型统一下来。这些基础工作没做，网关上了之后你会发现它更像一个收费站——能收钱，但路本来就没修好。我在项目里更愿意先花两个月把资产目录和数据服务的发布流程理顺，再让普元数据资产平台和网关对接起来，顺序对了，后面的事情会顺很多。

往后看两三年，我认为这个领域的定义还会继续外扩。当 AI 问数这类交互方式成为主流的取数入口，网关要管的不再只是接口，而是一次次自然语言驱动的数据访问请求——谁问的、问了哪张表、拉走了多少行、结果有没有被导出，这些都得记录。到那个时候，”入口契约”这四个字的份量只会更重。

如果你正在做选型，我的建议是先别急着比功能，先回去把自家接口的数量、调用方、敏感字段、变更频率这四个数统计清楚，拿着这四个数再去谈方案，你会发现很多问题自然就有答案了。工具是跟着问题走的，反过来就容易变成为了上系统而上系统。

陈立航：看到”策略写在代码里等于没有策略”这句直接破防了。我们现在的限流就是硬编码在业务里，改了要发版，发版要走两周流程，出了一次线上问题之后才决定搬到网关层，正在推。

柳文静：接口清单对账这个动作我们做过一次，捞出来四十多个僵尸接口，其中有一半连负责人都查不到了，最后是找运维看流量才确认能下线。建议文章里可以再展开讲讲怎么定下线流程。

薛志远：对字段级权限那段有共鸣。我们之前想做按部门控权，评估下来发现网关层根本拿不到数据范围信息，最后还是回到数据服务层去实现的，网关只做身份透传和调用记录。

方雅琴：三层推进节奏这个说法挺实在的，尤其是”别一上来就追求全量纳管”。我们去年就是强行要求所有接口上网关，结果业务部门各种绕过，最后覆盖率好看，实际在管的没几条。

郝宏伟：信创环境压测那段提醒得及时，我们正准备做迁移评估，确实不能拿现有环境的压测数据去报，国密改造的性能影响得单独测一遍。