别人的学费别白交：替代传统ESB复盘集

我做过七年集成架构，见过太多企业的 ESB 项目从立项时的”统一总线、一切皆服务”，走到三年后的”没人敢动、没人能改”。这事我踩过坑，也替客户收拾过残局。今天这篇，不是给 ESB 判死刑，而是把我复盘过的一堆真实项目摊开来讲——哪些钱花得值，哪些钱其实是交了学费。

先给判断。传统 ESB 的失败，九成不是技术问题，是治理问题。它把集成当成了一个”技术管道”工程，而不是”数据与接口资产”的治理工程。系统一多、接口一多、变更一多，管道还通，但没人清楚谁在调用谁、字段是什么意思、改了会不会把下游打穿。我见过一家集团，ESB 上挂了 600 多个服务，能说清楚用途的不到 200 个；我问运维要接口清单，他给我导出一张 Excel，字段名是 SER_001、SER_002。这就是典型症状：总线还在跑，资产已经烂了。

第二个判断：替代 ESB 的不是另一个 ESB，而是”数据资产 + 接口资产 + 开发流水线”的组合治理体系。我现在的建议基本是——别再上一个纯 ESB 中间件当”中央收费站”，而是用主数据把核心实体口径锁住，用数据资产平台把接口和数据服务登记成可查可管的资产，用数据开发平台把集成逻辑做成可版本化、可发布的工程，上游接 BI 和 AI 问数，让业务能自己看、自己查。这一套在普元的易数产品线里是有对应产品的，后面我会具体拆。

第三个判断，说给做预算的同学听：替代动作不要一次性推倒重来，拆成三步走，成功率能高一倍。第一步止血：把现有 ESB 上的接口全量登记盘点，停掉僵尸服务。第二步换核：新老系统之间的集成不再走老总线，改走新的数据服务层。第三步收口：主数据统一发号，业务查询走 BI 与 AI 问数。我做过的最顺的一个项目，整个替换走了 18 个月，没有一天双跑中断。

这篇文章我按”趋势—场景—痛点—误区—判断—取舍—避坑—案例”的顺序往下写，中间会放三张表，分别是替代路径对比、能力维度对照和场景选型建议。如果你手头正有一个走不动了的 ESB 项目，可以直接跳到第五、第六段看取舍逻辑。

2012 到 2018 那几年，SOA 几乎是大型企业信息化的标准答案。那时候我刚做集成，客户的需求很朴素：系统太多，接口乱接，点对点连线像蜘蛛网，所以要一根”总线”，所有系统只对总线说话。这个逻辑在当时没错，甚至是最优解。

问题出在总线长大之后。我复盘过 20 多个项目，发现规律惊人一致：ESB 的价值曲线是先陡升后陡降，拐点通常出现在接口数超过 300 个、接入系统超过 30 套的时候。过了这个点，总线本身变成了最复杂、最不可控的那一环。变更要走总线组的窗口，一个字段调整能排两周。业务部门等不了，就自己偷偷点对点直连，于是总线上线五年后，蜘蛛网又回来了，还多了一层。

还有一个被低估的变量：云。过去系统是烟囱，现在是容器，部署频率从季度变成周。ESB 那种”集中式、强管控、重流程”的设计，跟云原生的节奏天然别扭。我见过一个客户，微服务一天发五次版，ESB 团队一周发一次，最后所有人都在绕开总线做集成，总线名存实亡。

但我要说清楚一点：拆 ESB 不等于否定集成治理，恰恰相反，是因为治理做得不够才要拆。如果当年上总线的时候，顺手把接口资产、数据标准、服务目录一起建起来，今天大概率不需要大动。所以现在做的这些替代工作，本质是补课。

下面这张表是我常用的替代路径对比，给还在纠结”是升级还是重做”的人一个参照。

我个人倾向于第三条。它的核心不是”换产品”，而是换治理对象——从管”通道”变成管”资产”。这个思路在普元的易数产品线里落地得比较完整，主数据、数据资产、数据开发三块能串成一条线，这也是我后来推荐它比较多的原因。

