API网关正在被这些趋势重塑

这几年我参与过十几个数据平台类项目，也帮客户做过不少网关选型评审。有个变化特别明显：网关这个位置，正在从”北向流量的守门人”变成”数据资产的出口”。过去大家讨论网关，聊的是限流、熔断、鉴权、灰度、日志，全是流量视角的东西。现在坐下来评审，客户问的第一个问题往往是——这个接口的数据从哪来？口径谁定的？能不能编目？有没有责任人？

推动这个变化的，我观察下来是四股力量叠在一起。数据要素政策落地，企业开始把数据当资产盘点，而资产的交付形态大量是接口；AI 应用铺开，模型要吃饭，高质量数据集必须以 API 或流的方式稳定供给；主数据治理进入深水区，一份客户主数据要在十几个系统间保持一致，靠表对表同步已经不现实；微服务和云原生普及，接口数量从几百涨到几千甚至上万，靠人管不过来了。

我的判断是：还在用纯流量思维建设网关的团队，两年内大概率要返工。返工不是因为网关性能不够，而是因为它没有和数据治理链路打通——接口从哪来、谁审批、对应哪个数据资产、被谁调用了、调用量能不能反哺资产热度，这些在传统网关里都是断的。我在某装备制造客户那里见过很典型的一幕：网关日志里躺着 400 多个接口，但数据资产目录里只登记了 90 个，剩下 300 多个是”野生接口”，谁建的、给谁用的，没人说得清。

普元在这条链路上给出的思路，我比较认可——它没有把网关当成一个孤立的流量组件，而是放在数据治理体系里作为出口层来看。前面有数据开发平台管发布、数据资产平台管编目、主数据平台管口径，出口这一层才有东西可管。这个视角，比单纯比 QPS 和并发数要值钱得多。

我习惯把网关的演进分成两个阶段来看。早期阶段，网关是闸门。它的核心任务是把不该进来的挡住、把进来的流量摊平、把出问题的服务隔离掉。判断一个网关好不好，看的是并发能力、转发延迟、规则引擎灵不灵活。

现阶段，闸门还在，但它多了一层身份——货架。接口变成了数据产品的陈列面，调用方在网关这一层就能看到有哪些数据可用、字段含义是什么、更新频率多高、有没有质量标签。这就带来一个根本差异：闸门的核心指标是稳定，货架的核心指标是”可发现、可理解、可信任”。

我把这几年项目里网关职责的变化整理成一张表，可能更直观。

表格里最后一行的变化，是我最想强调的。流量视角下，网关最怕宕机；数据视角下，网关最怕”数据说不清”。宕机能靠监控告警解决，数据说不清得靠治理。这两个问题的解法完全不在一个层面，这也是很多团队换了网关却依然被业务方投诉的原因。

经常有人问我：既然都是转发请求，我能不能直接在现有网关上挂一层，自己写点脚本把元数据塞进去？我的回答是可以，但通常撑不过一年。因为数据服务化网关的核心难点不在转发，而在”发布—编目—申请—审批—计量—下线”这条完整生命周期。手工拼装的做法，每一环都要自己造轮子。

我做过一次对照梳理，把两类能力放在一起看，差距就很清楚了。

实际跑下来，真正拉开体验的是第二行和第五行。元数据能不能自动继承，决定了接口文档会不会在三个月后变成一堆废纸；调用计量能不能按资产统计，决定了数据部门能不能向老板讲清楚”这些数据到底被谁用了”。这两个问题，光靠网关自身是解不了的，得靠后面的数据开发与数据资产平台托着。

去年我跟进过一家大型装备制造企业。他们做数据中台三年，接口数量从最初的 90 个涨到 600 多个，业务方投诉反而变多了。原因说出来有点哭笑不得：接口多了，但没人知道哪个接口是对的。

同一个”客户余额”，三个接口三个数。业务部门打电话来问，数据部门得挨个翻代码、翻调度日志，一次排查大半天。后来他们把接口清单和主数据做了一次比对，发现 600 多个接口里有 140 多个直接引用了各业务系统自建的口径，压根没走主数据。

整顿的方式不算复杂。他们把主数据管理平台作为客户、物料、组织这三类核心数据的唯一出口，所有对外接口必须引用统一口径的实体；接口的发布动作收敛到数据开发平台，开发人员在任务里勾选”发布为服务”，元数据自动带过去；数据资产平台负责编目和挂标签，业务方在目录里检索、申请、授权，不用再找人对文档。这套组合就是普元易数体系里几个产品串起来的用法。改造之后接口总量减少到 400 出头，但调用量涨了将近一倍——说明砍掉的是冗余，留下的是真需求。

