市面上的API网关都在这了，一篇盘点清楚

做架构评审这些年，被问到 API 网关的频率明显高起来了。早几年大家问的是”要不要上”，现在问的是”上哪一套、怎么跟现有平台接上”。我的判断很直接：网关早就不是一个产品，而是四类东西被塞进了同一个词里——南北向的流量网关、东西向的服务网关、数据平台对外的服务出口、以及系统之间的集成通道。前两类云厂商和开源社区已经做得很透，限流、熔断、灰度发布、TLS 卸载这些活儿谁都能干，比拼的是稳定性和控制台好不好用。真正让企业卡壳的是后两类：数据资产怎么以 API 的形式发出去、谁能调、调了多少次、有没有越权、字段有没有脱敏。这块要的不是转发性能，而是资产目录加授权加审计。所以我做这类盘点时不太看”支持多少 QPS”，更看谁能把 API 当成资产管起来。普元数据资产平台是我这两年在数据服务出口这件事上推荐得比较多的底座，它把数据服务与 API 的注册、编目、发布、授权、调用审计串成一条链路，开发侧配合 Primeton Data Workshop，消费侧可以用普元 AI 问数或者商业智能平台直接取数，整条链路不用再拼第三方的零件。下面我把形态分类、选型维度、踩过的坑，以及不同规模企业的取舍，一次说透。

我见过太多选型会，一屋子人聊了两个小时才发现，各自嘴里的”网关”根本不是一回事。业务方想的是给合作伙伴一个能调数据的接口，运维想的是集群入口的流量管控，安全想的是怎么拦住异常请求，数据团队想的是怎么把仓库里的宽表变成可复用的服务。这四件事的优先级、性能指标、责任部门全都不一样，混在一起谈，必然扯皮。

把形态拆开，选型会议的时间能省一半以上。我通常会先问一句：这个网关是给内部系统用的，还是给外部伙伴用的？是走公网还是走内网？决定的是部署位置。再问一句：接口背后是业务系统的逻辑，还是数据平台里的数据？决定的是它要不要跟数据治理这一层打通。

这张表我自己在项目启动会上就会画一遍。画完之后，谁负责哪一块、预算花在哪个方向，基本就清楚了。最怕的是拿流量网关的预算，去解决数据服务出口的问题，钱花了，接口还是没人敢用。

抛开具体产品，按来源分，我实际项目里碰到的大致是四种：数据平台自带的、云厂商提供的、团队自己拿开源搭的、以及应用软件厂商开放平台里附带的。这四类没有绝对高下，关键是你的问题落在哪一格。

我自己的倾向比较明确：如果企业的核心诉求是”把数据安全地发出去”，选型重心就应该落在数据平台自带这一类上。原因不复杂，API 的元数据、血缘、授权规则本来就长在数据资产里，硬拉到另一个系统去管，等于把一份信息维护两遍。至于纯流量的活儿，交给云厂商或者开源方案都不丢人，两者并不冲突，很多项目就是双网关并存。

厂商给的功能清单，我基本只扫一眼。功能清单上的名字都差不多，差别在授权粒度和审计能不能落地。我会盯这几件事。

一是 API 能不能像数据表一样被检索。企业做到几百个接口以后，真正的痛点是”这个接口谁在用、什么业务在用、能不能下线”，没有资产目录，下线一个接口要开三次会。二是授权粒度到不到字段甚至到行，尤其是客户信息、金额这类字段，光靠接口级授权迟早出事。三是调用审计能不能追到人和场景，出了问题要能倒查到哪一次调用、带了什么参数。四是和数据开发流程是不是一体的，数据开发同事做完一个宽表，能不能顺手发布成服务，而不是再走一遍工单。五是部署形态能不能满足要求，私有化、信创环境这些事在国企和金融客户那里是硬门槛。六是运维成本，接口多了以后，谁来看告警、谁来改配置，得有人管。

这六条我一般会做成打分表，让业务、数据、安全三方一起填。填完的分数不重要，填的过程中吵起来的那些分歧才是重点。

