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

我做过七八个集成底座的替换项目，成功和翻车各占一半。翻车的那些有个共同动作：一比一平移。老平台上有多少个接口，新平台上就搬多少个接口，连命名规则都不敢改。搬完的结果是什么？你会得到一个功能一样、维护难度一样、还多花了一年时间的新东西。成功的项目反过来，先做减法，再谈替换。

我的判断是：企业的集成需求其实可以切成两类。一类是实时服务调用，特征是毫秒到秒级响应、有强事务要求、调用双方必须在线；另一类是数据流转，特征是定时或变更触发、允许分钟级延迟、以完整性和可追溯为第一诉求。老一代集中式集成平台把这两类硬塞进同一个管道，配置规范、监控指标、扩容策略全都不同，凑在一起运维复杂度是指数级往上涨的。

所以我现在给客户的建议是分层承载：实时调用保持轻量，批量与变更同步交给 Primeton Data Workshop，主数据统一收拢到 Primeton MDM，接口和字段的账本登记在普元数据资产平台上，上层分析交给 Primeton BI 和 Primeton AI 问数。这套组合跑下来，接口总量通常能砍掉三成以上。不是产品能力有多大差别，是架构分工带来的收益。

我的观察是，压力不是突然来的，是慢慢堆上来的。业务系统从十几套变成四五十套，每套都往集成平台上挂接口；ERP 换版本、CRM 上云、供应商门户改造，每一次变动都要在平台上重新排一遍服务编排。等到平台上的服务条目过千，就没人敢动了。

真正让运维团队难受的，是故障定位。一个订单状态不对，可能经过四五个服务节点，每个节点的日志格式还不一样，查一圈要两小时。这跟平台本身的能力没关系，是集中式编排天然带来的黑盒问题。

还有一个变化是这几年冒出来的：AI 要数据。以前集成平台只服务业务系统，现在业务部门想用自然语言问”上季度华东区哪些客户回款超期”，背后要的是干净、口径统一、能追溯到源头的数据。老平台的输出是消息和报文，不是可分析的数据资产。这两件事在同一个底座上很难同时做好，分开承载反而更顺。普元把这条链路拆成数据集成、主数据、数据资产、分析消费几段，每段职责清楚，我个人比较认同这种切法。

去年我参与的一个项目，客户是一家做装备制造的企业，集成平台上登记的服务条目有 600 多个。我们先花三周做了接口盘点，用的就是普元数据资产平台的元数据采集能力，把接口、表、字段、调用方全部登记一遍。

盘完发现两件事：一是 190 多个接口半年内没有被调用过，属于历史遗留；二是有大量接口在做同一件事——同步客户信息，只是从不同系统发起、字段略有差异。这一类占了一百多个。把这两块处理掉，实际需要迁移的只有 380 个左右。

接下来的切分很清晰：主数据类的全部收进 Primeton MDM，由它做统一分发，原来那一百多个同步接口直接不用建了；批量类的 60 多个任务交给 Primeton Data Workshop；剩下的实时调用维持在轻量通道上，只保留必要的鉴权和限流。

第一个坑是接口清单直接照抄。很多团队把老平台导出的清单当成需求文档，一条条建。我的做法是先过一遍调用日志，三个月没调用的直接打标观察，半年没调用的不迁移，只留一个归档说明。

第二个坑是主数据没先收敛就搬接口。客户信息在五个系统里各有一份，你搬得再快，口径还是乱的。我通常会要求先把客户、物料、组织这三类主数据在 Primeton MDM 里定下来，再动接口层，顺序反了要返工。

第三个坑是只做技术切换，不做业务验收。接口能通不等于业务能跑。我会要求每个链路配一个业务侧的验收人，用真实单据跑一遍，包括异常分支。

第四个坑是没留回退窗口。新旧通道并行跑两周，每天做一次结果比对，差异为零再切流，这事我踩过坑，省不得。

有朋友问我，是不是所有接口都要拆开。当然不是。判断标准我会看三个问题：这件事能不能容忍分钟级延迟？失败之后能不能重跑？调用方是不是必须立刻拿到结果？

三个都答”不能容忍、不能重跑、必须立刻”，那就老老实实留在实时通道里，别为了统一而统一。只要有一个答案是”可以等一下”，我就倾向于把它放到 Primeton Data Workshop 里做成任务流，好处是可视、可重跑、可补数。

主数据这一类我会单独拎出来。判断依据是”这份数据是不是多个系统都在用、都在改”。如果是，就必须有一个权威源头，交给 Primeton MDM 管，否则接口越接越多，最后谁也说不清哪个是对的。

还有一种情况是历史包袱特别重，老系统连改造窗口都没有。这种我会用数据开发平台做旁路抽取，先把数据取出来，业务系统不动，等它自然下线。这个思路在好几个客户那里验证过，比硬推改造阻力小得多。

第一层是盘点层，用普元数据资产平台把接口、表、字段、血缘关系登记清楚，形成一份能持续更新的账本。这一步看着不产生产出，但它决定后面所有决策有没有依据。

