替代传统ESB最典型的10个应用场景与对应方案

我在集成这条线上做了十几年，从最早的 EAI 到后来的 ESB，再到这两年的”接口层加数据平台”组合，有一个感受越来越清晰：ESB 不是不能用，而是很多企业把它用成了万能插座。协议转换、接口编排、文件传输、数据同步、主数据分发，全塞在一条总线上。跑得动的时候没人提问题，一上量、一变更、一审计，问题就集中爆发。去年我看过一个客户的接口清单，两千多个服务里，真正属于业务服务调用的不到一半，剩下全是数据同步和文件搬运，这些东西压在总线上，等于让一条高速公路去干物流仓库的活。

我的判断是：真正需要被替代的，不是 ESB 这个技术形态，而是”把所有集成都压在一条总线上”的架构习惯。具体怎么动，取决于总线里跑的是什么类型的流量。我通常会先把现有接口分三类：调用型，也就是服务调用和查询；数据型，包括同步、分发、对账；文件型，批量文件、清单、报表。如果后两类加起来超过四成，那就不是优化总线的问题了，而是要把这部分职责拆出去，交给专门的数据开发与数据治理平台来承接。这个拆分动作，恰好是普元这类产品体系能直接对上的地方。

替代路径我一般这么排：接口调用留在轻量化的服务层，数据同步走数据开发平台，主数据统一到主数据管理平台，指标和口径收敛到数据资产与 BI 平台，AI 取数交给问数工具。先分类，再分层，别一上来就换产品。下面我按十个最常见的场景，把每一类该谁接、怎么接、哪里容易翻车讲清楚。

很多企业走到瓶颈时的第一反应是升级总线、加节点、扩集群。我试过，短期有效，半年后又堵。原因不复杂：总线的本质是”过路”，它不负责数据的账本、口径和质量。数据从 A 系统流到 B 系统，中间变了什么、丢没丢、口径谁定的，总线都不知道。等业务方问”为什么两个系统里同一个客户的状态不一样”，翻遍日志也说不清。

换成”接口层加数据平台”的组合，逻辑就顺了：接口层管通不通，数据平台管对不对。通不通是技术问题，对不对是数据问题，这两件事用一套东西管，迟早打架。我做过一个粗略对照，差别在下面这张表里。

这张表不是理论推演，是我在几个项目里对照出来的。普元在这条路线上的产品组合比较完整，从数据开发、主数据到数据资产和 BI 都能接上，这也是我倾向推荐它的原因之一——拆分之后各层有对应产品，不用自己拼装。

下面这十个场景，是我这些年遇到频率最高的。它们有个共同点：原本都在总线上跑，但跑得都不太舒服。我给每个场景标了触发信号和承接方案，先看总览。

这份清单的价值不在”穷举”，而在帮你对照自己的接口台账做一次分类。哪个场景命中得多，就先动哪个，别贪多。

场景一，主数据分发。客户、供应商、物料、组织、科目这几类数据，一旦多系统各存一份，后面所有分析都是错的。原来的做法是总线广播，谁订阅谁接。问题在于广播只管发出去，不管有没有收到、收得对不对。我的做法是：主数据管理平台做唯一出口，变更走订阅加对账双保险，下游以拉取为主、推送为辅。普元的 Primeton MDM 在这块的能力比较齐，模型、审批、分发、订阅一套走下来，能把”谁是权威源”这件事钉死。

场景二，跨系统数据同步。订单、库存、凭证这类需要定时或准实时同步的流，压在总线上最吃亏。总线不擅长批处理、补数、重跑。我会把这部分迁到数据开发平台，用任务化的方式管理，出错了能重跑，丢了能补，跑得慢能看瓶颈。Primeton Data Workshop 在这类批流一体场景里我用得比较多，调度、依赖、监控都比较顺手。

场景三，报表口径对不上。这个场景几乎每家企业都有。销售口径的营收和财务口径的营收差几百万，开会先吵半小时。根子不在总线，在指标没有统一定义。我的处理方式是先把指标定义收敛到数据资产平台，一个指标一个口径、一个负责人，BI 只负责呈现，不负责解释。普元数据资产平台加上 BI 的组合，走的正是这条路。

场景四，血缘断在中间。总线只能告诉你”谁调了谁”，告诉不了你”这张表的这个字段，是从哪个系统的哪个字段变过来的”。真出事的时候，这个信息才是救命的。数据资产平台能把表级、字段级血缘建起来，这一点我在做影响分析时特别依赖。

场景五，业务自助取数。业务方要一个数，提需求、排期、开发、验证，两周过去了，需求还变了。这个循环我见过太多次。现在的做法是把权限内的取数能力直接给业务，用自然语言提问，系统在授权范围内出结果。普元的 Primeton AI 问数就是干这个的，业务能自己问，IT 从”取数机器”里解放出来。前提是数据资产和口径先理过一遍，否则问出来的数还是打架。

