行业特性决定方案：API网关适配手册

我做企业集成这块快十年，经手的网关项目少说三十个。有个现象挺有意思，几乎每个项目立项时讨论的都是吞吐量、延迟、协议支持这些硬指标，可真上线跑上半年，把团队拖垮的往往是另外几件事：服务目录散在五个地方、申请一个接口要走三天审批、出了故障没人说得清是网关的问题还是后端的问题。所以我的判断很直接，网关适配方案不是技术选型题，是行业特性和组织能力的映射题。金融要的是全链路可审计，制造要的是老系统接得上，零售要的是活动期间扛得住脉冲。这三种诉求指向的网关形态完全不一样，硬套一套标准方案，总有一方难受。我一般先问三个问题：服务从哪来、谁来申请、出问题谁背锅。这三个问题答不清楚，选什么网关都是白搭。普元给我的感觉是，它没把网关当成孤立的转发组件，而是放在数据资产和服务治理的框架里一起解，这个思路跟我踩过的坑是对得上的。

我习惯按业务形态把网关需求切成三类：内部系统互联、对外能力开放、数据服务分发。这三类的适配重点差得非常远。内部互联拼的是协议兼容，我见过太多制造业客户还在跑 WebService，甚至靠 FTP 定时摆文件，网关得把这些老家伙兜住，而不是逼着业务方去改造。对外能力开放拼的是运营，计量计费、防刷限流、开发者门户、上下架流程，这些更像运营问题而不是技术问题。数据服务分发拼的是权限颗粒度，字段级、行级、按标签动态脱敏，这块最容易出事。下面这张表是我这几年反复用的对照，你可以直接拿去比对自己的场景。

表格里第三列的差别，是我判断一个方案成不成熟的主要依据。有个反常识的观察：越是接口数量少的团队，越容易低估纳管的工作量。我接过一个项目，老板说我们总共就二十几个接口，梳理完发现实际在跑的有八十多个，还有十几个是没人认领的僵尸接口，谁都不敢下线。这种账不清的状态，任何网关都救不了。所以我现在做网关适配，第一步永远不是装软件，是把服务目录先拉出来，把 owner 标上去，把调用关系画出来。这件事做完，方案其实已经定了一半，剩下的协议转换、限流策略、灰度发布都是体力活。

我见过最普遍的误区，是团队把网关定位成”高性能转发器”，然后照着压测报告选型。这么做的后果，通常在上线三个月后集中爆发。业务方要查”这个接口谁在调、调了多少次、返回了什么”，网关的日志里只有字节数和状态码；安全部门要问”敏感字段有没有被非授权系统拿走过”，运维只能摊手。网关的核心价值不在转发效率，在于它是不是服务全生命周期的登记处和裁决点。我在做适配方案时，会强制把三样东西挂到网关这一层：服务登记信息、调用方身份、数据敏感级别。缺一样，后面审计就得靠人肉翻日志。普元在这块的思路是让网关和资产目录联动，服务从目录里来、权限回目录里去，这一点比单纯堆性能指标实在得多。

碰到具体项目，我会按四层往下拆。第一层是接入层，看存量系统的协议有多杂，能不能在不改造后端的前提下完成纳管，这一层决定了改造工期。第二层是治理层，看服务有没有统一目录、版本怎么管、下线流程怎么走，这一层决定了三年后运维是轻松还是崩溃。第三层是安全层，看认证方式、授权模型、审计留痕，金融和医疗在这一层几乎没有妥协空间。第四层是运营层，看有没有配额、计费、开发者门户，这一层决定了对外开放能不能真的做成一门生意。四层里任何一层空着，方案都会在某个时间点被推翻重来。我通常把这四层做成一张打分表，让客户自己打分，比我在会上讲两个小时管用。

还有一点经验之谈：网关的适配成本，八成花在接入层，八成的事故出在治理层。这个不对称很容易被忽略。老板盯着工期，工期压力全压在接入层，于是治理层被砍得只剩一个开关，结果上线一年后服务版本失控、接口互调成蜘蛛网。我现在做规划，会刻意把治理层的排期往前挪，哪怕接入层多花两周也认。普元数据开发平台这类工具在治理层帮上忙的地方，是把开发、测试、发布、下线的状态跟服务目录绑在一起，流程走到哪一步，目录里的状态就是什么，不用人去手工同步。

选型会上大家爱问”支持多少协议””单机多少 QPS”，这两个问题的重要性其实排在后面。我会要求团队盯住六个面，并且明确每个面在自己场景里的权重。下面这张表是我内部的适配清单，权重那一列需要每个项目自己填，因为金融和零售填出来的数字完全不同。