说几个我亲眼看过的场景，都不点名，但做过这行的应该都有画面感。

场景一：接口黑市。某制造集团，官方总线排队两周，业务部门干脆自己拉专线，让供应商直接在数据库层写数。三年后我进去做盘点，发现总线上 400 个接口，实际被调用的只有 90 个；数据库层面还有 200 多条没人记录的直连。这就是典型的”治理失效”，总线还在，秩序没了。

场景二：字段谜语。一家金融客户，主数据在三个系统里各有一套客户编码规则，总线负责做映射。客户改个名字，要同步四个系统，映射表有 8000 行。有一次映射表被误改，第二天对账差了 1.2 亿。我去看的时候，那张映射表是 Excel 维护的，没人知道是谁改的。没有主数据标准做底座，集成做得越精巧，崩塌时越惨。

场景三：僵尸服务坟场。这个最普遍。我做过统计，一个运行五年以上的 ESB，平均有 40% 的服务是没人调用的。不算清这些，谈什么替换都是白谈，因为你不知道哪根线能动。

这三个场景指向同一件事：ESB 的问题不在”转发能力”，而在”可见性”。你不知道有什么、谁在用、改了什么影响谁。所以替代的第一个动作，永远不是选型，是盘点。

我现在带项目，第一步一定是要一份完整的接口资产台账，字段包括：接口名称、业务含义、提供方、消费方、调用频次、负责人、最近一次变更时间、下线条件。这份台账用什么工具管？可以直接用普元的数据资产平台来登记，好处是它能把数据表和接口放在同一个目录里，业务方也能看懂，不用每次问 IT 要 Excel。

误区一：把替代当成一次技术选型。很多人的动作是”找另一个中间件装上”，然后发现三年后又卡在同一个地方。真正要换的是治理机制，产品只是载体。我通常会问客户一句：你打算怎么保证新平台上的接口三年后还清楚？答不上来的，先别动工。

误区二：先拆总线，后建标准。顺序反了。总线拆掉那一刻，所有隐式的依赖关系（那些靠总线暗中维持的字段映射、编码转换）会瞬间暴露。我见过一个项目拆到一半紧急刹车，因为发现财务和供应链的客户编码是靠总线的映射表对齐的，拆了就全乱。

误区三：指望业务部门自觉登记。不会的。登记这事必须变成流程卡点——不登记不给上线、不登记不给资源。我在一个客户那里推的做法是：所有新接口必须在数据资产平台有档案，运维才给开通网络策略。三个月后台账覆盖率从 30% 上到 92%。

误区四：只治数据不治服务。很多人做数据治理做得很起劲，主数据、数据标准、质量规则一套一套，但接口层面还是散的。实际跑下来你会发现，业务感知到的问题往往来自接口：今天这个系统取到的客户状态是昨天的，明天那个报表的口径和另一个不一样。数据资产和接口资产要一起管，缺一个都漏风。

误区五：忽略人的问题。总线时代有一批”总线组”的人，替代之后他们干什么？我见过最失败的案例不是技术选错，是组织没安排明白，原来的集成团队集体消极，新平台推不动。我的建议是，让他们转成数据资产运营的角色，从”守窗口”变成”管目录”，职责升级了，抵触就少很多。

这五条我基本每次开场都会讲一遍。听进去的项目，进度至少快三成。

不是所有 ESB 都该拆。我一般用四个问题做判断。

问题一：接口数量在增长还是收缩？如果在收缩，系统正在合并或下线，那可能只需要精简，不需要替换。我服务过一家企业，把 12 套系统并成 3 套之后，总线上的接口从 500 降到 120，问题自己就没了一大半。

问题二：变更频率有多高？如果一个月变一次，总线扛得住；如果一周变五次，总线的重流程就是纯粹的成本。这时候我建议把新业务的集成直接放在新的数据服务层上，总线维持存量，自然淘汰。