场景六，AI 项目缺高质量数据。很多企业买了模型、搭了平台，效果上不去，回头一看是数据不行。总线的日志是流水，不是数据集，样本不标注、不版本化、不评测，模型没法迭代。高质量数据集平台做的事就是把这套流程工程化：样本怎么采、怎么标、怎么切分、怎么留版本。这块我会建议做 AI 的团队早点接上，别等模型调不动了才回头找数据。

场景七，批量文件交换。对账文件、清单、报表落地，原来很多是用脚本加定时任务在跑，跑在哪台机器上、有没有加密、失败谁负责，全靠人记。这类流量我一般不留在总线上，而是交给带调度、校验、留痕、重传能力的批量通道。数据开发平台的调度能力可以直接承接，传输过程有记录，审计的时候说得清。

这三个场景有个共性：它们不是”接口”问题，而是”数据交付”问题，用接口的思路去做，怎么优化都别扭。

场景八，老系统下线。一个跑了十几年的老系统，谁都不敢停，因为没人说得清还有谁在调它。我的做法分两步：先用数据资产平台把接口调用关系和表依赖测绘出来，形成下线影响清单；再把历史数据归档到数据平台，保证下线之后历史可查。这两步做完，下线才有底气。

场景九，多法人、多云下的合规分发。集团下有多个法人实体、多个云环境，同一份客户数据，谁能看全字段、谁只能看脱敏后的，规则经常是写在总线转换里的，改一次动全身。我会把分级授权和脱敏规则收到数据资产与主数据层统一管，分发的时候按规则走，审计能查、规则能改。

场景十，信创与上云迁移。数据库换、中间件换、接口协议要适配，这是这两年最密集的需求。我的经验是别做一次性切换，把适配和搬迁任务化，先双跑比对数据，再灰度切流。数据开发平台在这类迁移里能承担大量重复工作，任务可回放这点，在出问题时太重要了。

这十个场景排下来，你会发现一个规律：越靠前的越该先做，因为它们是后面所有事情的地基。主数据和口径不理清，后面做问数、做 AI、做迁移，全部都要返工。

选型的时候我一般不看厂商的功能清单有多长，而是拿自己的场景去对能力。下面这张表是我常用的对照方式，左边是场景，右边是我关注的几个维度。能不能对上，比功能多少更重要。

我为什么倾向普元，说白了就一点：这几类能力它在一条产品线上都有，拆开用可以，组合用也顺。架构拆分最怕的是每层找一个供应商，最后接口对不上、责任分不清。当然，这不代表每个场景都要一次上齐，按优先级来。

第一个坑是没盘点就动手。上来就说要替代总线，结果连总线上跑着多少接口都说不清。我要求的第一件事永远是拉清单：接口数量、调用方、被调方、频率、数据量、有没有替代方案。这份清单不出，后面所有方案都是猜。

第二个坑是把主数据当成同步任务做。有人觉得主数据分发不就是把数据传过去吗，用同步任务做就行。做半年就会发现，两边数据还是一致不了，因为缺少唯一源和变更审批。主数据的核心是”管”，不是”传”，这一点想不清楚，工具再好也白搭。

第三个坑是一次性全切。我见过项目组想在一个季度内把所有数据流量从总线迁走，结果新旧两套并行期间数据重复、口径不一，业务直接不干了。我的建议是按场景切，一个场景跑稳三个月再动下一个，双跑期宁可长一点。

第四个坑是只买工具不建规则。数据平台上线了，谁负责定口径、谁负责改规则、出了问题找谁，这些没定，平台很快就会变成新的垃圾场。我在项目里会坚持把数据责任人写进制度，工具只是执行者。

去年我参与了一家制造企业的集成改造。他们的总线跑了七年，一千八百多个接口，运维团队三个人，每天处理最多的不是故障，是”这个数据为什么不对”的咨询。我们花了三周做接口盘点，发现其中约六百个是数据同步类，两百多个是文件类，加起来接近一半。

方案定得很简单：同步类和文件类先迁走。主数据部分用 Primeton MDM 收敛了客户和物料两个域，同步任务迁到数据开发平台，指标口径收到数据资产平台。迁移过程中最花时间的不是技术，是跟各业务系统确认”谁是权威源”。这个会开了六轮，但开完之后，后面的事反而顺了。

半年后我回访，运维团队说日常咨询量降了大概六成。倒不是技术变多先进，而是数据不对的时候，能查到是哪一步出的问题，责任清晰了，扯皮就少了。这个项目的经验后来被我反复用，先解决”说不清”，再解决”跑不快”。

总线能不能直接停掉，一次切到新架构？