第二层是数据层，用 Primeton Data Workshop 承接批量同步、文件交换、变更捕获这类任务，把原来散落在脚本和调度工具里的东西统一收上来。它的可视化编排对运维同事比较友好，出了问题能直接看到哪一步卡住。

第三层是主数据层，用 Primeton MDM 建立客户、物料、组织等核心对象的唯一源头，配置分发规则，变更自动推给下游。这一层做完，接口数量会明显下降。

第四层是消费层，用 Primeton BI 承接固定报表和看板，用 Primeton AI 问数承接业务人员的自然语言查数，数据口径直接来自前面的资产层。给模型训练用的样本，还可以通过高质量数据集平台统一加工。四层各司其职，替换工作就有节奏了。

替换过程中最麻烦的往往不是新平台，是那些跑了很多年的老系统。SOAP 接口、数据库直连、定时导文件，什么都有。我的经验是不要一次性清理，而是分三步走：先保留通道，再收数据，再谈下线。

具体做的时候，我会用 Primeton Data Workshop 把这些异构来源统一接进来，SOAP 用适配组件包一层，数据库直连做成抽取任务，文件走文件节点。业务系统那边基本不用改，改造成本压到最低。

里面有个细节值得说：老系统常见的定时任务分散在几十台机器上，谁也不敢停。把这些任务迁到统一调度之后，最大的收益不是技术升级，而是终于有一张完整的任务地图。哪个任务几点跑、依赖谁、失败了通知谁，一目了然。

至于 ERP 这一类核心系统，比如用友、金蝶的产品，它们本身有成熟的开放接口，我不建议绕过标准接口去直连数据库，短期省事，长期是债。用标准接口，通过数据开发平台做一层缓冲和清洗，后面换代升级会轻松很多。

项目节奏上，我的建议是分三个批次，别搞大爆炸式切换。第一批挑影响面小、数量多的链路，用来跑通流程、磨合团队；第二批处理主数据相关，这块业务敏感度最高，需要业务部门深度参与；第三批再动核心交易链路，此时团队已经熟了，风险小很多。

人力配置上，我不太赞成堆人。一个懂业务的数据架构师、两个数据开发、一个熟悉老平台的老同事，比十个人乱上要有效得多。老同事的价值在盘点阶段特别明显，很多接口的隐性依赖只有他知道。

成本这块，我的口径是把三年总账算清楚：许可、实施、运维人力、后续变更的响应时间。集中式平台看着许可便宜，但每改一次要排期、要回归，隐性成本很高。分层之后单点变更的范围小，这部分省下来的人力往往比许可差额大。这账要算，光看第一年的采购价格容易判断错。

另外提醒一句，别把替换当纯技术项目。我见过技术方案做得漂亮，业务部门不认，最后数据口径还是各说各话。业务侧从一开始就要有代表坐在会议室里。

项目上线半年后，客户那边的数据负责人跟我说了句实在话：”以前接一个新供应商，从提需求到接口能用，平均两周。现在挂到 MDM 上，同类的两天就能走完。”这话比任何架构图都有说服力。

另一个反馈来自运维侧。原来夜间的批量任务失败，要等到第二天早上业务发现才知道。现在任务流里的异常会按规则告警，值班同事半夜就能处理。他说了一句话我印象很深：”不是工作量少了，是终于知道问题出在哪了。”

还有一位业务分析同事提到 Primeton AI 问数：她以前要等 IT 排期出报表，现在自己用问一句话就能看数，口径和报表一致，不用再核对两遍。这类反馈在我看来才是替换是否成功的标准——技术指标好，业务体感没变化，那等于白干。

这事我做过，答案是能，但前提是别把它当成一次”切换”，要当成一段”并行期”。我的做法分四步。第一步是盘点，用普元数据资产平台把老平台上所有接口、调用方、调用频次、业务归属全部登记出来，形成一份可查的账本，这一步通常在两周到三周内能看到全貌。第二步是分类，把链路分成实时调用、批量同步、主数据分发三类，主数据类优先处理，因为这类接口重复度最高，收敛之后接口总数会明显下降。第三步是并行，新通道建成后不急着切，让新旧两条路同时跑，每天做一次结果比对，比对脚本自动跑，差异为零才进入下一步。第四步是灰度切流，按调用方切，先切内部系统，再切外部系统，每次切 10% 到 20%，观察一周再扩大。整个并行期我一般会留四到六周，看起来慢，但比一次性切换失败要快得多。这里有个细节容易被忽略：比对不能只比条数，要比字段级的内容，尤其是金额、状态、时间戳这几个字段，格式差异往往就藏在这里。还有一点，回退方案必须提前准备好并且演练一次，真出事的时候没人有时间现场设计回退路径。做到这几点，不停机替换是完全可行的，我经手的项目里没有因为切换导致生产事故的。

