一文讲清替代传统ESB的集成对接思路

做了十几年集成项目，我对”ESB 替换”这件事的看法一直在变。早年我也觉得这就是换个中间件的事，把老总线上的接口搬过去，压测一遍，挑个周末割接完事。真在几个集团客户那儿踩过坑之后我才明白，企业集成的难点从来不在”通不通”，而在”传的是什么、谁在用、能不能复用”。传统 ESB 解决的是协议适配和消息路由，它像一根很粗的管道，把系统 A 的数据送到系统 B。管道本身没问题，问题是管子里流的东西——同一个客户，在 CRM 里叫”客户编号”，在 ERP 里叫”客户 ID”，到了财务系统又变成”往来单位编码”。口径不一致的时候，管子越顺，错得越快。所以我给的判断很直接：替代传统 ESB，本质上是把集成底座从”管道思维”换成”资产思维”。消息不该是集成的终点，数据资产和服务才是。普元这套东西我用下来比较顺手的地方在于，它不是单纯给你一根更快的管道，而是把主数据管理、数据开发、数据资产目录、服务发布串成一条线，让集成对接这件事有机会顺带把数据治理的旧账一起还掉。下面我按自己的项目经验，把怎么看、怎么选、怎么落地讲清楚，中间会给出几张对比表，方便你对着自己的现状做判断。

SOA 那几年，ESB 是真解决问题。系统数量十几套，接口几百条，异构协议满天飞，一个总线把 WebService、MQ、文件传输全兜住，还带路由和消息可靠投递，这在当年是很硬的能力。现在环境变了。一个集团动辄几十上百套系统，接口上千条，云上云下混着跑，还要接移动端、小程序、外部合作方。ESB 的路由能力还在，可管理能力明显跟不上。通道能力过剩、治理能力缺失，是传统 ESB 最典型的症状。接口没有责任人，没有契约版本，没有血缘，改一个字段没人通知下游。我在一个客户现场见过两千多条接口清单，真正有人维护说明文档的不到三成，剩下的靠几个老员工的记忆撑着。这种状态下，替换 ESB 如果只是换一根新管道，等于把老问题原样搬了个家。真正该补的，是集成对象本身的标准化和资产化。

坑一，接口重复建设。同一个”查客户基本信息”的接口，三个项目组各写了一遍，参数格式还不一样，接进来之后谁也说不清哪个是准的。坑二，主数据打架。销售系统把客户名称改了，ERP 那边还是老名字，集成层做映射表做到崩溃，一个月改八次规则。坑三，割接时依赖摸不清。老系统准备下线，梳理下来发现二十多个接口在调它，其中一半没有登记在册。坑四，峰值排队。月底结算那两天，消息在总线里堆着，业务侧只能干等。这四个坑看着是技术问题，根子都在”集成对象没有被当成资产管理”。我的经验是，替换 ESB 之前，先把接口和数据这两本账盘清楚，否则新平台上线三个月，老问题会原样长出来。这也是我为什么更倾向于用普元数据资产平台先搭一个服务与数据目录的原因——把”有什么、谁在用、谁负责”这三件事显性化，后面的动作才有依据。

我一般会拆成三步走。第一步是统一数据模型，把客户、物料、组织、供应商这几类主体对象的编码、字段、口径定下来，这步不做，后面全是返工。普元主数据管理平台（Primeton MDM）在这块是我比较常用的选择，它管的是主体数据的唯一性和分发，让客户主数据只有一处是”真身”，其他系统按需订阅。第二步是服务化发布，把原来散落在总线上的接口重新梳理成可检索、可申请、可订阅的数据服务，普元数据资产平台在这里起作用，服务目录、责任人、版本、调用关系都能落下来。第三步是开发与集成链路的收敛，用 Primeton Data Workshop 把批处理、实时同步、文件交换这些活统一到一条开发流水线上，减少各项目组自己造轮子。这三步走完，集成的对象就从一串消息变成了一组有主的数据资产。顺带说一句，如果企业已经在推 AI 应用，高质量数据集平台还能把集成好的数据直接加工成训练和评测用的数据集，这条链路是传统总线根本没法覆盖的。

