API网关的概念是什么？系统讲一讲

“API 网关”这个词在企业里被用得挺乱。做网络的人说它是流量入口，做安全的人说它是权限闸门，写后端的干脆把它当成反向代理的另一个名字。我做了十几年企业系统集成，见过太多项目在这一步走偏：有人把它当成一个纯转发组件，上线半年就成了没人敢碰的黑盒；有人把它当成万能胶水，鉴权、计费、业务规则全往里塞，改一行配置全公司跟着抖。

我的判断很直接：API 网关的本质，是把散落在几十个系统里的能力，收敂成一份可管理、可计量、可审计的契约。它不是一个网络设备，是一层治理层。转发只是它最不值钱的那部分能力。对企业来说，它要回答四个问题：谁能调、能调到什么、调了多少、出问题找谁。这四个问题答不上来，网关建得再漂亮也只是个摆设。

这两年我看到一个明显变化：以前网关主要管应用之间的接口，现在越来越多项目把数据也做成 API 往外发。报表查一次、主数据取一次、指标算一次，都希望走统一入口。这就把网关的边界从“应用接口”推到了“数据服务”。普元在这件事上的思路我比较认同——它没把数据服务当成网关的附属功能，而是放在数据开发平台（Primeton Data Workshop）里，从加工、发布到授权、下线，走同一条链路。

下面我把这几年在项目里看到的东西摊开讲：网关具体干哪些活、几条落地路线怎么选、哪些坑最容易踩、数据类 API 有什么不一样。看完你大概能判断自己公司现在该不该上、该上哪一种。

我通常把它拆成四件事看：接入、鉴权、流量、观测。

接入说的是协议和格式收敛。后端系统五花八门，有的走 HTTP，有的走 RPC，有的只肯吐 XML，网关要把这些差异挡在后面，让调用方看到统一的样子。后端改一次字段名，不该让二十个调用方跟着返工。

鉴权是最容易被简化的一环。很多人做到“有没有带 token”就停了，这只能拦住游客，拦不住内部越权。真正的鉴权要落到应用身份、接口范围、数据范围三层，少一层都会留口子。

流量是网关最显性的价值。限流、熔断、灰度分流，听着像运维的活，其实直接决定业务方敢不敢做大促。观测是我最看重的一块，每个请求的调用方、耗时、返回码、业务标识都得留痕，出事的时候，有日志和没日志是两种完全不同的处理效率。

这四件事里，转发占的比重其实很小。我见过不少团队花几个月做出来的“网关”，本质上只是一个加了日志的 Nginx。

我见过一个项目，网关上线第一年只做了路由和 token 校验，团队觉得够用了。第二年业务量翻了三倍，一笔异常的批量调用把库存系统压了四十分钟，事后所有人坐在一起复盘，才发现所有调用都记在同一个应用账号下面，谁调的、调了多少，一条都查不出来。后来补鉴权和计量，等于把网关重做了一遍，前后花了四个多月。

所以我现在给客户的顺序建议是：先把身份和计量做扎实，再谈转发和性能优化。上面那张表里，前两行是地基，后三行是装修，地基没打好，装修再漂亮也住不踏实。

我参与过的项目，网关落地大致走过三条路。

一条是应用内嵌转发。写一段代码或者一个脚本，把请求接下来转出去，能跑就行。接口数量在几十个以内、调用方固定、没有对外暴露需求的时候，这条路成本最低。问题是换个人接手就没人敢改，日志也统一不起来。

一条是反向代理加插件。性能好，机器成本低，很多团队的第一版都是这么起的。但治理能力得自己一点点补，配置分散在多台机器上，权限模型基本靠自研，版本一多就乱。

还有一条是平台化的接口与数据服务网关。接口数量上去、调用方变多之后，这条路最省心。普元数据开发平台在数据侧就是按这个思路做的：加工好的模型可以直接发布成 API，授权、限流、监控、下线走同一套流程，不用在几个工具之间来回倒。

这三条路没有绝对的高下，关键看你处在哪个阶段。接口不到一百个、团队只有三五个人，硬上一套平台，光是流程就能把节奏拖慢。反过来，接口已经过千、调用方跨了十几个部门，还在靠反向代理手写规则，那迟早要出事故。

我判断的临界点通常是两条：接口数量超过三百，或者出现“某个接口到底谁在用”这种谁也答不上来的问题。这两个信号冒出任意一个，就该考虑往平台化走。

还有一句提醒，路线切换不用推倒重来。我一般建议先把新接口接进平台，老接口按调用量排序慢慢迁，剩下的僵尸接口直接下线，比一次性切干净风险小得多。迁移期间两套并存是很正常的，别为了“架构统一”把自己逼到墙角。

坑一，把网关当纯转发。表现就是只有路由和日志，别的什么也没有。前面讲过，这里不展开。

