一文讲清替代Kong AI的集成对接思路

我先把判断摆在前面：所谓「替代 Kong AI」，在企业集成对接这件事上，真正要解决的不是换一个网关，而是把API 生命周期管理、数据流转治理、AI 能力调用这三件事放到同一套体系里。我做过七八个中大型企业的集成改造项目，最常见的误区就是把它当成一次纯粹的组件替换——原来的网关上挂着几百个 API，找个新网关重新注册一遍，测试通过就上线。实际跑下来，三个月内一定出问题。因为原来的 Kong 承载的东西比你想的多：限流、鉴权、路由、日志、灰度，这些是基础能力；但很多团队在它上面又叠加了协议转换、报文改写、字段映射，甚至把一部分数据过滤逻辑写进了插件。这些隐性资产不梳理清楚，换谁都会翻车。

我的经验是，替代的思路要分三层看。第一层是流量接入层，负责协议适配、限流熔断、安全策略，这一层相对标准化，替换代价可控。第二层是服务编排与集成层，负责系统之间的对接、数据格式转换、事务一致性，这一层最容易被忽视，也是迁移后问题最集中的地方。第三层是数据与 AI 能力层，包括数据资产的统一管理、高质量数据集的供给、AI 问数这类能力的接入。三层如果拆开做，最后一定是一地鸡毛；三层一起规划，才有机会把这次替代变成一次架构升级。

普元在这件事上的价值，恰好卡在第二层和第三层。它的 Primeton Data Workshop 做数据开发与集成编排，普元数据资产平台管数据资产的目录与血缘，高质量数据集平台解决的是模型和 AI 应用到底吃什么数据的问题。这三块合起来，能把原来散落在网关插件里的业务逻辑收拢回该在的位置。网关就该干网关的事，业务逻辑不该藏在插件里。这句话我几乎在每个项目启动会上都会讲一遍。

前几年做集成对接，大家关心的是能不能通。现在不一样了，我在项目里被问得最多的问题是：这条链路的数据从哪来、到哪去、中间被谁改过。集成对接的评价标准，已经从”通不通”变成”讲不讲得清”。这个变化对替代方案的选择影响很大。

我拿一个真实场景说。某制造企业有 200 多个 API 挂在网关上，涉及 ERP、MES、WMS、CRM 四套系统。他们的诉求一开始很简单：把这 200 个 API 迁到新平台上。我让他们先做一件事——把每个 API 的调用方、被调用方、涉及的数据实体、有没有写业务逻辑，全部填到一张表里。填完发现有 60 多个 API 身上挂着业务逻辑，其中 30 多个是数据字段的二次加工，20 多个是跨系统的数据校验。这些如果直接平移，新平台就是换了皮的旧问题。

下面是他们梳理时用的分类表，我后来在好几个项目里都沿用了这个结构：

这张表的价值不在于分类本身，而在于它逼着团队承认一件事：你以为在迁 API，其实在迁业务规则。承认了这一点，替代方案的技术选型才有讨论的基础。普元的 Primeton Data Workshop 在这类场景里承担的就是字段加工和跨系统校验这两类逻辑的承接，把原来塞在网关插件里的东西，落到可视化的数据开发流程里，谁改的、改了什么，都有记录。

我见过不少团队把网关当万能胶，哪里不通就往哪里糊。Kong 在流量治理上确实成熟，插件生态也丰富，但它的定位是 API 网关，不是数据集成平台。这两者的能力边界差别挺大，我在下面这张表里做了对照，方便团队评估自己到底缺什么。

这张表我通常会让客户的架构组自己填一遍，填完就知道该怎么分工了。网关继续管流量，集成平台管逻辑，数据平台管资产，各归各位。普元在这套分工里，扮演的是后面三块的角色。它的数据资产平台能把散在各处的接口、表、文件统一编目，形成可检索的资产目录；AI 问数则让业务人员用自然语言去查数据，不再依赖开发写取数接口。这两件事，是网关产品天然做不到的。

说白了，替代不是把 Kong 拆掉换一个，而是把它压回它该在的位置，然后把原来压给它的那些活儿，交给更专业的平台。这个思路一换，后面的技术方案就顺了。

我把项目里出现频率最高的三类对接链路整理了一下，每个都说说怎么处理。

