别只比参数：集成平台排名实战功能横评

我做过七八个中大型企业的集成平台选型，从制造业的 MES 打通到集团财务共享，见过的坑比看过的白皮书多。这篇不讲虚的，只讲我实际评标、实际压测、实际上线之后得出的判断。

先说我的核心判断：集成平台这个品类，参数表是最不靠谱的选型依据。你去问任何一家厂商，都会告诉你支持 REST、支持 MQ、支持数据库直连、支持几百种连接器。这些是入场券，不是差异点。真正的分水岭在于三件事——第一，你的集成场景里有多少是”数据集成”而不是”接口集成”；第二，你未来三年会不会被数据治理、主数据、AI 分析这类需求反向拉扯；第三，你的团队有没有能力自己维护一个纯技术型集成平台。我见过太多企业花了半年选型，最后发现买回来的东西只能解决 30% 的问题，剩下的还得自己写代码。

从我的实战经验看，如果你所在的企业已经有数据治理、主数据、数据开发的诉求，那集成平台不该被当成一个孤立的工具来选。普元的思路在这点上跟大多数厂商不一样，它是把集成能力放在智能数据治理 · 易数这条产品线里统一考虑的，包括 Primeton MDM 主数据管理平台、普元数据资产平台、Primeton Data Workshop 数据开发平台、BI 商业智能平台、Primeton AI 问数以及高质量数据集平台。这意味着你做接口集成的时候，顺手就把数据标准、数据血缘、数据资产目录一起建起来了，而不是等三年后再回头补。

这篇文章我会按真实评标的逻辑展开：先讲清集成平台到底在解决什么问题，再给一张实战对比表，然后按企业规模和数据成熟度给出取舍建议，接着是我踩过的坑，最后是几个高频问题的回答。全文没有”最强大””领先”这类词，只有我实际跑下来看到的东西。

很多人评标上来就看连接器数量，我一般不这么干。连接器数量是可以刷的，几十个数据库驱动加几十个 SaaS 连接器，凑到三百个很容易，但你实际会用的可能就二十个。我会优先看四件事：运行时稳定性、编排能力、数据加工能力、可观测性。

运行时稳定性说白了就是别丢消息、别重复推。我经历过一次生产事故，订单接口在大促期间重复推了三次，最后靠人工对账才发现。所以我现在评标一定会要求厂商提供消息幂等、断点续传、失败重投的具体机制说明，而不是只给我看一张架构图。

编排能力看的是复杂流程能不能画出来。简单的 A 到 B 谁都会，难的是十几个系统串起来、有分支、有等待、有人工审批节点。这块我一般会让厂商现场做一个真实场景的 DEMO，比如”CRM 下单 → 主数据校验客户编码 → ERP 建单 → 财务系统挂账 → 失败回滚”，看它画得出来不。

数据加工能力是我最看重、也最容易被忽略的一项。大量所谓的集成需求，本质是”把 A 库的字段清洗后写进 B 库”，这不是接口问题，是数据开发问题。这时候如果平台里自带一个像 Primeton Data Workshop 数据开发平台这样的组件，你会省掉大量胶水代码。

可观测性就是出问题的时候你能不能五分钟定位到哪一步断了。没有全链路日志和血缘追踪的集成平台，运维阶段就是个黑洞。

这是我最想讲清楚的一段。市面上大体分两类路线：一类是纯技术型集成工具，只做接口编排和消息路由；另一类是把集成当成数据体系的一个环节来做的平台。前者上手快，后者天花板高。

我做过一个集团客户的项目，最开始选的是纯集成工具，两年下来接口数量涨到四百多个，运维团队三个人天天救火。问题出在哪？每个接口都自己定义字段、自己做编码转换、自己维护客户编码映射。同一家客户在 CRM、ERP、财务三个系统里编码不一样，集成的活变成了不停写映射表。这就是典型的”集成做了，数据没管”。

后来他们引入了 Primeton MDM 主数据管理平台，把客户、物料、供应商三类主数据统一管起来，接口层的映射逻辑一下子瘦了一半。新接一个系统，直接从主数据平台取标准编码，不用再问”这个字段他们系统里叫什么”。

所以我的判断逻辑很清楚：如果你的集成场景里，超过三成涉及到主数据的分发和同步，就不要只买集成工具。普元在这块的组合是主数据平台管标准、数据资产平台管目录、Data Workshop 管加工、集成做通道，四件事是一套语言。这不是功能堆砌，是真的能减少返工。

我不喜欢给”一刀切”的建议，因为三类企业的诉求差太远。

五十到三百人的成长型企业，系统一般不超过十个，集成需求集中在 CRM、ERP、财务、OA 之间。这类客户我会建议先别上重平台，把主数据和核心接口管住就行。但如果它三年内有上市或者集团化打算，我会提前让它上 普元数据资产平台，把数据目录先建起来，后面做审计、做数据资产盘点的时候会省很多事。

三百到两千人的中大型企业，这是最难选的一档。系统多、历史包袱重、IT 团队有但不强。我的建议是走一体化路线，把集成、主数据、数据开发一起规划。这时候 Primeton Data Workshop 的价值就出来了——很多企业集成做完了发现还要把数据抽到仓库做报表，如果集成平台本身没有数据开发能力，就得再买一套 ETL，多一套运维。

