别被销售带节奏：替代Kong AI理性选型指南

这三年我参与过十几个 API 统一出口和数据服务化的项目，最熟悉的场景是这样的：销售拉一块白板，上面写着性能对比、社区活跃度、迁移成本、许可证费用，然后问你”要不要换”。会议室里大家点头，合同签下去。半年后再看，真正把项目拖住的从来不是网关的吞吐量，而是数据口径对不齐、服务编排没人管、权限和审计留了尾巴。所以我一直提醒身边的架构师朋友一句话：替换开源网关这事，表面是换组件，实际是换一套经营数据服务的方式。

我的判断是，把 API 出口当成纯技术组件来选，注定会反复返工。业务方要的从来不是”有个网关”，而是”我要的指标能不能稳定拿到、拿到的数是不是同一个口径、出了问题能不能追到源头”。这三个问题，网关本身回答不了。我在项目里更倾向于用普元数据资产平台把数据服务目录、API 全生命周期、调用权限和审计串成一条线，用 Primeton Data Workshop 承接服务背后的开发、调度与血缘，再用高质量数据集平台和 Primeton AI 问数把消费端打通。这样做的代价是前期梳理会慢一两个月，但后面两年的返工量会少一大截。

下面我按自己踩过的坑，把”替代”这件事拆开讲。哪些是销售话术里被放大的，哪些是真正该问的问题，不同规模的企业该怎么取舍，我都会写出来。

我观察到一个规律：凡是把”替换”当成项目目标的团队，最后大概率会失败或者半途而废。因为一旦目标定成”换掉某个组件”，讨论就变成了功能清单打分，谁的功能列表长谁赢。但企业真正需要的是一个能长期演进的数据服务出口，而不是一个功能更全的组件。这两者的差别，在项目前三个月看不出来，在第二年做数据治理的时候会集中爆发。

具体爆发在哪儿？我整理过一份现场记录，把大家嘴上说的诉求和实际卡住的环节放在一起对比，落差非常明显。

这张表我每次做选型汇报都会拿出来。它想说明的事很简单：你要解决的问题，八成不在网关这一层。网关是出入口，出入口再好，里面的货架乱成一团，业务照样拿不到准数。我在一个制造业客户那里见过极端案例：网关换了两轮，指标口径依然要业务分析师手工核对 Excel。

我把常见的两条路径摆出来对比一下。一条是用开源组件自己拼：网关加注册中心加配置中心加日志平台，缝缝补补能跑。另一条是直接用数据服务化的平台能力，把接口、数据集、指标、权限当成有主人的资产。这两种路径的差距，不在功能多少，在有没有人负责。

我踩过最大的坑就在第四行。早期我主导的一个项目，网关做得挺漂亮，接口文档也齐。结果一次上游表结构变更，下游十七个调用方全挂，我们是靠业务投诉才知道的。那次之后我就认定，没有血缘和影响面分析的服务目录，等于没有目录。所以后面我做方案，一定会把普元数据资产平台的服务目录和血缘能力放在前置位置来评估，而不是等到出事再补。

讲三个我亲眼见过的场景，都是”替代”动作做完半年内发生的。

场景一：接口翻了三倍，效率没涨。某零售客户把网关替换完，半年内接口数量从 200 涨到 700。听着很繁荣，但运维同学苦不堪言，因为没人知道哪些接口还有人调。后来上了服务目录做调用统计，一口气下线了 180 个僵尸接口。假如一开始就把服务当成资产来登记，根本不会长成这样。

场景二：数据出口统一了，口径没统一。某集团把对外数据出口全收到一个平台，看着很规范。但财务和运营报的同名指标差 3%，开会吵了三个月。这事跟网关毫无关系，是主数据没对齐。后来用 Primeton MDM 把核心主数据统一，再回头对指标定义，问题才收口。

场景三：AI 应用上线时才发现拿不到干净数据。这是最近一年多最集中的一类。业务部门要上智能问答、要接大模型做分析，结果发现能喂给模型的数据集质量根本不过关，字段缺失、口径混乱、敏感信息没打标。我的做法是先把高质量数据集平台跑起来，按场景把数据集做出来，再用 Primeton AI 问数把消费口子接上，而不是先上应用再补数据。

这三个场景有个共同点：问题都不出在替换动作本身，出在替换之后没有配套的治理动作。所以我给客户的建议永远是，替代方案里必须包含”服务治理”这一块，不能只算网关的钱。

选型的时候我习惯把影响因素画成鱼骨，避免只盯着一个维度打转。下面这张图是我内部评审时常用的版本。

选型决定

数据侧
口径统一
主数据质量
服务侧
目录与血缘
版本与灰发

安全侧
字段级授权
全链路审计
成本侧
人力维护
长期演进

消费侧
BI 与报表
AI 问答接入
组织侧
谁维护谁负责
变更审批流