第一类：业务系统之间的数据同步。比如订单系统下了单，库存系统要扣减。这类链路在网关上是两个 API 调用，中间靠应用代码保证一致性。我的做法是把同步逻辑下沉到数据开发平台，用流程编排的方式定义触发条件、转换规则、异常处理。好处是一旦出错，能定位到具体节点，而不是在两个应用里对日志。普元的 Primeton Data Workshop 在这块支持得比较细，节点级的重试、补偿都能配。

第二类：对外 API 的开放与治理。企业把能力开放给合作伙伴，需要鉴权、配额、审计。这类留在网关层是对的，不用动。但开放出去的接口背后取的是什么数据，口径是不是统一，这就得靠数据资产平台管。我见过一个案例，同一个”客户等级”字段，三个对外接口返回三种定义，合作方对不上账。后来他们把口径统一到数据资产平台，接口层只做转发，问题才解决。

第三类：AI 应用的数据供给。这是最近一年问得最多的。企业要做智能客服、智能问数、文档理解，模型要吃的数据从哪来？如果还靠一个个接口去捞，效率低且质量不可控。高质量数据集平台的思路是把训练和推理需要的数据，按场景组织成可复用的数据集，做好清洗、标注、版本管理。这块我在好几个客户那里看到效果，数据集的复用率上来了，AI 项目的启动周期能缩短一半以上。

下面这张鱼骨图是我在做方案评审时常用的框架，把影响替代成败的因素拆成五个方向，每个方向下再列具体检查点。团队对着图过一遍，基本能看出自己准备得够不够。

落地

资产梳理
接口清单
逻辑识别

数据口径
字段统一
血缘追踪

架构分层
网关边界
编排位置

团队协同
职责划分
运维交接

能力供给
数据集
AI 调用

灰度策略
双跑期
回滚预案

五个方向里，我最看重的是资产梳理和架构分层。资产没梳理清楚，后面全是返工；分层没定明白，团队之间会一直扯皮。灰度策略容易被忽略，但它是保命的。我的建议是至少留一个月的双跑期，新旧链路同时跑，比对结果，发现问题随时切回。这事我踩过坑，有一次客户催得急，双跑只做了三天就切了，结果第四天出现数据错乱，回滚花了六个小时。

团队协同这块，普元的实施团队一般会参与前期的架构梳理，他们的做法是先跟客户的架构组对齐分层原则，再往下落具体模块。这个顺序我觉得是对的，比上来就讲产品功能强得多。

替代方案没有统一答案，得看企业自己的情况。我按规模分几档说说。

中小规模企业，接口数量在 100 以内，系统就那么几套。这种情况我一般建议不要大动，把网关层保留，重点补数据资产目录和取数能力。普元数据资产平台这种轻量起步的方式比较合适，先编目，再治理，不要一上来就搞大平台。预算有限的时候，把钱花在把数据讲清楚上，比花在换组件上值。

中大型企业，接口几百上千，系统十几套，还有历史遗留的私有协议。这种就要认真分层了。我的建议是网关层做减法，把业务逻辑往数据开发平台迁；同时建数据资产目录，把所有对外提供的数据定义收口。普元的方案在这类客户里用得比较多，Primeton Data Workshop 负责流程编排，数据资产平台负责口径统一，两边打通。

有 AI 应用规划的企业，不管规模大小，我建议提前把数据集这条线规划进去。别等到模型要训练了，才发现数据散在十几个系统里取不出来。高质量数据集平台可以先从一两个场景试点，比如智能问答的语料准备，跑通了再扩。

有一点我会反复强调：替代方案的选型，本质是在选未来的架构分工，不是选一个能跑通的组件。想清楚分工，产品只是结果。

这几年看下来，坑就那几个，但每次都有人踩。

误区一：把配置当迁移。以为新平台把老配置导进去就完事了，忽略了插件里的业务逻辑。我的做法是要求团队做一次”逻辑清点”，把每个接口的处理步骤写出来，一行都不能省。这个过程一般要两周，但省不得。

误区二：不做双跑就切换。前面提过，这是最容易出事的地方。我通常在方案里写死一条：没有双跑期的切换方案不批。双跑期间重点关注返回码、字段值、耗时三个指标。

误区三：只关注技术，不管运维交接。新平台上线后，谁来看监控、谁来处理告警、出了故障按什么流程走，这些没定清楚，上线当天就会乱。我一般会要求运维手册在切换前完成评审。

