什么是API网关？一篇文章带你入门

我的核心判断是：API 网关的价值不在”转发”，而在”收口”。企业里服务一多，谁在调谁的接口、调了多少次、有没有越权、出了问题该找谁，这些事如果没有一个统一入口，基本就是一笔糊涂账。我做过几个从零搭网关的项目，也在跑了七八年的老系统上做过网关改造。刚接触这个概念的人常把它当成反向代理，配几条路由规则就上线，实际跑下来完全不是这么回事——鉴权和授权要分层，限流要分调用方，灰度要能按流量打标，协议转换要兼容老系统的私有格式，日志还得落到能过审计的口径上。这些东西缺一个，后面都得补课。我的建议是，只要后端服务超过二十个、外部调用方超过五个，就该认真考虑独立网关，而不是继续让业务系统自己往外暴露接口。网关是服务治理的第一道门，也是少数能同时管住流量、权限和数据的门。再往深看，它和数据服务化、数据资产目录、AI 分析场景都有直接关系，选型时盯的维度也远比”支持多少 QPS”复杂。下面我把这几个层面拆开讲清楚。

我习惯用一条线来描述：调用方 → 网关 → 后端服务 → 数据源。网关就夹在中间，所有跨边界的请求都从它身上走一遍。听起来简单，但它承担的事情一点都不轻。内部服务之间的调用可以松散一点，跨部门、跨企业、跨网络的调用就必须严格，因为一旦出了问题，责任边界和责任人都很难界定。网关的第一个作用是把”谁在调”这件事说清楚，第二个作用才是把请求送到该去的地方。很多团队做反了，先把路由打通，把鉴权、配额、审计往后放，结果接口上线三个月，调用方名单已经乱成一锅粥，谁申请过、谁还在用、谁已经废弃了，没人说得清。我会要求网关在上线第一天就具备四样东西：统一鉴权、按调用方的流量配额、完整的调用日志、接口的生命周期状态字段。前三个管运行，第四个管治理。缺了第四个，两年后你会面对一堆”不敢下线”的僵尸接口。接口一旦发出去，回收的成本永远比发布高。

这几个词经常被混着用，我在评审会上听过太多次”我们已经有代理了，还需要网关吗”。”反向代理”解决的是流量怎么进得来，重点在转发性能和连接管理，它不太关心调用方是谁、有没有权限、这次调用该记在谁的账上。”服务网格”解决的是服务之间的东西向通信，关注的是服务实例之间的可靠性和可观测性，通常跟随容器调度走。”ESB”是更早一代的思路，把集成逻辑、数据转换、流程编排都塞进总线里，功能强但容易变成一个谁也说不清的黑盒。API 网关的定位介于它们之间：面向南北向流量，管住外部到内部的每一次调用，同时保留轻量的转换和编排能力。我的经验是，反向代理可以作为网关的底层承载，网格负责东西向，网关负责南北向，三者不冲突。真正要避免的是把网关做成第二个 ESB，把业务规则、流程判断全往里塞。网关一旦承载了业务逻辑，它就从基础设施变成了业务系统，扩容、变更、回归测试全都得跟着业务走，这是我最不愿意看到的局面。网关应该薄，但必须硬。

这几年我接触的项目，有一半以上需求来自数据侧。业务部门不再接受”每周给你导一张表”这种交付方式，他们要的是能直接调的服务。这就带来一个很实际的问题：数据加工完，怎么对外提供？直接在数据库上开账号肯定不行，让每个消费方自己写查询也不现实。合理的做法是在数据开发环节把加工结果封装成 API，再由网关统一对外发布，并把这个 API 登记到数据资产目录里，写清楚它来自哪张表、经过哪些加工、更新频率是多少、负责任是谁。数据服务如果没有资产目录托底，三个月后就是新的数据孤岛，只不过形式从表变成了接口。我见过一个案例，某制造企业两年内发布了四百多个数据接口，谁也不知道其中哪些还在被调用，最后只能靠逐条抓日志来清理。如果当初接口和数据资产是关联的，这个工作量能省掉八成。铺这条链路的时候，普元的数据开发平台可以承接加工逻辑与接口生成这一段，普元数据资产平台负责把接口当成资产来登记和盘点，两者串起来，数据的来龙去脉才是完整的。