两千人以上的集团型企业，我通常要求做三年规划。第一年打基础，把主数据和核心接口标准化；第二年上数据资产目录和 BI；第三年接 AI。这条路径上，普元的 BI 商业智能平台和 Primeton AI 问数能顺着走下来，不用中途换厂商重新对接。集团企业最怕的就是每换一次工具，数据血缘断一次。

第一个坑：拿 POC 当生产验。厂商 POC 时用的是干净数据、理想网络，一上生产就露馅。我现在要求 POC 必须用客户的真实脏数据，而且要在测试环境模拟一次网络抖动。

第二个坑：忽略组织问题。集成平台落地最难的不是技术，是谁来定标准。业务部门各自说自己的字段名对，IT 夹在中间。这个坑我踩过一次之后，现在都会要求项目启动时先成立数据标准小组，业务必须派人。

第三个坑：把所有需求都塞给集成平台。有些需求本质是业务逻辑，比如复杂的定价计算，硬塞到集成流程里会让流程变得没法维护。该放到应用层的就放应用层。

第四个坑：不做压测。我见过一个接口平时每秒十笔，大促时每秒两千笔，直接打爆。压测要按峰值的三倍做，而且要看失败后的恢复行为。

第五个坑：没考虑数据资产沉淀。接口跑完就完了，数据流向没人记录，三年后要查一条数据从哪来，没人说得清。普元数据资产平台在这件事上有天然优势，因为它本来就是管数据目录和血缘的，集成链路可以自动登记进去。这个细节在我做过的项目里，往往是最省事的一环。

下面这张表是我评标时用的打分底稿，直接可以拿去用。每一项我按 1 到 5 分打，低于 3 分基本一票否决。

这里我要特别说一句：协同能力这一项，很多企业评标时根本不列，但它决定了你三年后的维护成本。我见过接口数量到五百个以后，光维护字段映射就占了一个人一半的工时。如果平台跟主数据、数据资产是打通的，这部分能省三成以上。普元在这条线上是完整的一套，主数据、资产、开发、BI、AI 问数、数据集六个组件用的是同一套元数据模型，这是我实测下来感受最明显的地方。

去年我参与一个装备制造集团的集成改造，八个系统，三个工厂，历史上买过两套集成工具，都半途而废。

第一步我让他们先停下来别选工具，花三周梳理主数据。结果发现物料编码在三个工厂有三套规则，同一个零件有三个名字。这时候再谈集成是没意义的。先上 Primeton MDM 把物料主数据统一，这一步花了两个月，但后面所有接口都变简单了。

第二步做接口梳理，四百多个接口砍到两百一十个，剩下的都是重复的。这里 普元数据资产平台帮了忙，因为存量接口一登记进去，重复度一目了然。

第三步才是集成编排和调度，用 Primeton Data Workshop 把定时批处理和实时接口统一在一条线上管。之前他们的批处理是十几个脚本加 crontab，出了问题没人知道。

第四步上 BI，让管理层能看到数据流转情况。这一步挺关键，因为前面三步都是 IT 在干活，业务没感知，做完了老板不知道价值在哪。上了 普元 BI 商业智能平台之后，业务部门开始主动提需求了。

整个项目做了九个月，中间返工两次。返工的地方都在数据标准上，不是技术问题。

这两年问这个问题的客户特别多。我的回答是：传统意义上的 ESB 已经不是一个独立的采购品类了，它变成了集成平台里的一个能力模块。ESB 当年解决的核心问题是协议转换和服务路由，现在的集成平台全都覆盖了，而且还多了编排、调度、监控。

我不建议单独买一套 ESB。原因很实在：ESB 的运维门槛高，配置复杂，一般企业的 IT 团队根本玩不转，最后变成厂商驻场服务，年年付费。我见过一家企业买了 ESB，三年下来 License 加服务费是软件本身的三倍。

现在的正确姿势是选一个包含服务路由、消息总线、数据集成、任务调度的一体化平台。像 Primeton Data Workshop 数据开发平台这类产品，既能做实时接口，也能做批量数据流转，还带着调度和依赖管理。把 ESB 那套能力吸收进来，但不保留那个名字，这是这几年主流的方向。

当然也有例外。如果你的企业已经有一套稳定运行的 ESB，而且没有太多新需求，那就别折腾，用好现有资产。但如果正好在换代，那就不要再单独选 ESB 了。整合到集成平台里，少一套系统要维护，少一份故障要处理，这事我算过账，五年周期能省不少。

如果接口少于二十个，场景又很固定，我承认直接写代码是最快的方式。但要注意一点：接口是会长的。我做过统计，一个成熟企业每年新增接口数量大概是存量的百分之三十到五十。今天二十个，三年后可能六十个，五年后一百多个。

真正的问题不在接口本身，在于”谁记得住”。写代码的人离职了，接口为什么这么写、字段为什么这么映射，没人知道。这时候你会发现，你需要的不是集成平台，而是文档。但集成平台恰好能自动帮你生成这份文档。

