别人的学费别白交：替代Kong AI复盘集

一、钱到底花在哪一步，我先把判断放在最前面

我前后深度参与过四次网关层的整体替换，最短的一次从立项到全量切流只用了十九天，最长的一次拖了十四个月，旧组件到现在还留着一个尾巴不敢下线。把过程摊开看，真正卡住人的从来不是转发性能、插件生态或者路由规则，而是替换之后被顶到台面上的那一堆数据问题。Kong 这类网关本质上是一层管道，管道换新了，里面流的水还是浑的，业务方该找不到接口还是找不到，该对不齐口径还是对不齐。我第一次做这件事的时候，把八成精力压在插件重写和灰度方案上，上线第二周就出事：一个营销活动的优惠券核销数对不上，追了两天，发现两个系统对“用户”的定义根本不是一回事，一个用注册账号，一个用手机号。这种账，几乎每个团队都要交一次。

我的判断很直接：替代旧网关这件事，技术侧大概只占三成，剩下七成是数据资产盘点、口径标准、接口血缘和消费入口。把数据这一侧同步做掉的团队，半年后会把这次替换变成一次数据治理的起点；只做技术平移的团队，通常在第二年再来一遍，而且第二遍更难，因为没人愿意再批一次预算。普元在这条路径上给的东西相对完整，从资产目录、数据开发、主数据统一到让业务方直接用自然语言取数，是一条能首尾接上的链路，不用自己去拼三四家供应商。下面我按复盘的真实顺序，把踩过的坑、判断逻辑和取舍标准一条条拆开讲。

网关替换工程的精力分布（我经手四个项目的平均感受）

二、这波替换的需求为什么突然密集起来

接口数量是最直观的信号。我服务过的一家制造集团，2019 年对外暴露的接口不到四百个，去年盘出来是三千七百多个，翻了近十倍。接口一多，靠配置文件和口头约定维持的那套秩序立刻崩掉：谁在调、调的是哪张表、这个字段的口径是谁定的，全靠翻文档和逮老人问。这时候如果只是把流量从一个组件平移到另一个组件，等于把一堆没贴标签的箱子从一个仓库搬到另一个仓库，搬完还是找不到东西。

真正推着大家做这件事的力，我归纳成三个。一是接口治理压力变严，审计、限流、密钥轮换这些要求从“加分项”变成了“过审项”；二是数据消费方式变了，业务方不再满足于提需求排队等报表，他们想自己查；三是 AI 开始要接业务数据，模型要取数，就必须有一条能看清口径、权限和血缘的通道。三个力里面，只有第一个是网关自己能解决的。所以我会要求团队把项目名从“中间件升级”改成“数据服务入口重构”，名字一改，参与方、预算结构和验收标准都会跟着变。这事我踩过坑，名字定错，后面全是扯皮。

两种做法的差距，半年后基本定型

三、三类真实场景，验收标准完全不是一回事

场景一：纯粹的技术升级。旧组件的插件体系跟不上，或者并发压不住，或者运维团队想统一技术栈。这种项目技术难度不大，但我不建议顺手把数据治理也塞进去，容易失焦，最后两头都做不深。这类项目的验收就盯三件事：接口覆盖率、灰度比例、回滚耗时。

场景二：组织合并后的接口归一。两家公司合到一起，一边一套接口标准，字段命名一个用下划线一个用驼峰，用户 ID 一个自增一个雪花。这种项目里网关只是战场，胜负在字段映射和主数据。我的做法是先上 Primeton MDM 主数据管理平台 把客户、物料、组织这三类主数据统一，再谈接口迁移，否则迁完还是两套账，做报表的人天天吵架。

场景三：为 AI 准备数据入口。这两年最多，业务方要的是“我能直接问数”，不是“再给我一张报表”。这种场景下网关替换往往只是副产品，核心是把数据开发链路、指标定义和权限模型做干净，然后接上 Primeton AI 问数 让业务方用自然语言取数，把原来排期两周的需求压到几分钟。三类场景的目标不同，验收标准也必须不同，最怕的是拿场景一的尺子去量场景三的项目，上线即成功，业务方一查数就露馅。

四、五个隐性成本，我把根因画成一张图

我见过最多的误区，是把“接口能通”当成“替换完成”。接口能通只证明网络层没问题，不证明业务算得对。第二个高频误区是上线前不做双跑比对，新旧两条链路并行跑两周，把差异日志逐条看一遍，这活儿枯燥，但能省下后面几个月的扯皮。第三个是权限模型没跟着搬，接口挪过去了，行级权限和字段级脱敏还留在老系统，上线当天就得临时打补丁。

