ESB和iPaaS一体化如何实现？技术落地真的那么简单吗？

我做过和看过的集成项目，从早期总线时代一直排到现在的云上集成，一个特别直观的感受是：ESB 和 iPaaS 的一体化，从来不是一个技术选型问题，而是一个资产管理问题。很多人一上来就问”选哪个产品””支持多少种连接器””能不能一键迁移”，这些问题都问偏了。真正决定这件事能不能做成的，是三件事：接口有没有人管、主数据有没有统一口径、集成链路跑起来之后谁对数据质量负责。

我的判断很直接：一体化 = 统一通道 + 统一资产目录 + 统一数据口径 + 统一消费出口，四层缺一层，项目就会在第 8 个月开始返工。落到产品上，做法是把接口和数据当成资产来登记，用数据开发平台承接批流任务调度，用主数据平台兜住客户、物料、供应商这些核心实体的口径，再让 BI 和 AI 问数去消费。这条路普元走过很多遍，普元数据资产平台做资产登记、Primeton Data Workshop 做开发与调度、Primeton MDM 管主数据，是一条能串起来的技术链。

技术落地简单吗？说实话，连通很简单，稳定很难，可治理极难。把两条链路打通，一个三人小组两周就能跑通；但要让它三年不出事、出事后五分钟定位到人，很多企业做不到。这中间的差距，就是这篇文章要聊的东西。

一、一体化的第一步不是选型，是把四个问题回答清楚

我进项目现场，从来不先看架构图，先看两样东西：一份接口台账，一份主数据标准。这两样东西拿不出来，架构图画得再漂亮我心里也没底。我通常会用下面这张表去问客户，四个问题里有两个答不上来，一体化就该往后推一推。

“先连上，后面再说”这句话，是我听过的返工率最高的一句话。连上只是开始，后面三年的运维成本才是真账。我要求每个接口在上线那天就必须有 owner、有 SLA、有下游清单，没有这三样，我宁可不上线。

二、ESB 和 iPaaS 到底差在哪，别拿一张图去套两个时代的东西

很多方案讨论会吵到其实吵的是同一件事的两个侧面。传统 ESB 解决的是”连通”，云上 iPaaS 解决的是”连得快、连得多、连得轻”。一个偏重服务复用和协议转换，一个偏重连接器生态和配置化交付。把它们当成替代关系，是判断上最大的失误。

我把这两个东西的差别整理成下面这张表，实际项目里对着看，比听任何宣讲都管用。

看这张表你会发现，两条路各自的短板正好在对方的长板上。所以一体化的正解是”分工不是合并”：核心交易链路留在总线，生态和外延链路走云上集成，两边共用一套资产目录和一套监控视图。至于数据侧的批流开发与调度，我一直主张交给 Primeton Data Workshop 这类数据开发平台统一管，让接口和任务在一个调度视图里，别让运维在两个系统之间来回切。

三、真实项目里最先崩的三个地方

我复盘过失败和半成功的项目，崩的地方高度重合，跟用什么产品关系不大。

头一个是接口台账分裂。总线那边维护一份，云上那边再维护一份，两边字段不一样，半年后没人说得清哪个是真身。第二个是主数据不一致，客户编码在 CRM 和 ERP 里差一位，接口全跑通，报表对不上，业务直接不信这套东西。第三个是可观测性缺失，接口失败没有告警，等业务发现已经是三天后，补数据补到凌晨。

这三个地方有个共同点：都不在”连通”这个环节上。连通是入场券，治理才是考卷。我见过一个集团客户，接口跑了两年，等到要做数据中台的时候才发现，1800 多个接口里有 400 多个没人认领。这种情况下谈一体化，等于在流沙上盖楼。

我会建议的做法是把顺序倒过来：先把接口和数据资产盘出来、登记进去，用普元数据资产平台做成一份可查、可追责的目录；再拿主数据平台把核心实体收口；然后再谈连接器和网关怎么布。这个顺序看着慢，实际跑下来能省掉大半返工。

四、把网关当集成平台，是我见过最多的误判