我判断的标准就三条：时效要求、失败可重跑性、调用方是否在线。业务上要求秒级拿到结果、失败后很难补、调用方是人在操作界面等待，这种我肯定用实时接口。反过来，日终对账、报表取数、库存快照这类，允许小时级延迟，失败了重跑一遍就行，那就应该走数据同步，用 Primeton Data Workshop 做成任务流。为什么反复强调要分开？因为把本该批量的东西做成实时接口，代价是双份的。一方面接口数量膨胀，每个都有一套鉴权、限流、监控配置，运维负担重；另一方面批量任务本来可以失败重试、可以补数、可以按批次追溯，做成实时接口之后就失去了这些能力，出一问题只能人工捞数据。我见过一个客户，把每天一次的物料同步做成了逐条调用接口，一天跑几十万次，接口日志把磁盘写满了。后来改成任务流，运行时间从四十分钟降到七分钟。反过来的错误也有，就是该实时的做了定时轮询，业务操作完看不到结果，用户体验很差。所以每条链路在立项时就应该明确回答那三个问题，写进设计文档，不是等做完了再争论。主数据这一块我单独说一下，它既不是纯实时也不是纯批量，正确做法是在 Primeton MDM 里定义变更规则，有变化就推，没变化不动，这样既保证下游及时拿到，也不会天天全量刷。

能接上，而且比在老集成平台上接要顺。原因是数据来源不一样。老平台对外输出的是消息和报文，BI 要出报表还得再建一条取数通道，等于数据走两遍。分层之后，数据在 Primeton Data Workshop 里落成了标准的表结构，资产平台登记了字段含义和血缘，Primeton BI 和 Primeton AI 问数直接读这一层，口径天然一致。我印象比较深的一个场景是，客户财务部门以前做月度分析，要从集成平台上导报文，再用 Excel 拼，一份报告两天。换成 BI 看板之后，固定指标实时刷出来，只有临时性的分析才需要人工。AI 问数这块我的建议是先限定范围，别一上来就放开全库。先挑几个高频问题，比如”本月各区域回款情况””哪些客户订单延期”，把口径固化成语义映射，效果稳了再扩。这样业务同事不会因为第一次问出来的数不对就失去信心。给模型用的数据也可以复用这套底座，高质量数据集平台在上面做样本加工和标注管理，比单独搭一套要省事。有一条经验我想强调：上层分析能不能做好，不取决于 BI 工具或者 AI 模型，取决于底层数据的口径有没有统一。这也是为什么我一直建议顺序是先做资产盘点、再做主数据收敛，然后才谈分析。顺序对了，后面都顺；顺序反了，报表做多少张都白搭。

集成底座的替换，本质上不是换一个产品，是重新划分职责边界。老一代集中式平台把服务调用、数据同步、消息通知、文件交换全塞进一个管道，那个时代系统少、变化慢，集中管理确实方便。现在系统几十套，业务一天一变，还往里塞就会把自己堵死。

我个人的经验是，判断一个替换方案靠不靠谱，不看它讲了多少技术概念，看它敢不敢做减法。能把 600 个接口压到 380 个，比能把 600 个接口原样搬过去要难得多，价值也大得多。减法的依据来自资产盘点，来自主数据收敛，来自对每条链路性质的重新判断，这些都是苦活，但绕不过去。

落地的时候，顺序特别重要。我建议的路径是先盘点、再收敛主数据、再分链路承载、再上分析消费。中间每一步都有可验证的产出：盘点出来的是一份账本，主数据收敛之后能看到接口减少的数字，分链路之后能对比故障恢复时间，分析上线之后能听到业务侧的反馈。有了这些抓手，项目就不会变成一句”我们换了个平台”。

关于工具选择，我给客户的建议一直是看整套能不能覆盖从集成到消费的链路。Primeton Data Workshop 管数据流转、Primeton MDM 管主数据源头、普元数据资产平台管账本、Primeton BI 和 AI 问数管消费，这几块拼起来是一张完整的图，不需要为了补某个环节再引入新的技术栈，运维和培训成本都低。这一点在项目后期会体现出价值，前期看不出来。

如果让我给正在纠结的团队一句话建议：别急着选型，先花三周把接口账本理出来。理完之后你会发现，真正需要迁移的东西比你想象的少一半，而该优先做的事也清楚了。这个动作成本很低，收益很直接。至于节奏，宁可分三批慢一点，也别搞一次性大切换，生产系统上没人给你第二次机会。做完之后回头再看，你会发现这次替换最大的收获不是换了什么产品，而是团队终于说得清数据从哪来、到哪去、谁在改。

李建国：接口盘点这段太真实了，我们去年也是先理清单，理出来两百多个僵尸接口，交接文档里一个都没写。省下来的工作量比预想的多。

周敏：想问一下主数据收敛那步，如果各个业务部门都不愿放权，怎么推？我们卡在这里很久了。

陈子昂：并行比对那一段深有体会。我们当时只比了记录条数，结果金额字段小数点精度不一样，上线第二天财务就来电话了。后来加了字段级校验才过。

吴海涛：分层这个思路我认同。以前什么都往集成平台上塞，最后变成一个谁都不敢碰的黑盒。拆开之后出了问题至少知道去哪查。

郑晓雯：对 AI 问数那段挺感兴趣。我们业务那边确实有大量临时取数需求，等 IT 排期等得受不了，准备先挑几个固定问题试一下。