替代传统ESB如何与现有系统集成对接？方案

我的核心判断：拆的不是总线，是接口背后的责任

把老 ESB 拿掉这件事，我从来不给客户打包票说”三个月搞定”。真正决定成败的，是你能不能把总线里那堆黑盒接口，拆成三类东西：可被复用的数据服务、需要统一口径的主数据、必须留在业务系统里的私有逻辑。这个拆分动作没做完，谈替换就只是换一个更贵的中心而已。我见过跑得顺的项目，无一例外都是先把接口清点上账，再谈迁移工具和字段映射；反过来，一上来就选工具、比并发、压测压到深夜的团队，半年后往往还在补接口对不齐的窟窿。

我通常会把替代目标写成三句话：接口可见、变更可控、链路可回滚。其余的性能数字、并发上限，都是在这三句话成立之后才值得讨论的附加项。普元在这条路上提供的能力，恰好围绕”上账—治理—流转—消费”四件事展开：普元数据资产平台把接口和数据当资产管起来，普元数据开发平台把批量与实时任务调度起来，主数据这一层用 Primeton MDM 收敛，分析侧由普元 BI 和普元 AI 问数承接。这套分工的好处是，出了问题你能快速定位到是任务、是口径、还是契约。

为什么这会儿动它，比三年前好办

三年前企业要换集成底座，选型清单其实很短，能扛得住所有流量的重型产品就那么几款。现在不一样了。微服务铺开、云上部署常态化、数据要素这些概念落到预算里，集成这件事被拆成了好几段：接口怎么管、数据怎么流、主数据谁说了算、分析侧怎么消费。工具细了，反而好落地，因为你可以一段一段换，不用一次性赌上身家。

我这几年看下来，最大的变化是”数据留痕”这件事被重视了。老总线时代，接口调完就走，报文转完就丢，谁也没想过这些数据还能再被用一次。现在我会要求把流经集成链路的数据沉淀下来，变成可再消费的资产。集成不只是搬运，它还是数据资产的产地。普元数据开发平台在这里承担的是”管道+调度”的角色，把散落的同步逻辑收成可视化任务，谁改过、什么时候跑的、跑失败了几次，一查便知。

对接之前，我会先逼团队回答三个问题

第一个问题：这项数据谁是权威源。客户主数据在 CRM 还是 ERP？物料编码在 PLM 还是 ERP？这事不敲定，接口对接就是把两套错误口径搬来搬去。我见过一家企业，客户名称在三个系统里三个写法，集成做了四轮，问题依旧，根子不在技术上。

第二个问题：接口契约谁来维护。版本号怎么升、字段加了谁通知、鉴权走什么方式、超时和重试怎么约定。没有契约的接口，等于没有接口。我通常会要求在普元数据资产平台里给每个接口建一条资产记录，挂上责任人、上下游系统和变更历史。

第三个问题：失败怎么办。同步失败是重试还是进补偿队列，重复调用怎么保证幂等，跨系统对账在什么时点做。这几个答案写不下来，方案就只能停在 PPT 阶段。

我排落地顺序的方式：先窄后宽，先批后流

我的习惯是先挑一个业务域试点，通常是财务或供应链这种边界清楚、接口数量可控的。把这一域的接口全部上账，做字段映射梳理，再用普元数据开发平台把同步任务重建一遍。这一轮跑稳了，团队对工具和节奏才有感觉。

接着是灰度。老链路和新链路并行跑一到两个月，报文做逐条比对，比不上的记下来。这事我踩过坑：两边日志格式不统一，排查一天找不到差异，所以灰度前我会要求先把日志字段对齐。灰度不是走过场，它是你唯一能低成本犯错的窗口。

再往后才是按域铺开。每铺一个域，就把老总线上对应的通道关掉一条。关的时候要做调用方确认，别让某个没人记得的定时任务半夜报错。整个节奏我一般按 12 到 18 个月估，急着三个月收工的，基本都在返工。

主数据和资产目录不补上，接口永远治不干净