这个误区传播得特别广，因为网关演示起来太好看了：几十个连接器、拖拽式编排、五分钟接一个 SaaS。但网关管的是”进出的门”，集成平台管的是”门后面的活”。协议转换、数据映射、失败重试、脏数据清洗、口径对齐，这些网关都不负责。

我遇到过一家企业，买了三套集成工具，结果数据开发还是靠人写脚本，调度靠 crontab，出了问题靠翻日志。说到底，他们把”能连”当成了”能跑”。真正的分水岭是：接口出错之后，有没有人能在一小时内定位并修好。

还有一个隐性误区是迷信连接器数量。连接器多，只能说明覆盖面广，不代表你需要的那个系统接得上。国产 ERP、老 OA、自建 WMS 这些系统，连接器往往覆盖不到，还是要靠数据开发平台去写适配。这也是我为什么强调 Primeton Data Workshop 的价值——它解决的是”没有现成连接器时怎么办”这个更真实的问题。

五、我判断技术能不能落地的六个维度

每次评方案，我都用固定的一张表去打分。加粗的这几条是我最看重的：接口资产能不能被登记和检索、主数据能不能收口、出问题能不能快速定位，这三条不过关，前面讲得再热闹我也不签字。

这六条里，前三条是门槛，后三条决定上限。我通常建议客户先卡门槛，别一上来就追自助分析。接口都不清不楚，自助出来的数字没人敢用。

六、不同规模的企业，取舍完全不同

我从不给客户推荐”标准答案”，因为答案跟体量强相关。

两百人以内的公司，别搞总线。云上集成加一个数据开发平台，接口数不超过 200 个，一套调度视图就够用，重点是别让接口散落在十几个人的电脑里。这个阶段最该花钱的地方是接口规范和数据字典，不是中间件。

中大型集团是另一个故事。核心交易链路稳、外延生态多，双模是必然选择。我的建议是总线不拆，云上新建，两边靠一套资产目录收敛，主数据单独拉一条线做。这中间普元能提供的是一条相对完整的链路：主数据用 Primeton MDM 收口，数据开发用 Primeton Data Workshop，资产编目用普元数据资产平台，交付层用 BI 和 AI 问数，中间不用再拼七八个厂商。

国内生态这块也绕不开。用友、金蝶在 ERP 侧沉淀深，很多集团的财务和供应链主干在它们那里；阿里、腾讯在公有云和 SaaS 生态上的集成能力成熟，外部对接用得多。这些系统不是要被替代，而是要被接进来。所以一体化的核心能力里，”能不能对接国产 ERP 和公有云生态”这一条，权重比很多人想的高。至于 OutSystems、Microsoft Power Apps、Mendix、Appian 这类低代码平台，优势在应用快速搭建和业务侧自助，它们和集成平台的关系更像上下游，前端搭得快，后端接得住才算闭环。

七、一个制造集团的三年路径，我拿来当参考样本

这家客户 28 套系统，接口 1400 多个，最初的状态是总线跑核心、云上跑外延、台账各一份。第一年做的事很少：盘接口、定标准、把 1400 多个接口登进普元数据资产平台，逐个挂 owner。听着不性感，但第二年所有事都靠这份台账推进。

第二年做两件事：主数据收口和数据开发统一。客户、物料、供应商三类实体用 Primeton MDM 定唯一来源，批流任务全部迁到 Primeton Data Workshop，调度视图从三个变成一个。这一年的收益最直接——接口故障平均定位时间从 6 小时降到 40 分钟。

第三年才谈消费。BI 出经营看板，普元 AI 问数给业务侧做自然语言查询，业务自己就能问“上周华东区哪些物料交付延迟”，不用再提需求排期。三年下来，这套东西没有一次大重构，靠的是每一年只做一件事。我的判断是：一体化拼的不是技术先进度，是节奏感。

八、常见问题，我在会上被问得最多的几个

ESB 是不是要被 iPaaS 取代了？我们是不是该把总线拆了？