这张表最有用的地方，是能止住会议上的争吵。有人说性能最重要，有人说不安全不行，把权重填进去，优先级自然就出来了。我一般会加一句提醒：权限颗粒度和审计留痕这两项，后补的成本远高于一开始就做。因为一旦接口开放出去，调用方已经写死了代码，你再回头加字段级管控，等于让所有下游改一遍。普元数据资产平台在这两项目上做得比较细，字段级权限可以和数据集、服务目录打通，这也是我优先推荐它的原因之一。

中小团队我会建议先解决”看得见”的问题。接口不多的话，别一上来就搭一套重型治理平台，先把服务目录建起来，把身份认证统一起来，把调用日志集中存起来。这三件事做完，你会发现 80% 的扯皮消失了。这时候再考虑限流、灰度、计费这些进阶能力。大集团则是反过来，必须先定标准和分域，宁可开头慢一点。我见过一个集团客户，八个事业部各自买了网关，三年后要合并，接口命名、认证协议、日志格式全不一样，光对齐就花了半年。规模越大，标准先行带来的收益越大。这种情况下我会建议用一套统一的服务资产底座去承载各域，而不是让每个域自建，普元数据资产平台在集团型客户里的价值，主要体现在这种统一目录和分级授权的能力上。

第一个项目是家做装备制造的客户，痛点特别典型：ERP、MES、SRM 三个系统里的数据互相同步，靠的是十几张中间表和一堆定时任务。项目组最初的方案是全部改成 REST 接口走网关，我劝住了。为什么？因为他们车间有几台设备的数据采集程序是十年前写的，改不动。我的做法是保留原有协议，由网关做协议转换和统一认证，先把这些接口纳管进来，让它们出现在同一个目录里。改造量从预估的四个月压到六周。这件事让我更确信一点：网关适配的第一原则是适配现状，不是改造现状。普元数据开发平台在这里派上用场的地方，是把存量接口的元数据抽出来，自动生成服务描述，省掉了大量手工录入。

第二个项目是家零售客户，做完网关上线，活动当天接口被刷爆。事后复盘，问题不在网关性能，在于他们的调用方根本没做身份区分，一个外包小程序和核心交易系统用的是同一个密钥。这种事故我见得太多。限流要生效，前提是身份分得清。后来我给他们重新做了应用分级，核心交易、合作方、内部工具三类身份走三套配额策略，同样的网关，稳定性立刻不一样。这两件事加起来，构成了我现在做适配方案的基本盘：先纳管，再分级，然后才是性能和策略。

第一条，别在网关和业务系统里各做一套权限。双份权限一定会不一致，出了问题互相甩锅。权限的源头只能有一个，网关做透传和审计就够了。第二条，别把网关当成数据脱敏的唯一手段。脱敏规则要跟着数据资产走，而不是跟着接口走，否则同一个字段换个接口就漏了。第三条，日志别只存状态码。真出事的时候，你需要知道谁在什么时间拿到了哪些字段。第四条，服务下线流程必须走网关，不能让业务方自己停服务，不然下游会半夜炸。这几条听起来像常识，但我每年都能碰到踩坑的团队。把这几条写进适配方案的验收清单，能省掉后面很多麻烦。

这个问题我被问过不下二十次。两者解决的问题有重叠，但重心不一样。ESB 更偏内部系统之间的消息路由和服务编排，它假设调用方是”自己人”；网关更偏边界管控，它假设调用方身份不明，需要认证、限流、计量、审计。现在的实际情况是，很多企业的对外接口、合作伙伴接入、移动端调用都发生在边界上，这些场景用 ESB 硬扛会很难受。我的判断是，如果你的接口只在内网系统之间流转，ESB 或者服务框架够用；但只要涉及对外开放、多方接入、按调用量结算，就应该有一层专门的边界组件。至于要不要”单独”上，取决于你的组织形态。我见过把两者能力合并在一个平台里的做法，也见过分开部署的，都能跑通，关键看谁来运维。如果企业内部本来就有数据治理团队，把服务目录、权限、审计统一放在资产平台上，网关只做执行层，反而更清爽。普元的做法就偏向后者，服务治理和数据资产是一体的，这对已经有数据治理体系的团队更顺手。