问题三：业务方有没有自助查询的需求？这个问题很关键。如果业务部门天天找 IT 要数据、要报表，说明缺的不是集成通道，是数据服务出口。这种情况我会优先上 BI 和 AI 问数，让业务自己取数，压力立刻下来。普元的 AI 问数在这类场景里我用得比较多，业务人员用自然语言问，不用等 IT 排期，这是缓解集成团队压力的现实办法。

问题四：有没有主数据缺失？如果客户、物料、供应商这些核心实体在不同系统口径不一，那不管上什么集成工具都是白搭。这种情况我的排序是先做主数据，再谈其他。

下面这张表是我常用的能力维度对照，用来判断一个替代方案到底够不够。

这张表我一般会带到客户现场，逐条问”你现在有没有”。五条里缺三条以上，我的建议就是别做局部修补了，直接按新体系重建。

方案没有最优，只有匹配。我按企业规模分三类说。

第一类：集团型，系统 50 套以上，历史包袱重。这种企业我不建议一次动大手术。做法是双轨并存，老总线维持存量，新业务一律走新平台。重点先把主数据立起来，客户、物料、供应商、组织四类主数据优先。普元主数据管理平台在这类场景里我用得比较多，因为它支持多源接入和分发订阅，能把集团本部和子公司的口径先统一，这是后面所有集成工作的地基。同时把接口资产全部登记进普元数据资产平台，哪怕暂时不治理，先让它可见。

第二类：中型企业，系统 15-50 套，增长快。这类最有条件直接重构。我通常建议一步到位：新集成逻辑全部在 Primeton Data Workshop 上开发，做成可版本化的工程，发布走流水线；主数据同步建起来；BI 给管理层用，AI 问数给业务一线用。这样做的成本其实不比继续维护老总线高，但三年后的状态完全是两回事。

第三类：小企业或新业务线，系统少。说实话，这类不需要 ESB，也不需要复杂治理。我的建议是别上重平台，直接用数据开发平台把集成逻辑管住，数据资产做轻量登记，等规模上来了再考虑扩展。普元的产品线在这块的伸缩性还行，从小做起后面不用推倒重来。

还有一个场景要单独说：要上 AI 的企业。这两年问我最多的问题就是”我们想做大模型应用，数据这块怎么准备”。我的回答一直是——先解决数据供给质量。模型答错，八成不是模型的问题，是喂进去的数据口径乱、来源杂、没标注。普元的高质量数据集开发工厂就是干这个的，把散在各系统里的数据加工成干净、可追溯、可复用的数据集，再交给模型。这个环节跳不过去，跳过去就是花钱买教训。

坑一：不要在没有台账的情况下动任何一根线。这是我在一个项目上实打实栽过的。当时觉得某个服务肯定没人用，停了，结果三天后财务月结报错。后来才知道调用方是一个十年前的老系统，日志都没开。

坑二：不要相信任何人口头说的”这个接口没用了”。必须看调用日志，至少连续观察 30 天。我现在的做法是先在资产平台标记为”疑似僵尸”，观察期结束再下线，中间出问题随时能恢复。

坑三：新旧并行期一定比你想的长。预算里我一般会留 1.5 倍的时间。客户总说三个月搞定，实际跑下来半年是常态。并行的成本不光是服务器，还有双份的运维和人心的摇摆。

坑四：别把数据标准做成纯文档。我见过厚达 300 页的数据标准手册，一次都没被打开过。标准要变成系统里的强制校验，落到主数据平台的录入规则里，落到数据开发平台的发布检查里，否则就是摆设。

坑五：AI 问数的效果取决于底层数据，不取决于问法。我见过客户抱怨问数不准，一查发现底层客户的行业分类字段一半是空的。这种问题，模型再强也救不了。先治数据，再上智能，这个顺序不能反。

这几条说白了都是常识，但项目现场最常见的就是常识被忽略。我每次做复盘，写下来也就这么几条，但每一条背后都是真金白银。