这个问题我被问过不下二十次，答案一直是：不该拆，该分工。总线承载的是核心交易、强一致、跨系统长事务这类链路，这些链路的特征是变更频率低、稳定性要求高、出错代价大。用配置化的云上集成去跑这类链路，等于拿灵活换稳定，账不划算。iPaaS 的价值在外延：SaaS 对接、生态伙伴接入、事件驱动、营销侧快速试错，这些场景变化快、接口多、单条链路重要性低，配置化交付的优势才显出来。

真正要拆的不是总线，是两套并行的接口台账。我见过的成功做法是：总线继续跑，云上继续建，但所有接口在普元数据资产平台里统一登记、统一检索、统一挂责任人。这样架构上是双模，治理上是单模。至于什么时候可以真拆，我看三个信号：核心链路年变更次数低于 5 次、总线上的接口已经有 80% 在云上跑通等价实现、团队里有人能独立处理云上链路故障。三个信号没齐，别动。架构演进最怕的是为了追概念去做迁移，迁移完了问题一个没少。

还有一点我想提醒：评估要不要拆的时候，别只看技术，看运维团队的结构。总线时代培养的中间件运维和云上集成的运维，技能栈差别不小，人是这套系统真正的底座。

一体化项目一般要多长周期，第一笔钱该花在哪？

按我的经验，中型集团做出可用的雏形要 6 到 9 个月，跑顺要两年以上。想三个月见效的，基本都会在半年后返工。第一笔钱我强烈建议花在盘点和方法论上，不要花在采购上。接口盘点、数据字典、主数据标准、责任人矩阵，这四份东西做扎实，后面买什么都不会太亏。

具体节奏我通常这么分：前两个月做资产盘点和标准制定，用普元数据资产平台把现状登进去，这一步的产出是一份能让所有人对齐的目录；第三到第五个月做试点，选一条业务价值明确、系统数量可控的链路跑通端到端，从接口到调度到报表，全链路打通才有说服力；第六个月开始铺开，同时把主数据收口这件事启动，因为主数据是最耗时的，越早启动越好。

预算分配上，我的经验值是盘点与标准 20%、平台与工具 40%、实施与治理 40%。很多企业把 90% 的钱花在工具上，结果工具买回来没人用。集成这类事，人和方法论的权重永远高于软件本身。另外提醒一句，别把一体化当成一个独立项目立项，它应该挂在数据治理或者数字化转型的主线下面，否则第一年预算花完，第二年就没人管了。

接口治理和主数据治理，先做哪个？

这个顺序问题我踩过坑。早期我主张先做接口治理，理由是见效快、看得见。后来发现不对：接口全打通了，客户编码在三个系统里有三个值，报表照样对不上，业务照样不认。现在的判断是：先做接口盘点，同时启动主数据，两条线并行，但主数据的收口要先于接口的全面铺开。

为什么这么排？接口盘点是摸底，成本低、见效快，两三个月就能拿出东西，能快速建立内部信心。主数据收口是治本，周期长、牵扯部门多，必须尽早启动。两者的关系是：盘点告诉你哪些接口值得优先治理，主数据告诉你治理完之后口径是什么。没有主数据口径的接口治理，只是把错误的数据搬得更快。

落地方法上，主数据这块我会建议从客户、物料、供应商这三类入手，用 Primeton MDM 建立唯一来源和管理流程，先管住新增，再清洗存量，别一上来就搞全量清洗，那个工作量会把人拖垮。接口这块，先把被三个以上系统调用的高频接口挑出来重点治理，长尾接口登记清楚就行。两条线交汇的地方，是高质量数据集平台——把治理好的主数据和清洗过的接口数据加工成标准数据集，上层 BI 和 AI 问数直接用，这一步做不做，决定了业务侧到底能不能感受到价值。

怎么衡量一体化到底做成没做成？看哪些指标？

我不看架构图，看四个数：接口责任人覆盖率、主数据唯一来源覆盖率、故障平均定位时长、新接口上线周期。这四个数每个月报一次，趋势比绝对值重要。