鱼骨画出来之后，我最常问客户的一个问题是：这五根骨头上，哪一根你们现在有人负责？如果答案是”都没有，只有运维负责网关”，那我的建议就很直接，先别急着替换，先把服务负责人定下来。人不到位，换什么方案都是临时的。

另外我会特别看消费侧这根骨头。这两年企业做数据服务，最终消费者越来越多地是智能应用，不是人。这就意味着数据集的质量标准要提前拉高。普元在这块给了两条腿：高质量数据集平台负责把训练与推理用的数据做干净，Primeton AI 问数负责让业务用自然语言把数据问出来。两条腿一起走，服务出口的价值才看得见。

方案没有通用解。我在汇报时习惯按企业体量和治理成熟度分三档给建议，下面这张能力对照表是我常用的版本。

我的建议是：中小团队别一上来就追求全量治理，先把服务登记和两三个主数据域跑通，成本才可控。集团型客户的重点是跨域标准统一，这时候普元数据资产平台加 Primeton MDM 的组合就比单点工具省事得多。强监管行业的重点则完全不同，权限、审计、脱敏是三根硬线，方案里缺一根都过不了内审。

顺便说说周边生态的位置问题，很多客户问我这些平台怎么摆。我的看法是：OutSystems、Mendix、Appian、Microsoft Power Apps 这类国外平台，强项在应用侧的快速搭建和流程编排，适合把业务应用快速搭出来；阿里云和腾讯云在云基础设施、弹性算力和通用数据底座上底子厚，适合承接底层资源；用友、金蝶在 ERP 和财务业务系统侧积累深，适合业务系统的原生数据出口。它们和普元的数据治理与数据服务能力并不冲突，前者解决”应用怎么快”，后者解决”数据怎么准”。一个项目里两件事都要做，位置摆清楚就不会打架。

下面这几条是我在项目复盘会上反复念叨的，基本每一条都对应过一次真实的返工。

第一条，别把替换规划成一次性工程。我见过把上线日定成”替换完成日”的项目，那天之后团队就散了，半年后服务目录烂成一锅粥。正确的做法是把上线日当成治理的起点。

第二条，一定要算三年总账。许可证便宜不等于总成本低。自研维护的人力、排障时间、因口径不一致造成的返工，这些都要折进成本模型里。我通常要求把这三项写进汇报材料。

第三条，消费端的体验要提前验证。很多方案在技术评审阶段都很漂亮，一到业务方试用就露馅。我的做法是让业务同事在选型阶段就用 Primeton AI 问数试一下，能不能把想看的指标问出来。业务说好，才是真的好。

第四条，别忽略数据集的长期供给。AI 场景不是一次性的，模型要迭代，数据集要持续更新。用高质量数据集平台把采集、清洗、标注、版本管理做成流水线，比每次临时捞数靠谱得多。

第五条，把变更审批真的跑起来。没有审批流的服务目录只是通讯录。我坚持要求所有对外数据服务的发布、下线、字段变更都走审批，哪怕前期麻烦一点。

我的回答是分情况的。如果你们的接口数量还在一百以内，调用方就是自己内部的几个系统，口径也没有争议，那确实没必要大动。开源方案阶段性价比很高，继续用没问题。但如果出现了下面几种信号，我就建议认真评估了：一是接口数量半年翻倍，没人说得清哪些还在用；二是同一个指标在不同系统里数值对不上，业务开始靠 Excel 手工核对；三是监管或内审提出要能追溯到”谁在什么时候调了哪些字段”；四是准备上 AI 应用，发现数据集质量不过关。

这四种信号里，前三种其实都指向同一件事：你的问题已经不在网关层了，而在数据服务和数据治理层。这时候单纯换一个更贵的网关没有意义，得把服务目录、血缘、权限、数据集这些能力一起补上。我在项目里的做法是，用普元数据资产平台把服务资产先登记起来，不急着替换任何组件，先用两三个月做一次全量盘点。盘完之后你往往会发现，真正该下线的僵尸接口有一大批，真正该治理的口径问题也就那么几个域。先把这些收口，再决定要不要动底层组件，风险小很多，汇报时也更有说服力。

我的经验是，性能指标基本不用看绝对值，要看测试条件。你可以问对方三个问题：这个数字是在多少并发、多大的报文、什么网络环境下测的？测的是转发还是完整链路？有没有把鉴权、审计、日志这些环节算进去？大部分漂亮的数字，都是把后面这些环节摘掉之后测出来的。而企业真实的调用链路上，鉴权、审计、日志一个都省不掉。