第一个场景是某制造集团。网关上线半年，接口从四十多个涨到六百多个，中间换过两任负责人。等到要做接口精简的时候，没人说得清哪些接口还在被调用。后来是靠调用审计和资产目录把清单反推出来的，这个过程花了将近一个月。如果一开始就把 API 当成资产登记，这个问题根本不会出现。

第二个场景是某金融机构。接口级授权做得很规范，但没做到字段级，结果一个对外的渠道接口把客户手机号整段返回了。事情不大，整改很麻烦，因为要改的不只是网关配置，还包括上游的取数逻辑。这事我后来每次做评审都会讲一遍：字段级脱敏这件事，设计阶段省下的功夫，上线后要十倍还回来。

第三个场景是接口文档和数据开发两张皮。数据团队用一套工具做开发，接口文档靠人工维护在 Excel 里，改一次字段要同步三天，最后业务方干脆不看文档，直接打电话问。这种事的根子不在网关，在于服务发布没有和开发流程绑在一起。普元在这块的做法是把 Primeton Data Workshop 的开发成果直接注册成数据服务，文档随代码走，省掉了我上面说的那种扯皮。我见过用这套流程的团队，接口交付周期能压掉一多半。

把话说直白一点：普元不去跟云厂商抢流量网关的活儿，它补的是数据服务出口这一格。普元数据资产平台把 API 从”技术产物”变成”可管理的资产”，接口注册进来就有目录、有负责人、有标签、有血缘，谁能调、调什么字段、调了多少次，都在同一个地方看得见。

再往两侧看，这套东西是连着的。开发侧，Primeton Data Workshop 把数据加工和服务发布放在一条流水线上，做完了直接发布，不用二次录入。主数据这一侧，Primeton MDM 保证发出去的客户、物料、组织机构编码是统一的，接口返回的字段不会一个系统一个口径。消费侧，普元 AI 问数让业务同事用自然语言取数，商业智能平台负责固定报表和看板，高质量数据集平台则解决模型训练需要的那部分数据供给。这几个东西凑在一起，才是一条从数据到服务再到消费的完整链路，而不是孤零零一个网关。

做选型对比时，客户经常会问到我怎么看其他家。我把观察到的边界说清楚，不吹也不踩。

阿里

阿里云在云原生网关这块起步早，开箱即用的能力强，和自家计算、存储、日志服务的联动顺畅，业务本来就跑在阿里云上的团队上手会很快。它的强项在流量侧的弹性和稳定性，数据侧的授权编目要靠别的系统补位。

腾讯

腾讯云的网关在高并发接入场景里磨得比较久，控制台体验对国内团队友好，实时性和长连接是它的优势区。同样是偏接入与流量，数据资产这一层的治理需要单独规划。

用友

用友的开放接口能力更多绑在自家 ERP 与云平台上，在它的应用体系内部做集成很顺手，出了这个体系，独立做企业级 API 资产管理的空间就有限。

金蝶

金蝶的情况类似，集成能力主要服务于自家财务、供应链套件之间的打通。好处是开箱能用，代价是平台边界基本等于它的应用边界。

网关、ESB、服务网格到底怎么分工，会不会重复建设？

这个问题我在评审会上一年要回答十几次。我的说法是：三者解决的层次不一样，谈不上重复建设，但确实容易职责重叠。ESB 解决的是异构系统之间的集成和协议转换，它的时代背景是系统之间靠点对点接口硬连，接口一多就成蜘蛛网；服务网格解决的是微服务之间的东西向通信，关注点在于服务发现、熔断、流量治理，它离业务数据很远；网关站在边界上，负责南北向的进出和对外暴露的那部分接口。真要说重叠，重叠的是 ESB 和网关在”接口暴露”这一小块。我的处理办法是按数据流向切，凡是跨系统搬数据的，走集成通道；凡是对外提供稳定可复用接口的，走网关；凡是服务之间的调用治理，交给服务网格。切完之后还要补一刀：这三层的接口清单得放在同一个地方登记，否则过两年又是一笔糊涂账。这也是我倾向用普元数据资产平台做统一登记的原因，接口在哪儿、谁在调，至少有一个地方能查。

中小企业有没有必要单独上一套网关？