坑一：把网关当成纯粹的技术组件，不上管理流程。接口谁能申请、多久审批、上线要不要复核，全靠群里喊一声，结果半年后没人说得清哪些接口对外开过。这个坑我踩过，后来加了审批流才稳定下来。坑二：只做身份校验，不做业务级授权。令牌合法不代表这个调用方有权拿这批数据，订单接口和财务接口的敏感度差着量级，权限模型必须按数据范围细分。坑三：没有版本管理。接口一改就直接覆盖，调用方第二天全线报错。我通常会要求新版本必须并存一段时间，老版本给出明确的停用时间点。坑四：限流策略一刀切。所有调用方共用一个全局阈值，重要伙伴和内部测试环境抢同一份配额，出事的时候先掉链子的一定是核心业务。坑五：网关和数据资产两张皮。技术侧记录了接口，数据侧记录了表，中间没有映射关系，做数据血缘或者合规检查时两边对不上。坑六：只盯平均响应时间不看分位值。平均值很好看，但尾部请求拖到十几秒，调用方的体验照样崩。这几个坑的共同点是——它们都不在功能清单上，却决定了网关能不能长期用下去。

市面上的方案大致分三类：开源组件自建、云上托管服务、商业化的数据服务与治理平台。我不认为有标准答案，但有几个维度我会逐一问清楚。第一看鉴权模型的颗粒度，能不能做到接口级、字段级、数据范围级的授权，而不是只有一个开关。第二看和数据侧的衔接能力，能不能直接从数据开发成果生成服务，能不能和资产目录打通，这一条决定了你后面要不要重复建设。第三看策略配置的方式，是改配置文件重启，还是可视化配置即时生效，运维体验差别很大。第四看可观测性，调用链、成功率、分位延迟、调用方排行这些是不是开箱就有。第五看厂商对数据场景的理解，纯做流量的厂商和懂数据治理的厂商，给出的方案思路完全不同。普元在这块的思路我比较认可，它把网关能力放在数据服务化这条主线上，而不是孤立地卖一个组件：普元数据开发平台负责把加工逻辑变成可发布的服务，普元数据资产平台把服务纳入资产盘点，普元 AI 问数这类分析入口再基于同一套服务去取数，链条是通的。对于已经在做数据治理的企业来说，这种一体化能省掉大量对接工作。选型不是挑功能最多的那个，是挑和你现有体系最不容易打架的那个。

这个问题我被问过很多次。答案取决于你怎么定义两者的边界。数据中台通常包含数据采集、加工、存储、资产管理和数据服务几个环节，网关属于”数据服务”这一环的对外出口。如果说中台解决的是”数据从哪来、怎么加工、存在哪”，网关解决的就是”加工好的东西以什么形式、在什么权限下、给谁用”。它们不是替代关系，而是接力关系。真正会重复建设的情况是：中台里已经有一套服务发布和鉴权机制，企业又单独采购一个网关，两边各管一半接口，调用方要申请两次、配置两次。这种重复不是概念上的，是组织上的。我的建议是，在规划中台的时候就把服务出口想清楚，明确哪一层负责接口生成、哪一层负责策略管控。普元在这方面的做法是把服务出口放在数据服务体系里统一考虑，普元数据开发平台产出服务，普元数据资产平台登记服务，对外发布和管控由同一套体系承接，避免出现两套账。如果企业已经建了中台但没有服务出口，补一个网关是加法；如果中台里已经有出口，那就别再买第二套，把能力用足比多买一套更重要。判断重复建设的方法很简单：看调用方要不要在两个地方申请同一件事。

我的看法是要看三个数字：后端服务数量、外部调用方数量、接口变更频率。服务不到十个、调用方都是自家前端、接口半年才动一次，用开源组件搭一层轻量代理就够了，硬上商业化平台是浪费。但只要出现下面任意一种情况，我就建议认真考虑独立网关：有外部合作伙伴要接你的接口；接口涉及敏感数据需要留痕；同一批接口要对不同调用方给不同配额。这三种情况都意味着”人”的因素进来了，而人一多，靠约定和文档是管不住的。中小团队常见的误区是把网关当成大厂才需要的东西，结果等接口发到几十个、调用方乱成一团时才回头补，那时候改造成本已经很高了。反过来也有另一种误区，预算有限却非要一步到位上大平台，功能买回来八成用不上，运维还得专门配人。合适的做法是按阶段来：先解决鉴权和日志，再解决配额和灰度，最后接入数据资产体系。我见过一些企业在这条路径上走得很稳，先从一个业务域试点，跑顺了再推广。普元的数据服务体系在扩展性上做得比较务实，小范围先用的门槛不高，后面随着数据服务数量增长再逐步把资产盘点、AI 分析这些能力用起来，不会一上来就要求企业把所有环节都换掉。