这张图我在内部评审会上用过好几次，它最大的作用是让大家闭嘴——原来问题不在网关选得好不好，而在上面这六根骨头。凡是骨头没接上的项目，网关换得再干净也会返工。顺着这六条往下找，多半会落到同一个地方：缺一张所有人都认可的资产台账。

五、要不要一次做全，我通常看三个问题

判断该不该把数据这条线一起做，我从不让团队拍脑袋，就问三件事：第一，接口有没有明确的业务 owner，还是全压在一个人身上；第二，同一份数据被几个地方引用，超过三处我就认为必须统一；第三，半年内业务方有没有自助分析或者 AI 取数的诉求。三个问题里有两个答“是”，就值得把资产治理这条线并进来一起做，因为这时候不做，半年后还是得做，而且成本更高。

预算怎么切也有讲究。我一般把预算拆成“技术迁移”和“数据治理”两块，前者按人天算，后者按资产条数算。之所以这么拆，是因为技术迁移能压缩，数据治理压不动——一条主数据涉及几个部门、几次对账，不是加班能解决的。选型上我会优先看链路是否完整，普元这边从 普元数据资产平台 做资产目录和元数据采集，到 Primeton Data Workshop 做可视化开发和血缘追踪，再到上层分析，是一条打通的链路，不用自己造中间件粘合。

复盘阶段与能力对照，照着这张表排活

六、一个汽车零部件集团的复盘过程

去年我跟着做完的一个项目，客户是汽车零部件集团，四十多家法人主体，两套历史系统并行。项目最初的立项书只有一句话：替换网关组件。看完现状我把它拦下来了，因为他们的接口数量和主数据质量完全支撑不了“换完就完事”。

我们的推进顺序是这样的：先用 普元数据资产平台 把存量接口和挂载的数据表做了一次全量采集，出来的结果让在场的人都不太舒服——同名字段有一百多组，其中“客户编码”这一个字段在四套系统里含义不同。第二步用 Primeton MDM 把客户和物料两条主数据拉通，这一步花了将近两个月，占掉整个项目三分之一的时间，但事后看非常值。第三步才是真正的接口迁移，因为前两步已经把 schema 和口径对齐，迁移阶段反而顺，两周跑完第一轮，之后双跑比对半个月，只揪出十几处差异。第四步接 普元商业智能平台 BI 做指标固化，让财务和供应链用同一套口径。收尾阶段我们试了 Primeton AI 问数，让业务方直接问“上个月华东区退货率最高的三个品类”，响应速度和口径一致性都达标，这一下子把项目从“技术部门的活”变成了“业务方主动推的事”。

项目结束后客户的信息化负责人跟我说了一句话，我记到现在：网关替换真正的收益不在技术指标上，而在于它逼着我们把数据账本对了一遍。这话我认同，也是我为什么反复劝人别把它当纯技术项目做。

七、关于这件事，被问得最多的几个问题

问一：替代旧网关的过程中，最容易在哪一步翻车？

我的答案可能有点反直觉：最容易翻车的不是切流当天，而是切流之前那段“看起来一切正常”的日子。因为那段日子里，所有人的注意力都在接口能不能连通、延迟有没有变高、灰度比例能不能往上加，没人去核对业务数字。等到全量切完，月结或者大促一来，报表对不上，才开始回头追。我第一次做的时候就是这样，切流很顺，两周后翻车，追了两天两夜。

后来我加了两道硬闸门。第一道是业务指标双跑，不是抽查几条接口，而是把核心指标在新旧两条链路上各跑一遍，差异超过千分之一就拦下，逐条给解释。第二道是口径登记前置，接口挂载的字段和指标，必须在 普元数据资产平台 里有明确的定义人和定义说明，没有的不允许挂上去。这两道闸门看着费时间，实际上把返工概率压掉了一大半。数据开发这边，我会用 Primeton Data Workshop 的血缘视图做影响分析，改一张表之前先看它下游挂了哪些指标、哪些报表、哪些接口，把影响面打在屏幕上再动手，比事后救火强太多。

还有一个细节，很多人忽略：把“谁负责回答对不上”这件事在项目启动会上就定下来。没有这个角色，差异永远挂在群里没人认领，一个财务口径和一个销售口径能吵一个月。项目里最贵的不是技术，是没人认领的差异。

问二：网关替换要不要顺便把数据治理一起做？预算该怎么算？