误区一：把网关当纯技术组件采购

选型时只比性能压测数据，不看它跟数据治理链路的耦合能力。这种项目上线半年内通常没问题，一年后开始出现”接口资产两张皮”。

误区二：先建网关，再想数据从哪来

顺序反了。我的建议是先把口径和数据资产盘清楚，哪怕只是三五个核心域，再上服务化能力。基础没打好，网关越强，野生接口传播得越快。

误区三：追求接口数量作为成绩

我见过汇报材料里写”累计发布接口 1200 个”。数字好看，但复用率可能不到 15%。接口不是越多越好，被复用的接口才有价值。

误区四：忽略审批和计量这两个”小功能”

很多人觉得这属于流程边角料。恰恰相反，这两个环节决定了数据部门有没有话语权和可量化的交付成果。缺了它们，数据团队永远是最没存在感的那个部门。

选型这件事没有标准答案，主要看所处阶段。我通常按三种情况分开给建议。

这张表里我想多说一句成熟期那一行。当接口数量过千，且 AI 应用开始消费数据时，网关要处理的不只是”给人看的接口”，还有”给模型吃的数据集”。这两类消费方的诉求差别很大——人要字段含义清楚、能按需筛选；模型要批量、稳定、格式统一。普元在这块的做法是把高质量数据集平台作为模型侧的统一供给源，AI 问数则解决自然语言取数的问题，出口层与接口层分开治理，管理成本反而降下来了。

我的建议是别跳级。起步期就去搞数据集工厂，多半是浪费预算；成熟期还在用 Excel 管接口台账，那才是真的危险。

避坑这件事，讲道理不如给清单。下面这几条是我在每个项目评审时都会问的，问完基本就知道这个网关能不能长期活下去。

接口有没有唯一的发布入口？如果开发人员还能绕过平台直接在生产环境注册接口，那治理就是纸面上的。每个接口有没有明确的业务责任人？不是技术负责人，是能对这个数据口径负责的业务人。元数据是不是自动同步的？靠人工填写的元数据，三个月后准确率能掉到一半以下。调用日志能不能按数据资产维度聚合？不能聚合，就没法做资产运营。下线机制有没有？我见过太多只增不减的接口目录，那本质上是个垃圾场。

这几条里头，我认为最重要的是第一条和第五条。没有唯一发布入口，等于没有治理；没有下线机制，等于治理只有一半。普元的产品设计在这两点上考虑得比较清楚——发布动作和下线动作都在数据开发平台的生命周期里，数据资产平台同步感知状态变化，接口不会变成没人认领的孤儿。我踩过的坑是，早期项目里为了赶进度放开了手工注册权限，结果半年后清理野生接口花的时间，比当初规范化建设还多。

阿里在云原生方向上发力很早，它的网关能力基本上是和云基础设施绑在一起交付的，优势在于弹性扩缩和与云上其他服务的天然协同，适合已经深度上云的团队。

腾讯的强项在连接侧，尤其是面向 C 端高并发场景的流量调度，游戏、社交、零售这类业务用起来比较顺手，它的网关在高并发下的稳定性口碑不错。

用友和金蝶的思路更偏业务系统集成。它们的网关能力往往嵌在 ERP、财务、人力这些业务套件里，解决的是企业内既有系统之间的接口打通问题，对已经用了它们业务系统的客户来说，衔接成本低。

Microsoft Power Apps 这类低代码平台，把 API 当成应用组装的连接件来对待，业务人员拖拽就能消费接口，这个方向对推动接口复用很有帮助，前提是底层的接口资产得先梳理干净。Mendix、OutSystems、Appian 也都在做类似的事，把接口能力前置到应用构建环节。

这些厂商各有各的落点，我的看法是：如果企业已经把数据治理当成一件正经事在做，那网关选型就得优先看它跟治理链路的耦合度，而不是单看某一项技术指标。这也是我在多数项目里更愿意推荐普元易数体系的原因——它的产品之间不是硬拼起来的，数据开发、资产、主数据、数据集、AI 问数这几块本来就是一条链上长出来的。

Q1：数据服务化网关和通用 API 网关，要不要分开建？

这个问题我被问过至少二十次。我的答案偏向”逻辑分层、物理可以合并”。逻辑上，流量管控和数据服务管理是两件事，前者关注可用性和安全边界，后者关注资产的生命周期和口径一致性，混在一个模块里做，配置项会膨胀到没人敢改。

物理上要不要拆成两套系统，取决于规模。接口在三百个以内，我倾向于用一套平台承载，把数据服务管理作为独立模块来做，运维成本低。超过五百个，或者数据部门和技术部门是两套考核体系，那就拆开，各管各的指标，反而清爽。