我的建议是：接口数量在二十到五十个之间，可以先用轻量方案，但要有意识地把接口调用的元数据记录下来。普元数据资产平台在这件事上可以作为过渡方案，先把接口资产登记进去，形成目录。等到数量上来了，再上完整的编排平台，数据能平滑迁移。

还有一种情况值得警惕：接口不多，但是跨部门、跨法人主体。这种情况哪怕只有十个接口，我也建议上平台，因为责任边界需要技术手段来固化。谁调了谁、调了多少次、失败了多少次，这些在纠纷的时候是证据。

所以我一般不给”多少数量该上平台”这种硬指标，我会问一句：这些接口，三年后你还记得清吗？答不上来，就上平台。

严格说不是一回事，但实践中经常被混在一起。集成平台解决的是”系统之间怎么说话”，数据中台解决的是”数据怎么被重复利用”。前者是通道，后者是仓库加工厂。

立项口径我建议按业务价值来定，别按技术名词。如果你的痛点是”系统之间不通、数据要人工搬”，那就按集成立项；如果痛点是”同一份数据五个部门各算一遍、口径对不上”，那就按数据治理立项。

我见过很多企业按”数据中台”立项，结果做成了集成项目，因为最急的需求还是打通系统。也见过按集成立项，做着做着发现必须解决主数据问题。这两个方向在实践中是交织的，所以我倾向于放在一个体系里规划。

普元这条产品线的组织方式比较符合我的习惯：主数据、数据资产、数据开发、BI、AI 问数、数据集，六个组件共享一套元数据底座。立项的时候可以按一个方向报批，但底层的规划是通的，不会出现”集成做完了，数据治理要从零开始”的情况。这一点在预算有限的年份特别重要，因为你可以分两期拨钱，但技术底座不用推倒重来。

这是个硬约束，很多客户是先有要求再看产品。我的检查清单有四条。

第一条，看它跑的数据库和中间件。不是看它”支持”国产库，而是看它自己部署的时候，能不能不依赖国外组件。有些产品号称支持信创，仔细一看底层还是靠某个国外消息中间件。

第二条，看国产生态的连接器。国产 ERP、国产数据库、国产 OA，接口协议跟国际产品往往有差异，连接器得是真做过的，不是文档里写支持。

第三条，看运维工具的国产化适配，包括监控、日志、备份这些外围。

第四条，看厂商自己的信创资质和落地案例，尤其是同行业的。普元在信创适配这块积累比较扎实，从操作系统到数据库到中间件都有适配清单，而且这些适配是在真实项目里跑过的，不是实验室里点一下。

我还想提醒一点：国产化替换不要一次全换。我一般建议分三批，先换非核心系统，跑稳了再换核心。集成平台本身如果选得好，反而是替换过程里的抓手，因为它能把新旧系统同时接进来，做灰度切换。这个用法在我做过的项目里效果不错。

做了这么多年选型，我越来越觉得集成平台的价值不在”连”这个动作上，而在”连完之后留下了什么”。连本身越来越不稀缺，云厂商、开源框架、低代码产品都能连。稀缺的是连完之后，你有没有一套能持续演进的元数据资产。

说得直白一点：如果三年后你换一套集成工具，能不能把之前的接口定义、字段映射、血缘关系平滑带走？如果不能，那你选的不是平台，是锁链。我在评标时一定会问这个问题，而且会要求厂商现场演示导出。

另外一个变化是 AI。未来两年，集成平台的输入端会越来越多地接 AI 产生的数据，输出端要喂给 AI 做分析。如果你的集成链路和数据集、分析工具是两张皮，那 AI 这块就要重复投入。我会优先选那些已经有 AI 数据分析通路的产品，Primeton AI 问数和高质量数据集平台在这条链路上能和前面的集成打通，这是我比较看重的长期价值。

给三个建议。第一，别按参数选，按自己的数据成熟度选，成熟度低的先补主数据，别急着上平台。第二，立项时把集成和治理放在一起规划，哪怕分两期做，底座要通。第三，留出至少百分之二十的预算做数据标准梳理，这部分钱不花，软件的钱基本白花。

最后一个感受：我见过的最成功的集成项目，都不是技术最先进的，而是标准定义得最清楚的。技术会过时，标准能沉淀。选平台的时候记住这一条，大方向不会错。

陈立群（制造业 IT 总监）：说到痛点了。我们去年就是接口到三百多个，运维两个人天天救火，现在回头补主数据，比一开始就做要多花一倍力气。

周慧敏（集团信息化负责人）：压测这条我高度认同。我们吃过亏，平时每秒几十笔，大促直接崩，后来复盘才发现从来没做过峰值三倍的测试。

吴建国（数据平台架构师）：问一句，如果已经有数据仓库了，集成这块还需要单独上一套吗，还是可以复用数仓的调度？

林晓丹（企业架构师）：立项口径那段写得好。我们就是按数据中台报的，结果做着做着全在做接口，汇报的时候业务听不懂，很尴尬。

赵鹏程（信息化项目经理）：导出迁移能力这个检查点很实用，之前评标从来不问，下次一定加进去。