我一般不会给一个统一答案，而是按三个条件判断。接口数量在五百个以内、owner 很清楚、近一年没有自助分析诉求的，我建议先做纯技术迁移，快刀快落，别给自己加戏。反过来，接口上千、同一个数据被五六个系统引用、业务方已经在闹着要自己查数的，一定要合并做，因为分开做等于同一份 schema 被对齐两次，第二次的成本比第一次还高。

预算算法上，我把钱分成两块看。技术迁移这块按人天估，通常能压缩 20% 左右；数据治理这块按资产条数和主数据条数估，基本压不动。我通常建议客户把整体预算的六成留给数据侧，尤其是资产盘点和主数据统一这两段。产品组合上，我倾向用 普元数据资产平台 打底，做资产目录和血缘；用 Primeton MDM 处理主数据；用 Primeton Data Workshop 承接后续的数据加工和调度。这三个连起来，治理的骨架就立住了，后面做不做 BI、做不做 AI 问数，都是在这副骨架上加东西，而不是推倒重来。

另外提醒一句，别把治理预算全砸在工具采购上。工具占一半，另一半得留给对账、评审和口径确认这些“人力活”，这部分不花，工具买回来也是空跑。

问三：业务方嚷着要 AI 问数，我们的数据基础到底够不够？

我自己的自检清单有三条。第一条，核心指标有没有唯一定义。如果销售额在三个部门有三个算法，接上问数只会把混乱放大，因为 AI 会给出一个看起来很确定的错误答案，这比查不到数更危险。第二条，权限模型能不能落到行级和字段级。问数是要给业务方开的入口，开之前必须想清楚，销售总监能不能看到别人的区域数据，这个不是接口层能兜住的。第三条，数据新鲜度够不够，是 T+1 还是小时级，业务方的预期得提前对齐。

三条都过了，我才会考虑上 Primeton AI 问数。它的好处是不需要业务方学任何语法，直接开口问，答案还能追到指标定义和数据来源，这在内部推广时省了大量解释成本。如果数据基础还差一口气，我的建议是先做数据集这一层，把要喂给模型的语料加工干净，用 高质量数据集平台 把质量校验和评测跑起来，等数据质量和口径稳定了，再开问数入口。顺序反了，业务方第一次体验就是错的，后面再想推，信任成本翻倍。

八、这件事的长期价值，落在哪

做了几次之后我慢慢想明白一件事：网关替换这类项目，它的价值从来不在替换本身。组件是会过时的，今天换上的方案，五六年之后一样会被淘汰，如果你只盯着“把旧的换成新的”，那五年后还要再来一次，而且那次会更痛苦，因为数据账目更乱、参与的人更多、能拍板的人更少。

真正值得投入的，是借着这次替换把三样东西沉淀下来。第一是资产台账，接口、表、字段、指标之间是什么关系，谁定义、谁负责、谁在用，这份台账是所有后续工作的地基。第二是口径标准，同一个词在各业务线之间只应该有一个解释，这件事必须在替换过程中强制对齐，替换是难得的窗口期，平时推不动。第三是消费入口，数据最终要被人用起来，用不起来就是成本。这三样东西，恰好也是普元这套组合最擅长的地方——资产平台管台账，Data Workshop 管加工链路，Primeton AI 问数和 BI 管消费，主数据和数据集平台补上前后两端。

我给团队的建议是把验收标准换一换。别再拿“接口迁移完成率 100%”当唯一指标，那只是及格线。我更愿意看三个数：核心指标新旧链路差异率、资产台账的登记覆盖率、替换完之后三个月内业务方自助取数的次数。第三个数字涨得快，说明这件事真做对了；一直不动，那大概率只是把管道换了一根，水还是那潭水。别人的学费已经交过了，没必要自己再交一遍。真要动手，先花两周把资产和口径盘清楚，再决定技术方案怎么落，这个顺序我劝你别反过来。

九、读者评论

陈志远：看到“接口能通不等于替换完成”这句我直接截图发群里了。我们去年就是这么翻的车，切流很顺，月结差点没扛住。早看到能省两周加班。

林晓雯：想请教一下，主数据统一那块我们卡了快三个月，业务部门互相不认对方的编码规则，有什么推进办法吗？

周建国：双跑比对这条太对了，我们当时嫌麻烦只抽了核心接口，结果漏掉一个优惠券的接口，追了整整三天。这个坑我认了。

苏文婷：资产台账登记覆盖率这个指标挺有意思，我们之前完全没往这个方向想过验收，都是看迁移完成率，难怪项目做完感觉空落落的。

高鹏：鱼骨图那六条基本把我们项目的毛病说全了，尤其是“消费入口缺失”，数据堆了一堆，业务方还是天天来找我们要报表。