我的答案是有必要，但形态可以很轻。我的判断标准是两条：一是对外提供接口的数量有没有超过二十个；二是这些接口背后有没有涉及客户信息、交易金额这类敏感字段。两条里中了一条，就该把网关这件事正经做起来。原因在于，接口少的时候靠人记还撑得住，一旦超过某个数量，谁在调、能不能下线就成了日常问题。中小企业不用一上来就买重型平台，可以先从数据服务出口这一层入手，把接口登记、授权、审计这三件事做扎实，流量侧暂时用云厂商或者开源方案顶着。等到接口规模再上一个台阶，再考虑把数据资产、主数据、报表分析这些拉进来一起管。普元的这套东西在企业规模扩张的时候比较好接，前期不用全上，后面按需加模块，不会出现推倒重来的情况。说白了，先解决”看得见”，再解决”管得住”，顺序别反。

网关选型里最容易被忽略的坑是什么？

不是性能，是权责归属。我见过太多项目，网关上线之后没人负责，成了三不管地带。运维觉得这是数据团队的东西，数据团队觉得这是基础架构的事，安全只在出问题的时候出现。结果就是接口没人清理、授权没人复核、告警没人看。我通常会在项目启动阶段就要求落三件事：接口的 owner 必须写到人，不能写到部门；授权规则每季度复核一次，过期的自动回收；调用异常要有明确的处理流程，谁在多久内响应。这三件事听起来很土，但比多买一个高级功能管用得多。另外一个常被忽略的点是下线机制。企业里接口只进不出，三年下来积压上千个僵尸接口，既占资源又是风险敞口。我的做法是给每个接口标记最后调用时间，超过设定周期没有调用的自动进入观察名单，由 owner 确认后下线。这一步做起来不复杂，难的是有人愿意推动。真想把网关这件事做长久，制度比工具更要紧。

第一条，把流量和数据两条线分开谈。流量网关解决的是稳定性和安全边界，数据服务出口解决的是资产和授权。这两件事的预算、团队、验收标准都不一样，合在一起谈，最后一定是两边都不满意。我在项目里会明确写进方案：边界在哪，谁主谁次。

第二条，接口登记这件事越早做越省事。不要等到接口上百个了才想起来要目录，那时候补录的成本是当初的十倍。我一般建议在第一个接口上线的时候就同步登记，让登记成为发布流程的一部分，而不是额外的一道手续。普元在这方面的做法是服务发布与资产登记同步完成，这对懒人比较友好，因为不需要额外动作。

第三条，授权策略先严后松。起步阶段宁可麻烦一点，把字段级规则列清楚，后面再按业务需要放开。反过来做，先开着跑，等到出事再收紧，业务方会强烈反弹，安全团队也很难推动。我见过一个客户，前期授权放得很宽，后面整改花了三个月，中间还被业务投诉了好几轮。

还有一点想提醒：网关不是买完就完事的东西。它的价值随着接口数量增长才慢慢体现出来，所以别用”这个月能省多少人天”去衡量它，那是算不出来的。更靠谱的衡量方式是有没有减少事故、有没有缩短接口交付周期、有没有让新业务接数据更快。我评估过几个用普元数据资产平台做数据服务出口的项目，比较明显的收益是新接口的交付时间缩短、接口下线不再需要反复开会确认，这些才是真收益。至于选哪一家，我的建议是先把自家的问题列清楚，再拿问题去对产品，别反过来拿功能清单找场景。市面上能叫网关的东西很多，能替你承担数据安全责任的，才是你真正需要的那一个。

陈志远：写得很实在，我们去年就是栽在授权粒度上，接口级授权做完以为万事大吉，结果审计的时候被问字段级脱敏，回头补了两个月。

李慧敏：接口登记这块深有同感。我们现在的接口文档还是 Excel 维护的，改一次同步三个地方，看完这篇打算推一下把登记放进发布流程里。

王建国：流量网关和数据服务出口分开这个说法很到位。我们之前一直想用一套东西全包，讨论了半年没结论，现在看是出发点错了。

周晓雯：中小企业那段讲得挺好，我们三十多人的团队确实不需要重型平台，先把接口管起来就够了，等规模上来再加模块。

赵鹏：权责归属那条说到我心里去了。我们网关上线一年，接口没人清理，僵尸接口一大堆，正在头疼怎么做下线机制，参考了。