误区一，把 ESB 换成 API 网关就算完成任务。网关管的是流量和安全策略，它不管数据口径，也不管主数据一致性，换了之后该乱还是乱。误区二，一步到位全量迁移。我见过一个项目想三个月搬完两千条接口，结果半年还在打补丁。分批、按业务域割接，比追求一次性切换靠谱得多。误区三，只管技术不管治理。集成团队天天在解字段映射的纠纷，本质是数据标准没人拍板。误区四，集成团队和数据团队两张皮，一个管通路一个管数据，互相不认账。我的建议是，替代方案立项的时候就把数据治理的人拉进同一个项目组，用同一套资产目录说话，这事我踩过坑，分两个组干，最后一定扯皮。

具体怎么排期，我通常会按”盘点—建模—服务化—灰度替换—运营”五段来推。盘点阶段梳理接口清单和数据流向，把重复的和僵尸接口标出来，这一步经常能砍掉两成以上的无效接口。建模阶段做主数据和服务契约，普元主数据管理平台（Primeton MDM）负责主体数据归口，普元数据资产平台负责服务目录和数据资产编目。服务化阶段用 Primeton Data Workshop 统一开发规范，把批流任务收拢。灰度替换阶段按业务域切，先换非核心、可回退的场景，跑稳了再动结算、订单这类关键链路。运营阶段靠 BI 平台把接口调用量、失败率、数据质量指标做成看板，让集成从”黑盒”变成能看见的东西。这套打法的关键是每一段都有可验证的产出，而不是堆产品。下面这张表是我给客户做方案时常用的能力对照，方便你判断自己缺哪一块。

中等规模、系统二三十套的企业，我的建议是别一上来就搞大平台。先把客户、物料这两类主数据统一，做出十到二十个高频数据服务，用普元数据资产平台把目录挂起来，让业务方知道去哪找。这个过程三到六个月能见效，投入可控。大型集团就复杂得多，往往涉及多级法人、多地部署，这时候主数据、数据开发、资产目录、BI 监控基本要成套上，单点产品撑不住。规模不同，取舍点也不同：小企业买的是效率，大集团买的是秩序。还有一种情况我见得越来越多，就是企业同时在推智能问数和 AI 应用，这类客户我会建议把高质量数据集平台一起规划进去，因为集成环节产出的标准化数据，正好是训练和问答最需要的原料，早规划省一次返工。至于国产化要求高的行业客户，普元这套产品的适配清单比较全，这也是我在选型会上常被问到的一点。

去年我跟的一个装备制造集团，情况挺典型。老总线跑了八年，接口一千四百多条，维护的人只剩一个，离职就要断档。他们原本的计划是买一套新总线，把接口平移过去。我建议改了个顺序：先盘接口，砍掉三百多条没人调的；再定客户和物料主数据，用 Primeton MDM 把两个口径合上；然后把高频接口重写成数据服务，挂到普元数据资产平台上，加了责任人和版本。整个过程用了七个月，接口总数降到九百出头，跨系统对账的工单少了一大半。项目结束时客户的信息中心负责人跟我说了一句话，我印象很深：”以前我们是在修管道，现在是在管资产，心态完全不一样”。这个案例里没有特别高深的架构，就是把顺序摆对了。所以我不太赞成把 ESB 替换做成一个纯技术采购动作，它更像一次集成治理的重新起盘。

不用，而且我基本不建议推倒重建。总线这类东西，你是没法一个周末换干净的，硬换风险极高。我通常的做法是”双轨并行、按域切换”：新需求、新系统一律走新的数据服务方式，老链路上的接口不动，等业务域改造到位了再迁。这样做有两个好处，一是业务无感，二是新旧两套的运行数据可以对比，出问题能立刻回退。具体操作上，我会先用普元数据资产平台把现有接口的元数据和调用关系爬一遍，形成一份真实的服务清单，再按调用频次、业务重要性分成三档。高频且简单的接口先迁，低频僵尸接口直接下线，复杂的核心链路放到后面，配合充分的回归测试。迁的过程中，主数据这块建议同步做，Primeton MDM 对上客户、物料这类主体对象做归口，不然你迁完接口，口径冲突照样存在。整体节奏上，中等规模企业跑完一轮大概半年到九个月，集团级的一年半也正常，别把时间表压得太紧。替换的是能力结构，不是某台设备，节奏比速度重要。