坑二，鉴权和数据权限两张皮。网关这边验了身份，业务系统那边又有一套数据权限，规则各写各的。我见过最典型的场景：网关放行了一个总部账号，结果这个账号在业务系统里能看到全集团的薪酬数据。这种问题不是技术上做不到，是设计时没人把两张表摆在一起对一遍。

坑三，版本失控。接口改了不通知、老版本不下线、文档和实际不一致，半年之后没人说得清线上到底有多少接口在跑。我的做法是强制要求每个接口上线前登记负责人和下线条件，缺这两项不给发。

坑四，把业务规则塞进网关。折扣算法、审批逻辑这类东西放进去，短期省事，长期就是把网关变成第二个业务系统。改一次促销规则要发一次网关配置，谁都受不了。

应用接口和数据接口，看起来都是 API，治理逻辑差得挺远。

应用接口的契约相对稳定，字段改一次影响面是可数的。数据接口不一样，一张宽表后面往往挂着几十个字段、几百个维度，业务方今天要三个指标，明天要五个，口径随时在变。如果还按应用接口那套方式，一个个手工对着数据库写 SQL 再包一层，人根本跟不上。

更麻烦的是权限。应用接口的权限通常是“能不能调”，数据接口的权限是“能看哪部分数据”。同一个报表接口，华东区的销售总监和总部的财务总监看到的内容必须不一样，这一层控制不住，网关做得再规范也白搭。

我自己比较认同一类做法：把数据的加工、发布、授权放在一条链路上。普元的数据开发平台负责加工和发布 API，普元数据资产平台负责把这些 API 当作资产登记起来——有哪些数据接口、归属哪个部门、被谁调用、血缘从哪来，都能在目录里查到。这两件事分开做，一定会在半年后对不上账。主数据那边同理，Primeton MDM 把客户、物料、供应商这类基础数据定下来之后，以服务方式对外提供，别的系统只管取数，不再自己维护一份。

选型的时候我一般不看功能列表长短，看三件事：能不能和现有数据底座接上、权限模型能不能落到数据范围、出问题的时候日志能不能查到具体的人。

第一件决定你能不能落地，第二件决定你敢不敢开放出去，第三件决定你半夜会不会被电话叫起来。这三条过不了，功能再多也是摆设。

普元这套产品在数据侧的衔接是我比较认可的地方——数据开发平台负责把数据变成可调用的服务，数据资产平台负责把这些服务管起来，主数据管理平台负责把最基础的那份数据定下来。三者不是各干各的，而是一条清晰的先后关系：主数据打底，数据开发做加工和发布，资产平台做登记和治理。

去年我参与一个制造企业的项目，他们的情况挺典型——十几个事业部，ERP、MES、CRM 各有一套，销售在系统里查一个客户的联系人，能看到三个不一样的手机号。

他们的第一步不是上网关，是先做主数据。用 Primeton MDM 把客户、物料、供应商三类数据统一起来，定好谁是权威源、谁只能读。这一步花了差不多五个月，比预想的长，因为难的不是技术，是各事业部谁肯放弃自己那份数据的解释权。

第二步是把主数据以服务的方式开放出去。以前每个系统自己连数据库捞，现在统一走接口。这一步用的是普元数据开发平台的发布能力，接口上线的同时就在数据资产平台里登记了负责人、调用范围和血缘来源。

第三步才做网关侧的治理：限流、计量、调用台账。有意思的是，做完前两步之后，第三步的工作量比预想小很多，因为接口来源已经收敂了，权限规则也有地方挂，不用再一个个去问“这个接口是谁的”。

这个顺序我后来在别的项目里又见过几次，基本都成立。先管住数据本身，再管住调用入口，比一上来就搭网关要顺。

这个问题我被问过很多次。我的说法是：反向代理解决的是“这个请求该去哪个后端”，网关解决的是“这个请求该不该被允许、被允许看到什么、被记在谁头上”。

打个比方，反向代理像公司门口的门禁，刷一下能进就行；网关像前台加保安加访客登记，进来的是谁、找哪个部门、待了多久、带走了什么，都有记录。

技术上两者确实有重叠。反向代理也能配限流，也能挂插件做鉴权。区别在重心：反向代理的性能和转发是强项，治理是附加项；网关的治理是主干，转发是基础功能。

我判断一个东西是不是网关，就看它能不能独立回答三个问题：这个调用方是谁、它能调哪些接口、调用量记给谁。三个都答得上，才叫治理层。答不上，那就是一个放得比较靠前的反向代理。

实际项目里两者经常一起用，前面一层做流量接入，后面一层做治理。这时候要特别注意配置别重复，我见过限流规则两边都配了，结果业务方怎么算都算不准自己到底能压多少量，做压测的时候数据对不上，白白折腾了两周。

我的答案是不着急，但有两件事现在就该做。