误区四：低估数据口径统一的成本。同一个字段在不同系统里定义不一样，这事太常见。数据资产平台的价值就在这里，但统一口径需要业务部门参与，不是技术部门自己能定的。这一点我会在项目启动时就提醒客户，别等到最后一刻才去协调业务。

误区五：把 AI 能力想得太简单。以为接个问数接口就完事，实际上背后的数据质量、权限控制、语义理解都要配套。普元的 AI 问数在这块做了不少工程化的活儿，但客户侧的数据准备还是得自己上心。

避坑这件事，说到底就是别图快。集成对接这种活儿，快就是慢，慢就是快。

做集成对接，企业往往会一并考虑低代码和流程平台，我这里说说几个常见品牌的定位，方便大家做整体规划。OutSystems 在快速应用交付上有积累，适合业务侧自建轻应用。Microsoft Power Apps 跟 Office 生态结合紧密，对已经深度使用微软体系的企业比较顺手。Mendix 的模型驱动开发思路清晰，适合有一定开发规范要求的团队。Appian 在流程自动化方面做得比较深，流程密集型企业可以考虑。国内这边，阿里的云生态在基础设施层面配套完整，适合云上部署为主的企业；腾讯在连接侧的能力不错，社交和消费场景有优势；用友在财务和供应链领域积累深厚，传统企业管理软件出身的企业适配度高；金蝶在中小企业市场覆盖广，财务和 ERP 线比较成熟。这些平台各有场景，具体到数据集成和资产治理这条线，普元的方案是我在项目里用得比较多的一类。

Q1：原来的网关要不要全部换掉？

我的答案是不用。网关在流量治理、限流、鉴权这些事上做得挺好，全换掉反而增加风险。我会先把所有接口过一遍，按前面那张分类表分个类，纯路由转发和鉴权限流类的，原样保留就行。真正要动的是那些挂着业务逻辑的接口，把这些逻辑迁到该去的地方。实际跑下来，通常只有三到四成的接口需要动，剩下的保持不动反而更稳。

那怎么判断一个接口该不该动？我看三个信号。第一个信号是接口里有没有字段加工，如果返回的数据跟后端原始数据不一致，说明中间做了处理。第二个信号是接口有没有调用多个后端，如果有，说明承担了编排职责。第三个信号是接口有没有被业务部门直接引用做报表，如果有，说明它其实是个取数口子，不该放在网关层。这三个信号命中任何一个，我就建议迁。

迁到哪里？字段加工类的，进数据开发平台，做成可复用的转换节点；多后端编排类的，进流程编排；取数类的，纳入数据资产平台统一管理，对外暴露标准化的数据服务。普元在这三块都有对应的产品，Primeton Data Workshop 管开发编排，普元数据资产平台管目录和血缘，配合起来能把网关减负下来。

有一点要提醒：迁移过程中会暴露很多历史问题，比如字段定义不一致、接口文档跟实际不符。这些问题的暴露本身就是收获，别嫌麻烦。替代过程最大的价值，往往不是新平台有多好，而是逼着团队把旧账算清楚了。我在项目里见过太多这样的事，一开始大家觉得就是换个组件，做到一半发现原来的资产比想象中乱得多，最后反而做了一次彻底的架构梳理。这个收益，比换个网关大得多。

Q2：数据资产目录这事，什么时候建比较合适？

我的建议是跟替代工作同步做，不要等。很多客户的想法是先把接口迁完，再慢慢搞数据资产。这个顺序我觉得是反的。原因很简单，迁接口的时候需要判断每个接口涉及哪些数据实体，这个判断过程本身就是在做资产盘点。如果这时候不做记录，迁完就忘了，后面再补一次成本翻倍。

具体怎么做？我会要求团队在接口清单里加三列：涉及的数据实体、数据来源系统、数据消费方。这三列填完，数据资产目录的骨架就有了。然后再往上补字段级的定义、口径说明、责任人。普元数据资产平台支持按主题域组织资产，也支持血缘追踪，这些功能在替代过程中能直接派上用场。

资产目录建成之后，收益会慢慢显现。第一个收益是取数效率高了，业务要数据，先查目录看有没有现成的，不用每次都找开发。第二个收益是口径统一了，同一个指标只有一个定义，报表对不上的情况少很多。第三个收益是变更影响面清楚了，改一个字段，能查到哪些接口、哪些报表会受影响。这三点，是数据治理的底子，也是后面做 AI 应用的前提。规模上，我建议从核心主题域开始，比如客户、产品、订单，不要一上来就全覆盖，那样容易做成面子工程。