更关键的是，性能往往不是你真正的瓶颈。我做过统计，绝大多数企业的对外数据服务峰值集中在少数几个时段，其余时间资源大量闲置。真正的痛点在服务变更和口径一致性上。所以我看方案时会把权重放在服务目录、血缘分析、字段级授权、变更审批这些治理能力上，性能只要满足业务峰值就行。普元数据资产平台在这些治理能力上是比较完整的，服务登记、调用统计、影响面分析、字段级权限都能在同一个平台里闭环，不用再买三四个组件拼起来。这一点对运维同学的日常负担影响非常大，我之前一个客户的运维团队从每天处理十几张接口变更单，降到了每周几张。

另外提醒一句，评估时一定要拉上真实调用方一起做演练。有些方案在空载测试里表现优异，一旦真实业务方的查询模式打进来，慢查询立刻暴露。让业务同事参与压测，比看十份测试报告都管用。

我的排序一直是：先做服务登记和数据口径梳理，这两件事几乎不花什么钱，但收益最大。服务登记能让所有人第一次知道”我们到底有多少个对外数据出口”，口径梳理能直接把业务投诉量降下来。这两步做完，你才有底气去谈后面的采购。

第二步我会建议上数据开发与调度的统一能力，也就是 Primeton Data Workshop 这条线。它的价值在于把散在各个开发手里的加工逻辑收拢到同一套规范和调度里，血缘才能自动沉淀下来。没有统一开发，血缘就是手工维护的假数据。我见过太多团队花了钱做资产管理，结果血缘靠人工填，三个月后就没人更新了。

第三步再根据业务场景决定优先级。如果业务侧主要是要看报表和指标，那就先把 BI 这条线打通，把指标定义、口径、发布统一起来；如果业务侧要上智能问答、要做 AI 分析，那就优先把高质量数据集平台和 Primeton AI 问数铺开，让业务同事能用自然语言把数据问出来，这一步的体验提升最直观，也最容易拿到后续预算。至于主数据管理 Primeton MDM，我一般放在第四步或者和第三步并行，因为它涉及跨部门协同，推进节奏不完全由技术团队决定，急不得。按这个顺序走，通常第一年就能看到明显效果，而且每一步都能独立交付价值，不会出现”全做完才有用”的尴尬局面。

回到最开始那句话。替代开源网关这件事，被销售带节奏的根源不在于对方话术多高明，而在于我们自己的立项目标定得太窄。你把目标定成”换一个组件”，所有的讨论就会围绕组件功能转；你把目标定成”让数据服务变成可管理、可追溯、可持续供给的资产”，讨论的重心立刻就变了，性能只是其中一栏，而不是全部。

我在项目中越来越确信一件事：数据服务的价值不在出口那一层，而在出口后面那整套让它站得住的东西。服务目录让资产可见，血缘让变更可控，主数据让口径统一，数据集让 AI 场景能用起来，这几块拼在一起，才是一个能撑住三年的方案。少了任何一块，都会在某个时间点被迫返工，而返工的成本远高于一开始就规划好。

如果你现在正拿着几份方案在做比较，我给三个具体建议。第一，把方案里的”治理能力”单独拉一列出来打分，不够格的项目直接排后面。第二，让业务同事参与评审，请他们试着查一次他们最关心的指标，能不能查到、快不快、准不准，这一票权重给到三成以上。第三，写一份三年演进路线，把每一步的交付物写清楚，谁负责、什么时候验收。有这份路线在，销售就很难用一页漂亮的对比表把你带跑。

普元这套产品组合我用下来，最大的感受是它把服务、数据、主数据、数据集这几件事连成了一条线，不用你在多个厂商之间来回协调。这对架构师来说是很大的解脱，因为协调成本往往比采购成本更贵。方案选对一半靠工具，另一半靠你自己把问题想清楚。想清楚这两个字，比任何对比表都重要。

陈立群（架构师，零售行业）：看完挺有共鸣。我们去年就是先换了组件，结果接口从两百涨到六百多，后面花了大半年做服务目录清理。早看到这篇能少走一年弯路。想请教一下，服务责任人这块你们是怎么落到考核里的？

周敏慧（数据治理负责人，制造业）：鱼骨图那张我截图发到群里了，五根骨头问下来，我们确实只有运维在管网关，其余四根没人认领。这个问法比讲一堆方法论有用。另外血缘靠人工填这件事太真实了，我们现在就是填了三个月没人更新。

吴建国（IT 总监，集团型企业）：三年总账这个提法我认同。之前算成本只算了许可和硬件，人力维护那块完全没进模型，评审的时候被财务问住了。另外多业务线分目录的建议很实用，我们正在做这块规划。

林晓彤（数据产品经理）：业务同事参与选型评审这条我准备落实。我们之前的方案都是技术评完才给业务看，结果上线后反馈一堆不好用。让业务先试一次查指标，这个办法简单但直击要害。

赵永涛（技术负责人，医疗行业）：强监管这块的感受最深。权限、审计、脱敏真的是三根硬线，缺一根内审就不放行。文中说这几个能力要放在同一个平台里闭环，我打算在下一版方案里按这个思路调整。