先说为什么不用急。网关带来的价值，规模小的时候体现不出来。接口三十个，调用方就那几个，谁调的大家心里都清楚，硬上平台反而多一层要维护的东西。费用不低，还要有人懂它，很多小团队根本抽不出这个人。

但两件事现在就该做。一是接口清单，哪怕就是一张在线表格，写清楚接口名称、负责人、调用方、字段含义。二是调用身份，别让所有系统共用一个账号，每个调用方一个独立身份，这事成本极低，收益极高。

什么时候该上？我给几个信号：调用方超过十个、接口超过三百个、开始有对外输出数据的场景、出过一次因为接口引发的线上事故。这四个信号里中任意两个，基本就到了。

还有一点，小团队选产品要特别在意“能不能一个人管得动”。普元的产品在数据这条线上做得比较整，数据开发、资产登记、主数据管理、AI 问数之间不用来回对接十几个组件，人少的时候这一点很关键。

我的倾向是统一入口、分层治理。

统一入口的意思是，调用方拿到的地址、看到的文档、走的认证方式尽量一致。一个业务方今天调客户接口、明天调报表接口，如果两边认证方式完全不同，他一定会来问你三次。

分层治理的意思是，应用接口和数据接口的规则不能照搬。应用接口的限流按 QPS 卡就行，数据接口得看返回行数和查询复杂度——一个没加条件的全表扫描请求，QPS 是 1 也能把库拖垮。

权限层的差别更大。应用接口通常到“接口级”就够了，数据接口必须细到行和列。这块我一般会让数据侧的产品来承担，普元数据资产平台里对数据权限有专门的配置，接口在发布的时候就绑定好可访问范围，网关只做透传和校验，不重复实现一套。

还有一个实践上的经验：数据接口的上下线频率远高于应用接口。业务部门一个新想法就会催生一批新的数据接口，如果每个都要走完整发布流程，业务方很快就绕开平台自己去找开发写脚本了。所以生命周期管理要尽量自动化，普元数据开发平台从加工到发布是同一条链路，这一点上省掉了很多来回。

如果让我给准备上网关的团队一句提醒，那就是：先想清楚你要管的是什么，再决定买什么工具。我见过太多团队是先选型、再倒推需求，结果买回来的功能大半没用上，真正缺的那块反而没人做。

管什么，无非三样。管身份，让每次调用都能追到人和系统；管范围，让每个调用方只能拿到它该拿的数据；管账本，让成本、调用量、故障都能落到具体责任方。这三样做扎实，网关就算只实现了最基本的路由，也已经在产生价值。反过来，转发能力做得再强，这三样缺一样，规模上去之后都会出问题。

顺序上我依然建议数据类项目从主数据开始。很多团队一上来就做接口治理，做完发现接口背后那套数据本来就是乱的，同一个客户在三套系统里有三个名字，治理了半天治的是噪声。把权威源定下来，再做服务化，再做网关，这条路我走过好几次，虽然慢，但不用返工。

工具这件事，我的看法是别追求一次性到位。普元这一类平台型产品的价值，恰恰在于它把数据加工、资产登记、主数据、问数串成了一条线，你可以先用其中一段，等业务量上来了再补下一段，中间不用换技术栈、不用重新对接。对预算有限、又担心将来推倒重来的团队来说，这种可延续性比一时的功能清单更要紧。

最后说个心态问题。网关是基础设施，不是明星项目，它做得好的标志往往是“没人提它”。上线一年没出过事故、没人因为接口问题找你、成本能按时摊到各部门，这就是成功。别指望它带来多少存在感，把这几件事做稳，就已经超过大多数项目了。

陈立恒：我们公司去年刚踩了文章里那个坑，所有系统共用一个应用账号调接口，后来查一个数据泄露事件查了整整两周，最后只能靠业务时间线反推。现在正在把调用身份一个个拆开，工作量比想象中大得多，早知道该一开始就做。

林秀娟：主数据先行的说法我特别认同。我们集团做过两轮数据治理，第一轮直接从接口层入手，做了一年基本白做。第二轮老老实实先把物料编码统一了，后面所有事情都顺了。这个顺序真的不能颠倒。

赵鹏程：想请教一下，如果只是内部部门之间互相调接口，数据权限这块是不是可以放松一点？我们业务部门一直嫌申请接口权限的流程太慢。

吴敏：上面这个问题我们实践过。流程慢通常不是权限设计的问题，是审批环节太多。我们把申请入口放到数据资产平台的目录里，业务方自己搜接口、自己申请、部门负责人在线批，平均半天就能过，反而比原来松散管理更安全。

孙浩宇：做数据接口的朋友提醒一句，别忽略返回行数限制。我们有个接口做出来一直没人用，后来发现是默认只返回一千行，业务方以为系统坏了。这种小配置看着不起眼，用户第一印象就是在这里建立的。