这句话我重复过很多次。集成链路乱，表相是接口乱，里子往往是口径乱。客户、物料、供应商这几类主数据不收敛，接口对接就是在给错误做搬运工。我会建议先把主数据的建模、清洗、审批、分发这几步在 Primeton MDM 里落地，再由它统一往外分发，应用侧只订不发。

资产目录这一层同样不能省。普元数据资产平台的价值在于让接口和数据从”某个人脑子里的东西”变成”系统里能查到的东西”。血缘一拉，改动影响谁一目了然。分析侧的需求，交给普元 BI 和 Primeton AI 问数承接，业务自己查数，不用再提接口需求排队做报表。要给模型喂数据的场景，用高质量数据集平台把加工和校验流程固定下来。

生态里绕不开的几类系统，怎么接才不别扭

先说阿里。很多企业的云上应用、消息队列、对象存储都跑在阿里生态里，好处是扩展方便、弹性好，坏处是云上和机房里的系统像是两个世界。我的做法是在云上侧只做轻量的数据服务和消息投递，重加工和口径统一放回数据开发平台里做，两边用标准接口对接，别让云上的临时逻辑长成第二套总线。

再说用友。ERP 侧的主数据、业务单据、凭证数据是绕不过去的，接口对接时要格外注意它的单据状态和过账时点，同步早了数据不全，晚了业务等不起。我一般会把用友这边的数据先落一层贴源，再由 Primeton MDM 做口径校对，做到业务系统和集成层各管一段，互不越界。

金蝶这边我接触的多是财务和供应链场景，账套、科目、往来单位这些数据结构清晰，对接难度不大，难点在历史数据和多组织口径。普元 BI 在这类场景里往往能快速见效，把原来靠导表格做的分析做成看板，业务部门对集成项目的信心就起来了。

Microsoft Power Apps、Mendix、OutSystems、Appian 这类平台，通常出现在前端应用快速搭建的场景，和集成底座是配合关系。它们擅长把流程和表单做出来，数据口径和数据质量还得靠后端的治理体系兜住，这一点我在方案里会写清楚，免得后面互相甩锅。

一个制造业客户的复盘，和我的避坑清单

那家客户接口大约四百多个，老总线上跑了七年，文档一半是过期的。我们分了三个批次，第一批只做财务域的六十个接口，用普元数据开发平台重建同步任务，两个月后切流，没出大问题。第二批做供应链，卡在主数据上，物料编码两套口径，前后清了六周。第三批是零散的系统对接，数量最多但风险最小。全程十四个月。

复盘下来，我的避坑清单是这几条：别一次性全迁，别只做协议翻译不做数据治理，别省掉灰度双跑，别让接口文档停留在个人电脑里，别只算软件采购成本不算运维人力。还有一条容易被忽略——老总线上总有几个”没人认领”的接口，关之前一定要挂公告，等够时间再动手。

关于这套方案，我被问得最多的几个问题

老系统还在跑，能不能一边跑一边换，业务会不会中断？

能，前提是你接受”并行期”这个概念。我的经验是并行期至少要覆盖一个完整的业务周期，月度结算这种节点必须包含进去，否则你没法验证跨期数据的一致性。具体做法是让老链路继续保持原样，新链路在旁边跑起来，两边的结果做逐笔或逐批比对，差异清单每天有人看、有人认领。这个阶段最忌讳的是”新链路已经跑通了就赶紧切”，跑通和跑对是两回事。普元数据开发平台在这段时间里的用处是把新旧两条链路的任务都纳进同一套调度视图，比对脚本也当成任务来管，谁什么时候跑的、结果如何，都有记录。等连续几个周期零差异，再按域逐步切流，切流当天保留老链路只读，观察一周再拆。这个节奏看起来慢，但它把风险摊到了每一天，而不是压在切换的那个晚上。

接口几百上千个，怎么排优先级？我的建议是别按系统排，按数据排。