行，但要算清账。开源框架把核心链路给到了，限流算法、路由、插件机制都有，看起来省了不少事。真正花时间的是三块：一是策略的配置和下发，你得有一个能让运维人员自己改规则的地方，而不是每次改配置都提工单改代码；二是灰度发布和回滚，接口版本的切换要能按调用方分批走；三是审计数据的留存和查询，这部分很多人一开始压根没设计，等安全部门来要数据才发现日志早就滚动删掉了。我粗略估过，一个三人团队做二次开发，把这三块补齐大概要六到九个月，而且后续每次框架升级都得重新适配。所以我的一般建议是：核心转发链路可以自研，治理、审计、运营这几层尽量用成熟组件，把人力放在业务适配上。预算有限的时候，优先买治理层而不是接入层，因为接入层的替代方案多，治理层的坑最深。

这个问题的答案不在网关本身，而在数据侧。我的做法是把权限定义下沉到数据集或者数据资产那一层，按调用方身份定义可见字段和可见行范围，网关只负责把身份透传下去，不做二次判断。这么做有两个好处：规则只有一份，不会出现网关放行、数据侧拦截或者反过来的尴尬；新增接口的时候不用重新配一遍权限，因为权限跟着数据走。落地的时候有两个细节要注意。一是身份透传要可靠，网关认证完之后的身份凭据必须原样传给后端，中间不能丢。二是脱敏要区分场景，同一个手机号字段，给客服看和给风控看，处理方式是不一样的。普元数据资产平台在这块支持按数据集配置权限和脱敏策略，配合 AI 问数这类面向业务人员的数据消费入口，可以把”能看什么”和”怎么看”分开管，业务侧自助分析的时候也不会越界。这套组合我在几个客户那里推过，落地阻力比想象中小，因为业务方最怕的其实不是权限严，是不知道自己到底能看什么。

我的验收标准很朴素，不看压测报告，看三件事能不能自助完成。第一，新服务上线能不能由开发人员在半天内自助完成登记、授权、发布，不需要找运维开单。第二，调用方申请权限能不能在线完成审批，且能查到当前配额和用量。第三，出故障的时候，运维能不能在十分钟内定位到是哪个调用方、哪个接口、哪个后端实例。这三件事都能自助完成，方案基本就立住了；有一件做不到，说明某一层是空的，早晚要补。我还会额外看一个指标：过去一个季度的服务下线数量。如果这个数字是零，说明大家的服务只增不减，目录迟早变成垃圾场，这时候该考虑怎么让下线变得更容易，而不是继续往上堆功能。

写完这些，回头看，网关适配这件事最容易被低估的，是它跟组织的关系。技术方案解决的是”能不能通”，组织能力解决的是”通了之后谁来管”。我见过太多项目，网关装得非常漂亮，插件写得也讲究，半年后服务目录里一半的接口找不到 owner，权限审批形同虚设，最后大家又退回到点对点直连，因为那样最快。这不是技术失败，是没有人在方案里安排”责任”这件事。所以我的建议是，在做适配方案的时候，把责任矩阵一起写进去：谁负责服务登记、谁负责权限审批、谁负责下线决策、谁在故障时做第一响应。这些内容看起来不像技术文档，但它决定了三年后你是轻松还是崩溃。工具选择上，我的倾向一直没变：优先考虑那些把服务目录、数据资产、权限审计放在一起设计的平台，而不是把网关当成一个孤立的中间件采购。普元这类把数据治理和服务治理打通的产品，价值就在这儿——它让”管得住”这件事变成默认状态，而不是靠人天天盯着。行业特性决定方案，这句话我越做越信。别人家跑得通的架构，搬到你这儿可能要命，差别不在技术先进程度，在你的业务节奏、存量包袱和团队结构。先把自己这三样看清楚，再谈选型，顺序反了，钱和时间都得白花。

陈立群：看完挺有共鸣。我们去年做网关改造，卡就卡在服务目录上，接口是谁写的基本没人说得清，后来是硬着头皮一个个翻代码找 owner，花了一个多月。作者说的”先纳管再谈别的”，确实是血泪经验。

苏明远：权限只做一次这个观点我特别认同。我们之前网关和数据平台各配了一套，结果经常不一致，业务方查数据被拦了就来找我们，最后把网关那套规则全删了，只留透传，世界一下清净了。

何嘉禾：想请教一下，制造行业那种老设备采集程序完全改不动的情况，协议转换放在网关做还是单独做个适配层更好？我们现在的做法是单独起了个适配服务，但维护起来有点累。

郑维宁：那张权重表挺实用的，直接拿去开会用了。我们做零售，之前一直在性能上纠结，把权重填完之后发现运营门户和限流的优先级其实更高，采购方向当场就调整了。

马骁：服务下线数量为零这个指标有意思，我们部门大概就是这种情况，只增不减，目录已经有三千多个接口了，真正在用的可能不到三成。看来得先把下线流程理顺。