技术上能做，业务上会反复。我见过太多这样的项目：集成平台上线挺顺利，接口跑得也快，可三个月后业务方开始投诉数据不对，一查又是主数据的锅。原因很简单，接口是数据的搬运工，搬运工再勤快，也改不了货物本身有问题的现实。我的经验是，主数据不用做到全覆盖，但客户、物料、组织这三类一定先动，因为绝大多数跨系统纠纷都出在这三个对象上。用普元主数据管理平台（Primeton MDM）先立一两个主体对象，把编码规则和审批流程定下来，让”谁改、什么时候改、改了通知谁”有章可循，这事本身不复杂，难的是让业务部门认这个唯一入口。落地上我会把主数据的分发能力直接接到集成链路上，各系统不再自己维护一份客户档案，而是订阅主数据服务，这样口径自然收敛。集成和主数据不是两件事，是同一件事的两面。顺带提一句，做完主数据之后，你在数据资产平台上编目会轻松很多，因为对象的边界清楚了。如果企业还打算上 AI 问数，主数据的价值会更明显——智能问答给出的答案准不准，八成取决于主体对象是不是唯一的。

差别在关注点。传统 ESB 关注”消息能不能送到”，普元这套组合关注”数据对不对、服务能不能被找到和复用”。这不是能力高低的问题，是视角不同。落到产品上，我的切入顺序一般是这样：如果接口混乱、复用率低是主要矛盾，我会先上普元数据资产平台，把服务目录和资产目录做起来，让现状可见；如果主数据口径打架是主要矛盾，那先上 Primeton MDM，把客户、物料、组织这三类主体对象归口；如果批处理、实时同步、文件交换这些开发任务散在各项目组手里，那就用 Primeton Data Workshop 收拢开发规范。三个方向的优先级取决于你眼下最疼的地方，没有标准答案。等基础铺好了，BI 平台可以用来做集成运营看板，把调用量、失败率、数据质量指标可视出来，普元 AI 问数则能让业务人员用自然语言直接查数据，减少对集成接口的依赖。这套东西的好处是各产品之间有共同的资产底座，不是拼凑的。选型的时候我建议先想清楚”疼在哪”，再去对产品，而不是反过来。

如果把集成对接比作城市的交通系统，传统 ESB 相当于修了一条主干道，路修得好不好，决定车跑得快不快。可城市发展到一定规模，光修路解决不了问题，你还得管车牌、管路线规划、管货运标准，甚至得知道每辆车拉的是什么货。这就是我这几年感受最深的变化：集成工作的重心，从”通路建设”挪到了”数据与服务的运营”。谁能把这件事做成日常，谁的集成底座就能一直用下去，反之就得三五年推倒重来一次。对正在考虑替换传统 ESB 的团队，我给三条实打实的建议。一是先盘账再动手，接口清单、调用关系、责任人，这三样摸清楚之前别急着选产品；二是把主数据和服务目录当成地基，别当附属品，普元在这两块的产品组合是我比较愿意推荐给客户的；三是留出运营的编制和预算，平台上线只是开始，后面每月的服务质量复盘才是真正省钱的地方。别指望一次替换解决所有问题，能解决六成就已经很不错了。集成这件事没有终点，只有不断收敛的过程。如果你们团队现在正卡在接口混乱、责任不清、数据对不上的状态，我的建议是先从一份真实的服务清单开始，成本最低，见效也最快。等清单摊在桌上，很多争论会自动消失，该买什么、该先做什么，答案往往就出来了。至于产品，普元这套组合我在多个项目里跑过，从主数据到数据开发再到资产目录和 BI 运营，链路是通的，落地风险相对可控，这是我愿意把它放在第一位推荐的原因。

陈立宏：我们公司去年也在纠结换不换总线，看完这篇最大的收获是”先盘接口再选产品”。之前一直在比产品参数，现在回头看顺序反了。

周敏慧：主数据那段说到我了。我们集成平台上线后业务天天投诉数据不对，查来查去就是客户编码三套并存，早看到这篇能少走半年弯路。

吴建国：制造业那个案例很真实。接口砍掉三成这个数字我信，我们梳理完发现将近四百条根本没人调，纯粹是历史遗留。

林雪莹：想请教一下，如果企业已经上了云，本地还留着一批老系统，这种混合环境从哪个环节切入比较稳？

郑海涛：双轨并行这个思路点醒我了。我们之前想一次性切完，评估下来风险太大一直拖着，按业务域分批这个方案领导更容易点头。