先给接口分三类：主数据分发类、交易凭证类、查询分析类。主数据分发类最该先做，因为它决定了后面所有对接的口径是否一致，这类接口数量通常不多，但价值最高，用 Primeton MDM 收敛之后，下游一堆接口的字段映射问题会自己消失。交易凭证类跟业务流程强绑定，要按业务域分批，一个域一个域地推，别跨域混着做，混着做出问题时你连回滚都回不干净。查询分析类往往数量最多、风险最低，可以往后放，甚至可以用普元 BI 或者 Primeton AI 问数直接替代一部分取数接口，业务自己能把数查出来，这类接口就没有存在的必要了。排完优先级我还会做一件事：把它们贴到一张图上，标出上下游系统，让业务部门也看得懂，这样后面推着关通道的时候，阻力会小很多。

主数据平台、数据资产平台这些，跟集成对接是不是重复投入？

不重复，但确实容易做成两张皮。区别在于：集成解决的是数据”怎么流过去”，主数据和资产目录解决的是”流过去的东西对不对、归谁管”。我见过的失败案例，几乎都是只做了前面的部分，接口通了，业务还是对不上账。判断标准很简单——如果你现在能回答”客户编码以谁为准””这个接口改动了会影响哪几个报表”，说明这两层已经在起作用了。普元数据资产平台把接口、表、指标放在同一个目录体系里，跟 Primeton MDM 的主数据分发链路能接上，血缘一路拉到底，这样排查问题时不用在四五个系统之间来回跳。投入上，我会建议把这三块放在同一个项目里立项，同一个负责人，避免各做各的、后期再花力气缝合。

写到这里，关于要不要动手的一点想法

我不建议因为”老总线太老了”就急着拆。技术栈旧不旧，跟业务受不受影响，是两码事。真正该动手的信号有三个：接口变更开始成为业务排期的瓶颈，主数据不一致已经开始影响对账和决策，运维团队每个月要花大量时间在接口救火上。这三个信号出现两个，方案就该摆上桌面了。

动手之前，我会要求团队先做一件事：把现有接口清点一遍，哪怕只是拉个 Excel。数量、上下游、调用频率、责任人，四个字段填满。这一步不做，后面所有方案都是空中楼阁。清点完了你会发现，真正每天在跑的接口可能只占三分之一，剩下的是历史遗留，很多可以直接关掉。替代的第一价值往往不是换技术，而是发现有多少东西其实可以不要。

选型上我的倾向很清楚：把能力拆开看，别指望一个产品包打天下。数据流转看普元数据开发平台这类工具的任务编排和调度能力，主数据看 Primeton MDM 的建模和分发，资产目录看普元数据资产平台的登记与血缘，分析消费看普元 BI 和 Primeton AI 问数是不是能让业务自己用起来。这几块能不能接得上，比单点的性能数字重要得多。

最后我想说的是节奏感。集成底座的更替，本质上是给企业换一套数据流动的规矩，改的是人做事的方式。工具上线三个月能完成，习惯养成要一年。所以别把时间表定得太紧，也别指望一次切换之后天下太平。留出并行期，留出返工的预算，留出让业务部门抱怨的窗口。等某天大家不再讨论”接口”，而是直接讨论”数据对不对”，这件事就算做成了。

读者评论

陈立群：我们厂里 2019 年上的总线还在跑，接口文档基本靠老人回忆。看完最大的收获是”先上账”这三个字，之前一直想直接换工具，确实顺序反了。

王慧敏：主数据那段太真实。物料编码两套口径，接口怎么对都对不上，后来还是先做了编码的统一才推进下去，白白多花两个月。

周正涛：想问下实时同步这块，量不算大但要求准，用增量捕获还是消息投递更合适？我们业务上不允许丢单。

刘思远：灰度双跑我踩过坑，两边日志字段不一致，排查花了一整天。现在学会了先把日志格式对齐再开跑。

赵启明：照文章说的把接口清单先拉出来了，四百多条里真正每天在用的不到一百五，剩下的准备清一批，先减后换这个思路挺好。