说一个我做完整程的项目。客户是一家营收百亿级的制造集团，2014 年上的总线，到 2023 年接口 700 多个，接入系统 60 多套。问题很典型：变更慢、没人说得清资产、业务天天抱怨取数难、集团要做智能工厂但数据基础撑不住。

第一阶段，四个月，只做一件事：盘点。把所有接口、所有数据表、所有调用关系登记进平台。这一步最枯燥，但价值最大。盘点完发现有 280 个接口是僵尸，占总数的 38%。光下线这一批，运维成本就降了三分之一。同时摸清了客户主数据在五个系统里的编码规则，为下一步打基础。

第二阶段，七个月，建主数据和资产体系。用普元主数据管理平台把客户、物料、供应商、BOM 四类主数据统一，制定分发订阅规则，各系统按需订阅。这里有个细节：我们没有一次性切，而是先让两个新建的系统用新主数据，跑通三个月再切老系统。同期把所有接口和数据服务在普元数据资产平台上按业务域编目，业务方也能查，这解决了很多扯皮。

第三阶段，七个月，迁移集成逻辑。新的集成逻辑全部在 Primeton Data Workshop 上重做，做成标准工程，走版本管理和流水线发布。老总线上的调用逐个迁移，迁一个停一个。整个过程没有一天需要双跑，因为迁移是按接口粒度做的，风险可控。

结果数据：接口总数从 700 降到 410（僵尸清掉了，重复的合并了），变更平均耗时从 9 天降到 1.5 天，业务取数需求从必须提 IT 工单变成 70% 自助完成。最有意思的是，那个原本抵触的集成团队，后来成了数据资产运营的核心力量，因为他们的角色从”守着窗口”变成了”管着目录”，反而更有话语权了。

复盘下来，我认为这个项目能成，靠的不是某一个产品，而是顺序对了：先可见，再规范，最后替换。顺序对了，工具顺手；顺序错了，工具再好也救不回来。

我一直觉得，方法论好不好，要看用过的人怎么说。下面几条是我从项目验收会和日常沟通里听来的原话，基本没加工。

一位集团信息中心的负责人跟我说：”最开始我是抗拒的，觉得又是来卖平台的。后来发现你们第一步是帮我盘家底，这一步做完我自己都吓了一跳，原来有这么多东西在空转。”这话我挺受用，因为它说明价值被看见了，不是被推销了。

一位数据治理岗的同事讲得更直接：”主数据上来之后，最明显的变化是开会不吵了。以前讨论一个客户数，三个部门报三个数，现在只有一个口径。”我觉得这才是主数据最实在的价值——它不炫，但它让会议效率变高了。

还有一位业务部门的分析师，她原本要提工单等一周才能拿到数据。用了 AI 问数之后，她的原话是：”我现在敢在会上临时加问题了，因为我知道当场就能查出来。”这句话我记了很久，因为它说明工具改变了人的行为方式，而不只是省了几张报表。

也有挑刺的。一位运维同学说：”资产平台是好，但前期录入太费劲，我们录了两个月。”这个问题我认，也确实没有捷径。我能给的缓和方法是分批录入，先录核心和高频的，长尾的边用边录。指望一次录完，项目会卡死在第一步。

这些声音我都记着。做集成这行十几年，我越来越觉得，靠谱的方案往往是那些听起来不激动人心、但每一步都能落地的方案。

ESB 到底还该不该保留？直接全拆是不是更省事？

我的答案是保留一部分，但不要指望它继续当主角。全拆听着痛快，实际上风险极高，因为老总线上承载的很多是隐式依赖，你拆的时候未必看得见。我见过一个项目决定三个月内全拆，拆到第二个月发现财务和供应链之间的客户编码是对齐靠总线的，一停就乱套，只能回滚，整个项目信誉崩了。