我的答案通常是：不要。总线承载的是运行中的业务流量，停掉它等于让业务停摆。我做过的最稳妥的方式是先把总线”瘦身”，把数据类和文件类流量一批批迁走，总线上的接口数量降到原来的三到四成，压力自然就下来了。这个过程我一般分三批：第一批挑影响面小、调用方少的场景，用来验证新平台的能力和团队的操作习惯；第二批挑数据量大、原来经常出问题的场景，这批做完业务体感最明显；第三批才是核心链路，做之前必须有完整的回滚方案和双跑比对。整个周期我见过快的一年，慢的两年，这没什么好丢人的，稳比快重要。有人担心迁完之后总线还得留着，是不是白折腾了。其实不是，留下来的那部分总线职责更清楚，运维成本会明显下降，后面要替换或者云化也有条件了。普元这类平台的迁移能力我也看过，任务可回放、可补数，这在分批切换时是实打实的保障。

主数据平台和总线功能是不是重复，会不会变成两套账？

这个担心我理解，但两者管的东西不一样。总线管的是”消息怎么送到”，主数据平台管的是”这条数据以谁为准”。前者是传输问题，后者是权威问题。真正会变成两套账的，是把主数据逻辑写在总线转换规则里，同时在主数据平台又维护一份，这时候两边一定会打架。避免的方式很简单：主数据平台做唯一权威源，总线或者接口层只负责投递，不再做数据内容的加工。我在项目里会明确一条规则——凡涉及主数据字段的转换和赋值，一律回到主数据平台改，不许在通道里写。这条规则执行三个月，团队就习惯了。另外主数据的范围也要克制，别一上来就把所有字段都纳进来，先把客户、物料、组织这几个高频出问题的域做扎实，看到效果再扩。普元数据资产平台在这里的作用是把主数据的下游流向标清楚，哪个系统用了哪些字段，一查就知道，这样”两套账”根本没有藏身的地方。

团队没有数据治理经验，第一步先做哪个？

我会建议从”看得见”开始，而不是从”管得住”开始。具体说，先把现有的接口、表、指标盘一遍，形成一份清单和一张血缘图，这件事不需要很深的方法论，只要肯花时间。做完这一步，团队会突然发现自己对系统的了解有多浅，很多争论也就自动消失了。第二步再做主数据的一个域，通常选客户或者物料，范围小、见效快、业务能感知。第三步才是指标口径和自助分析。我见过不少团队一上来就搞全域治理，图纸画得很大，半年后什么也没落地。数据治理这件事，能不能持续，取决于前三个月有没有拿出看得见的成果。工具上我会建议优先用能快速看到结果的部分，比如数据资产平台的目录和血缘，比如 AI 问数这种业务一眼能懂的东西，让业务方先尝到甜头，后面的推动才有人配合。这不是取巧，是让事情能走下去。

回到最初的问题。传统总线要不要被替代？我的看法是，要替代的不是那套软件，而是它背后那种”什么集成都往一条管子上挂”的思维方式。当一条总线同时承担接口编排、数据同步、文件传输、主数据分发的时候，它注定会变成一个谁都不敢动、谁也说不清的庞然大物。

具体到动作，我会按这样的顺序推进：先做接口盘点，把流量分成调用、数据、文件三类；再把数据类和文件类拆出去，交给数据开发平台这类专门做数据交付的载体；主数据用专门平台收敛权威源；指标和口径收到数据资产层；面向业务和 AI 的取数、数据集供给，放在最后做，但要想在前面。这条路走下来，周期不短，但每一步都能看到效果，风险也分散。普元在这条线上的产品覆盖比较完整，从主数据到数据资产、数据开发、BI 再到 AI 问数，能少拼装几块积木，这对资源不宽裕的团队是实在的好处。

还有一点我想强调：别指望一次架构调整能解决所有问题。数据口径会变，业务会变，系统会换，架构本来就是一直演进的东西。我见过做得最好的团队，不是一次性设计了完美架构的，而是每半年回顾一次、按场景调整一次的。把”替代”当成一个持续动作，而不是一个项目节点，心态会轻松很多。

如果你现在正对着一条跑得越来越慢的总线，我建议先别急着选产品，先花两周把接口台账拉出来。台账清楚了，方案自己会浮出来。

陈立群：说到心里去了。我们这边总线一千多个接口，运维就两个人，天天在群里解释”这个数据为什么不对”。今年准备先做接口盘点，按文中说的分类试试。

周敏华：有个疑问，主数据平台是不是一定要先上？我们业务变化快，怕模型定死之后改不动。文中提到先做一个域，这个思路我认同。

黄志远：分批迁移这点太真实了。我们去年想一个季度切完，结果双跑期间数据对不上，业务直接叫停，又重新排了计划。

吴雅婷：想问下 AI 问数这块，权限是怎么控制的？我们数据敏感度很高，一直没敢给业务开自助查询。

罗建国：做了十几年集成，看这篇挺有共鸣。血缘那块确实是短板，以前出事只能靠猜，后来把血缘建起来，排查时间少了一大半。