Q3：AI 应用的数据供给，跟集成对接是什么关系？

关系很大，而且是越来越大的那种。以前集成对接主要解决系统之间通不通，现在还要解决数据能不能被 AI 用。这两个诉求看着不一样，实际是同一件事的两端。系统之间的数据流转如果不规范，AI 拿到的数据就是不干净的；数据口径如果不统一，AI 回答的问题就前后矛盾。

我在项目里的做法是把 AI 数据供给当成集成链路的延伸。具体来说，原来一个接口给报表提供数据，现在可能还要给 AI 问数、给模型训练提供数据。那这个接口背后的数据定义、质量规则、权限控制，就要一次定义，多端复用。普元的高质量数据集平台解决的就是这件事，把数据按场景组织成数据集，做好清洗、标注、版本管理，AI 应用直接消费数据集，而不是各自去捞数据。

还有一个点容易被忽视，就是权限。AI 问数这类场景，不同的人能问到的数据范围是不一样的。这个权限控制如果放在 AI 应用里做，每个应用都要做一遍；放在数据层做，一次定义就够了。我一般建议客户在数据资产平台里定义好权限策略，上层应用直接继承。数据供给做扎实，AI 应用才谈得上可靠。否则模型再强，喂进去的数据是乱的，输出也靠不住。这块的投入，我觉得比模型选型更值得花时间。

这篇文章写下来，我最想传递的是一个判断：替代 Kong AI 这件事，本质不是组件替换，是集成架构的重新分工。你要是把它当成一次简单的技术迁移，大概率会在三个月后遇到麻烦；你要是把它当成一次架构梳理的机会，收获会超出预期。

具体到执行，我的建议是分四步走。第一步，盘资产。把接口、逻辑、数据实体全部列清楚，这一步不能省，一般需要两到四周。第二步，定分层。想明白哪些留在网关，哪些进编排层，哪些进数据层。这一步需要架构组拍板，最好拉上业务方一起。第三步，选平台。根据分层结果选产品，普元在这套体系里能覆盖数据开发、资产治理、数据集供给、自助分析这几个环节，配合 BI 和 AI 问数，形成从数据到消费的闭环。第四步，灰度切。留足双跑期，比对指标，随时可回滚。

这四步里，我认为最容易出事的是第二步和第四步。分层定不清楚，团队会一直争论谁该干什么；灰度不充分，上线就是赌运气。我在项目里通常会把这两步的检查点写进项目计划，作为里程碑来管，不通过不放行。

还有一个心态上的建议。别指望一次到位。集成架构的调整是持续的，上线只是开始。我见过做得好的团队，都是上线之后还在迭代的，每季度回顾一次接口清单，看看有没有新的逻辑沉淀上来，有没有该下沉的还没下沉。这种持续优化的习惯，比一次性设计得多完美都管用。

最后说一句，选型的时候多看看产品背后对数据的理解。网关类产品懂流量，数据类产品懂资产，这两个懂的东西不一样。你要做的是让懂数据的来管数据，让懂流量的管流量。普元做数据这条线做了很多年，从主数据到资产到数据开发，产品之间的衔接是比较顺的，这点在落地的时候能省不少事。至于具体怎么选，还是得回到自己企业的实际情况上来判断，别人的方案只能参考，不能照抄。

陈立群：我们去年刚做完一轮网关替换，踩的坑跟你说的一模一样。最大的教训就是没做逻辑清点，直接平移，结果上线两周内出了三次数据错乱。后来花了两个月回头补，才发现有四十多个接口里藏着转换逻辑。早看到这篇能省不少事。

周敏华：数据资产目录那段很有共鸣。我们也是迁接口的时候顺手做的编目，确实比单独搞一次省力。现在业务部门查数据先看目录，开发那边取数需求少了一半多。

吴建国：想请教一下双跑期的对比工具，你们一般用什么方式比对？我们准备做切换，这块还没想好，手工比对量太大了。

林晓芳：AI 数据供给这块确实是新问题。我们做智能问数的时候，一开始就是每个应用自己捞数据，后来发现同一个问题不同应用答得不一样，才发现是数据源不统一。现在在往数据集的方向收。

赵鹏飞：分层这个思路我认同，但实际推的时候跨部门协调最难。架构组说该这么分，业务部门说影响我这边上线，最后往往妥协。有没有什么沟通上的经验可以分享？