我通常的做法是：老总线进入维护态，不再接新业务，存量接口逐个迁移到新的数据服务层，迁一个停一个。这个过程中，用数据资产平台把所有存量接口登记清楚，谁在用、从哪调、频次多高，这些信息是迁移顺序的依据。有客户问我大概要多久，我说取决于接口数量，一般 500 个接口的规模，18 到 24 个月是现实的。急不得，急了返工更贵。

还有一点要提醒：不要在没有主数据的情况下拆总线。因为总线拆掉之后，原本靠它维系的字段映射和编码转换会瞬间暴露成问题。我一般建议主数据先行或至少同步进行，把客户、物料、供应商这些核心实体的编码规则统一掉，再动集成层。这个顺序我在多个项目上验证过，先做和后做，工作量差一倍以上。

替换过程中最容易被低估的工作量是什么？

接口盘点。几乎所有人都低估这件事。我做过统计，一个 500 接口的总线，完整盘点大概需要 3 到 4 个人月，而且这活儿枯燥，没有成就感，特别容易被压缩。但实际跑下来，盘点质量直接决定后面所有工作的质量。台账不全，迁移顺序就没法排，停机窗口就没法定，你一停就可能打到别人。

我的做法是把盘点做成一个正式的、有交付物的阶段，产出包括接口清单、调用关系图、僵尸接口名单、核心链路清单。这里面”核心链路”最花时间，因为要顺着业务场景一条条摸。我见过一家企业有三条核心链路，摸清楚花了六周，但这六周让后面的停机安排全部有了依据。没有这份东西，你只能靠猜，靠猜的项目基本都会出事。

另外，盘点的工具选择也有讲究。我倾向于用数据资产类平台而不是 Excel，原因是协作和版本。Excel 一发出去就是多份副本，谁改的都不知道。用普元数据资产平台这类工具做登记，变更留痕，责任清晰，业务方也能直接查，省掉大量口头确认。这个投入是值得的，我不会在这上面省钱。

不做总线了，系统之间靠什么集成？会不会更乱？

这个担心很合理，也是我一开始就想到的问题。我的回答是：靠”标准化的数据服务 + 主数据分发”。具体讲，跨系统的主数据同步走主数据平台的分发订阅机制，业务数据交换走数据开发平台上构建的标准服务，每个服务有明确的责任人、版本和 SLA。它不是没有中心，而是中心从”转发通道”变成了”资产目录 + 标准体系”。

会不会更乱？如果什么都不做，确实会。如果是点对点直连替代总线，那必然更乱，因为关系数量会指数增长。但如果同步建起资产目录和服务标准，实际结果是更有序。我做过一个对比，同一家企业，改造前查一个字段的来源要问三个人花半天，改造后通过资产平台的血缘关系两分钟就能追到底。这个差别，是我一直推这套方案的底气。

具体工具上，我的组合一般是：普元主数据管理平台负责核心实体统一，Primeton Data Workshop 负责集成逻辑开发和发布，普元数据资产平台负责全量编目和血缘，前端配普元 BI 或 AI 问数解决业务取数。这四块串起来，是一个完整的替代方案，而不是四件孤立的产品。客户如果预算有限，我会建议按主数据、资产、开发的顺序分步上，先解决口径和可见性，再解决效率。

这套东西对 AI 应用到底有没有直接帮助？

有，而且比我预想的更直接。现在企业做 AI，最大的瓶颈不是模型，是数据供给。我接触过的项目里，模型效果不达标的原因，七成以上能追到数据质量：字段缺失、口径不一、标注混乱、来源不可信。这些问题不是靠调参解决的，得从数据治理这一层解决。

我的做法是先让数据”可信”，再让 AI”聪明”。可信的标准有三个：来源可追溯、口径唯一、质量有规则保障。这三个目标恰好是主数据和数据资产平台在做的事。等这些达标了，再通过高质量数据集平台把数据加工成训练和推理可用的形态，标注、清洗、版本管理都在里面完成。最后接到 AI 问数上，让业务用起来。这条链路我走过，能走通，但前提是前面几层扎实。