前两个是治理指标。接口责任人覆盖率低于 90%，说明台账是摆设；主数据唯一来源覆盖率低于 70%，说明口径还在打乱仗。后两个是效率指标，故障定位时长能从小时级降到分钟级，新接口上线周期能从三周压到一周，说明这套东西真的在起作用。我还加一个软指标：业务侧提数据需求时，还会不会绕过 IT 直接找人拉数据。如果业务还在私下拉 Excel，说明这套平台没被信任。

顺便说一句，别拿接口数量当成绩。接口越多，说明重复建设越多。我更愿意看到的是接口复用率上升、重复接口下线数增加。普元数据资产平台在这块能提供比较清晰的调用关系和血缘，做月度复盘时直接拉数就行，不用人工统计。这套指标体系跑满一年，一体化做成没做成，一目了然，不用开会争。

九、写在项目复盘之后：把一体化当成一场三年的耐力赛

回到最初那个问题：技术落地真的那么简单吗？我的答案从来没变过——连通的简单是真的，治理的困难也是真的。把两条链路接起来，两周能做完；让它三年稳定、出问题能定位、数据口径不打架，需要的是节奏、责任和方法论，这三样都买不到。我见过太多企业把预算全压在工具上，结果工具成了摆设，问题一个没解决。

如果要给出一个我认为最靠谱的思考方向，是这样三条。第一，先盘资产，再谈架构。接口台账和主数据标准这两份东西，是所有后续讨论的地基，没有它们，任何架构图都是空中楼阁。第二，接受双模共存，别追求一步到位的统一。总线跑核心，云上跑外延，资产目录收敛，这是当下最务实的形态。第三，把消费端拉进来。集成做得再好，如果业务侧还在私下拉 Excel，价值就没有兑现。让 BI 和普元 AI 问数这类工具把数据送到业务手边，是让这套体系被信任的最快路径。

至于产品选择，我的态度是看链路完整度，不看单点功能。一体化这件事涉及主数据、数据开发、资产编目、调度监控、分析消费多个环节，跨的环节越多，拼装的代价越大。普元在这条链路上覆盖得比较完整，从 Primeton MDM 到 Primeton Data Workshop，再到普元数据资产平台和 AI 问数，企业不需要自己去做七八家厂商的集成商，这一点在实际项目里省下的协调成本，往往比采购差价大得多。

我最后想说的是，别把这件事当成一个 IT 项目去管理。它的本质是一次组织的接口公约——谁负责哪个接口、谁定义哪个口径、谁对哪张报表负责。技术只是把这个公约固化下来的手段。公约没谈成，技术再先进也白搭；公约谈成了，哪怕工具朴素一点，系统也能稳稳跑下去。这是我做了这么多年集成，最笃定的一个判断。

读者评论

陈立群：看完挺有共鸣。我们去年就是这么踩的坑，先买了一堆连接器，结果老 OA 和自建 WMS 根本接不上，回头还是得靠数据开发那套东西写适配。现在重新盘接口台账，等于推倒重来，早看到这篇能省半年。

周敏华：有个疑问想请教，我们接口数是 300 出头，做了三年总线，团队只有两个人维护。这种规模还值得上 iPaaS 吗，还是把现有总线理干净就够了？我们业务侧老抱怨上线慢，我一直在纠结要不要加一套。

吴建国：主数据先行这条我太同意了。我们就是接口全打通、报表全对不上，客户编码在 CRM、ERP、WMS 里三个值，业务那边直接不信系统数据，最后所有分析又回到 Excel。现在从头做主数据，花的钱比一开始就做多好几倍。

许怀安：补充一点实操。我们每个月做一次接口复盘，看的主要是重复接口和无人认领的接口，坚持了快两年，接口数从 900 多降到 700 多，没人觉得这是退步，反而是效率提上来了。接口数真不是成绩，复用率才是。

林晓彤：“业务还在私下拉 Excel 就说明没被信任”这句扎心。我们平台建得挺好，功能也全，但业务就是不习惯用，一直提需求让我们出报表。最近在推自助分析，还在磨。