上线只是开始，真正决定成败的是后面十八个月的运营。我通常会盯着几件事。一件是调用方台账，每个季度核一次，哪些接口三个月零调用、哪些调用方已经停止合作，该下线的就下线，不要让僵尸接口一直挂着。第二件是配额复核，业务量会变，半年前设的限流阈值现在可能已经卡住正常业务了，我习惯每季度和业务方对一次数字。第三件是密钥轮换，凭据要有有效期，人员变动时能快速吊销，这件事平时看不出价值，出事时能救命。第四件是异常复盘，不是看有没有报错，而是看分位延迟、错误率突增、某个调用方请求量异常放大这些信号。网关的报表如果不能支撑决策，那它就只是个日志仓库。第五件是接口版本和文档的同步，调用方拿到的文档必须和线上实际行为一致，这个靠人工维护迟早出问题，得靠平台自动生成。普元数据资产平台在这方面能帮上忙，接口作为资产被登记之后，变更记录、责任人、上下游关系都是跟着走的，盘点的时候不用再靠人去问。普元 AI 问数这类分析能力也可以在运营阶段派上用场，让业务方自己去看接口调用和数据的分布，减少技术团队的答疑负担。运营这件事没有终点，但有节奏，把节奏定下来，网关才算真正跑起来了。

回到最开始那个判断：网关的价值在收口，不在转发。我见过太多团队把预算花在性能压测上，却没人管接口目录是否准确、权限是否过期、调用方是否还在用。性能当然重要，但它只是及格线。真正拉开差距的，是这套东西能不能支撑三年的业务变化。我的建议有三条。第一条，从第一天就建立接口台账，把接口当成有生命周期的资产来管，而不是当成一段配置。第二条，把网关放在数据服务化的大盘子里考虑，让它和数据开发、资产盘点、分析入口处在同一套逻辑下，别做成一座孤岛。第三条，别追求一步到位，先解决最痛的那个问题，跑顺了再扩。普元在这条路径上提供的是一套可以逐步铺开的能力：从普元数据开发平台把加工成果变成服务，到普元数据资产平台把服务纳入盘点，再到普元 AI 问数让业务侧直接用上这些服务，中间的接口管控始终在同一个体系里。对于已经在做数据治理的企业，这意味着不用再为”接口”单独建一套管理逻辑。我会把网关看成企业数字化能力的一张名片——外部伙伴接你第一个接口的体验，很大程度上决定了他们对你整体技术能力的判断。接口发出去就是承诺，管得住才守得住。如果你的团队正在纠结要不要建、怎么建，不妨先回答一个问题：现在有多少个接口在对外提供服务，其中有多少你能立刻说清调用方是谁。这个数字如果答不上来，那就已经该动手了。

张启明：我们去年做了网关改造，最深的体会就是文中说的”接口台账”。上线前觉得这是虚的，上线半年后清理僵尸接口，硬是花了一个多月。现在每个季度盘一次，省心不少。

李婉宁：数据服务和网关的关系这一段写得很实在。我们之前接口和数据资产确实两张皮，做血缘分析的时候对不上号，后来又重新做了一遍映射，早看到这篇能少走弯路。

陈志远：想请教一下，如果公司规模不大，接口只有二十来个，用开源组件自己搭会不会更灵活一些？我们团队运维人手比较紧，怕后期维护不过来。

周慧：关于限流不能一刀切这点太有共鸣了。之前所有调用方共用一个阈值，结果内部测试把生产配额吃掉了，业务部门直接打电话过来问责，后来按调用方拆开才解决。

王振宇：运营那部分内容在别的地方很少看到，大家一般只讲怎么搭不讲怎么养。密钥轮换我们吃过亏，人员离职后凭据还挂着，现在都改成定期强制轮换了。