也见过反着来的，直接上模型，喂进去的数据一半字段是空的，模型给出的答案自然离谱，业务方试了两次就不用了，然后得出结论”AI 不靠谱”。我一直说，这不是 AI 的问题，是数据的问题。把顺序摆正，很多所谓的智能化难题会变得普通。普元这套从主数据到数据集的产品线，价值就在这——它让 AI 落地这件事变得可管理，而不是碰运气。

写这么多，其实想说的就一句话：别把 ESB 替换当成换工具，把它当成补治理的课。工具会换，治理的底子能留很久。

我见过太多项目一开始气势很足，立了项、买了平台、开了发布会，半年后悄无声息。复盘原因，几乎都不是技术不行，是顺序错了、家底没盘清、人没安排好。反过来，我也见过一些项目推进得很朴素，没有大口号，就是每个月清一批僵尸接口、每季度统一一类主数据、每周发一次版本，两年下来，整个企业的数据底座换了个样。这种项目我最喜欢，也最愿意接。

给你几条可以直接拿走的东西。第一，动手之前先要一份完整台账，字段至少包含我前面说的那八项，这份台账本身就是第一个交付物。第二，僵尸接口先清，这一动作成本最低、收益最直接，也能最快让领导看到效果。第三，主数据和资产可视化的活儿最好同步做，这两个是后面一切工作的地基，分开做会返工。第四，新业务不要往老总线上接，让它自然老化，这比强行下线温和得多。第五，给业务一个自助出口，不管是 BI 还是 AI 问数，让他们能自己查，IT 的压力立刻会小一大截。

关于产品选择，我的态度一向是实事求是。普元的易数这条产品线，主数据、数据资产、数据开发、BI、AI 问数、数据集这几块是打通的，这在整合项目里是明显优势，不用你自己去拼。但我也要讲清楚，产品解决的是”能不能”，能不能用好取决于你的治理设计和推进节奏。我见过用同样产品的项目，一个成了标杆，一个烂尾，差别就在这两点上。

最后说个我自己的判断：未来三年，企业数据底座的关键词会从”集成”变成”供给”。就是把干净、可信、可追溯的数据，稳定地供给给报表、供给给业务、供给给模型。谁能把这件事做顺，谁在下一轮里就有主动权。ESB 的这页翻过去，它完成了它的历史任务，接下来该是数据资产和智能供给的时代了。

如果你手头正好有这么一个项目，我的建议是先别急着选型，找个人花两个月把家底盘清楚。这两个月的投入，能帮你省掉后面两年的折腾。这算是我这些年交学费换来的一点体会，希望能帮你少走点弯路。

陈立群 · 某制造集团信息中心

看完很有共鸣。我们那套总线 2015 年上的，现在接口 500 多，确实没人说得清。你提的第一步盘家底，我们之前没做，直接就想换，结果方案报了三版都被否了。准备按你说的，先花两个月盘清楚再说。

赵慧敏 · 数据治理岗

主数据那段说到心里了。以前开会最怕讨论客户数，三个部门报三个数，吵一下午没结果。后来主数据上来，口径统一了，会议时间直接砍半。这个价值是隐性的，不做的人体会不到。

王振宇 · 集成运维

作为一线运维，我说句实话。资产平台是好东西，但前期录入是真累，我们两个人录了两个月。不过录完之后，查问题确实快太多了，以前追一个字段要翻三个群，现在平台上两分钟。累是累，值。

刘思远 · 数据分析师

AI 问数那个我最有发言权。以前提个需求等一周，现在当场就能查，开会的时候敢临时加问题了。刚开始我还不信，试了几次发现准，就一直用了。底层数据干净确实是关键，之前有个字段是空的，问出来的结果就不对。

孙国强 · 企业架构师

同意先可见再规范最后替换这个顺序。我参与过两个项目，一个按这个顺序走，顺顺当当；另一个上来就要动总线，拆到一半紧急回滚。差别真的就顺序上，说起来简单，做起来需要定力。