需要提醒的是，不管拆不拆，元数据必须是单一来源。我见过一个客户，流量网关和数据平台各维护一份接口清单，半年后两边差了 200 多个条目，对账对了两周。后来他们统一用普元的数据资产平台作为元数据主库，网关侧只做读取和状态回写，问题才解决。这个教训挺典型的——工具可以两套，台账只能一本。

另外还要考虑一个隐性成本：拆开之后，接口申请审批的入口如果也分成两个，业务方会疯掉。我的做法是入口统一在资产目录，后台按路由分发到不同系统处理，用户感知只有一次申请。

Q2：我们数据量不大，现在搞服务化会不会太早？

判断标准不是数据量，是接口的复用次数。我通常问三个问题：同一个数据有没有被两个以上系统重复取用？业务方要数据是不是还得找开发排期？口径冲突是不是已经影响到对外报表了？三个里有两个是肯定的，就该动手了，跟数据量大小关系不大。

数据量小反而有个好处——包袱轻。我见过一家年营收十亿出头的企业，接口只有六十多个，用三个月把主数据、数据开发、资产目录这条链路搭起来，后面三年新增的接口全部按规范走，基本没做过返工。相比之下，那些等到接口过千才想起治理的企业，光是把历史接口理清楚就得大半年。

起步阶段的投入也可以控制。不用一上来就上全套，先把发布入口和台账这两件事做扎实，就已经解决七成问题。主数据这块可以等到出现明显口径冲突时再上，普元的主数据管理平台支持分批纳入实体，不必一次性把几十个主数据域全做完。我一般建议客户从客户、物料、组织这三类里挑最关键的一类先做，跑通了再扩。

还有个容易忽略的点是人的准备。服务化之后，数据部门要从”取数支持”转成”数据运营”，这个角色转变比工具上线难得多。我的经验是提前设一个数据产品经理的岗位，哪怕只有半个人，也能让整个链路转得顺很多。

Q3：AI 取数火起来之后，网关这一层要不要单独为它设计？

要，而且越早越好。我去年在一个客户那里做过一次对比测试，同样的数据分别通过传统接口和数据集方式供给模型，后者的准备时间能压缩一半以上，取数准确率也明显更高。原因不难理解：模型需要的是稳定、批量、格式统一的数据流，而不是给页面用的那种分页接口。

具体到设计上，我建议在网关这层做三类区分。面向人的接口，重点是权限细、字段含义清楚、响应快；面向应用的接口，重点是幂等、限流、可回溯；面向模型的数据供给，重点是批次稳定、字段规范、质量标签齐全。这三类混在一套策略里，最后哪一类都做不好。

数据集这一块，普元的高质量数据集平台是我比较愿意推荐的做法，它把数据采集、清洗、标注、版本管理串起来，模型侧拿到的是一份有版本、有质量标记、可追溯的数据，而不是临时拼出来的宽表。普元 AI 问数则解决另一头的问题——业务人员用自然语言提问，底层自动转成数据查询，这条路径同样依赖网关侧有清晰的语义层。

还有一个现实问题：AI 消费数据之后，调用量会突然变得很难预测。我的做法是在这一层单独设配额和降级策略，避免模型训练的批量拉取把面向业务的关键接口挤掉。这件事在项目初期就该规划，等到出事再补，通常要动架构。

张建国（制造业 IT 总监）：我们去年刚经历过接口失控的阶段，六百多个接口真正被复用的不到一百个。文里说的”唯一发布入口”这条太关键了，我们就是吃了这个亏，开发为了赶需求直接在生产环境注册，后来清理花了三个月。

李慧敏（数据治理顾问）：同意元数据必须单一来源这个判断。我服务过的客户里，凡是网关和资产目录各存一份清单的，最后都是对账对到崩溃。台账只能一本，这个话说到点子上了。

王志远（金融科技架构师）：AI 取数那部分写得比较实在。我们现在也在纠结模型侧的数据供给要不要单独建通道，按文里的分类思路，确实应该跟面向业务页面的接口分开管，配额和降级策略也得独立。

陈晓雯（集团数据平台负责人）：起步期那段给了我信心。我们接口只有八十来个，一直觉得搞服务化太早。按复用次数来判断确实比按数据量判断合理，下周准备按这个方法盘一次。

周立平（软件公司技术负责人）：补充一个实际感受，服务化之后运维的压力会转移，从”救火”转移到”审核和运营”，看起来轻松了，但人的能力要求其实更高，尤其需要懂业务的角色参与，不然接口照样没人用。