严格定义：替代传统ESB到底指什么

我做过十几个和”替代传统 ESB”沾边的项目。真正在评审会上把需求摊开的时候，会发现各人心里的目标完全不一样。架构组想的是把总线这个单点拿掉，运维想的是少维护一台中间件，业务部门想的是接口能不能当天开通，数据团队想的是口径能不能统一。这四个诉求，指向的其实是四种完全不同的改造。

所以我这几年的判断是：替代传统 ESB，严格讲不是换一个中间件，而是把”以总线为中心的同步调用”改成”以数据资产为中心的按需供给”。这句话听起来绕，拆开就清楚了。总线之所以长期占着核心位置，是因为它替企业兜住了三件没人愿意接的活——协议不通它来转，字段不一致它来映射，系统之间要同步数据它来搬。这些年微服务和云原生铺开之后，协议转换和服务路由这两件事，应用框架加一个轻量接入层基本能接住。真正没被接住的是第三件：数据在不同系统之间怎么对齐、怎么加工、怎么有秩序地供给出去。

我在一个集团客户那里做过统计，总线上跑的服务里，真正属于”业务实时调用”的不到四成，剩下六成是定时同步、批量搬运、报表取数。也就是说，大家嘴上说要替代总线，实际要解决的是数据供给方式的问题。这两个问题混在一起谈，项目一定会跑偏。

我的建议很直接：别急着立”替换总线”的项。先做一次接口和数据的双向盘点。我通常会看三张表——现有服务清单、近半年调用量分布、跨系统反复同步的数据实体清单。这三张表出来，该替代什么、不该动什么，边界基本就清楚了。

我把经手的项目翻了一遍，传统 ESB 在企业里实际扛的活，比它宣传的多得多。名义上它是服务总线，实际上更像一个什么都往里面塞的中央厨房。协议不通就接总线，字段对不上就在总线上做映射，系统之间要同步客户档案也接总线，甚至连报表取数都有人绕过数仓，直接调总线上的接口。

塞得越多，问题越明显。总线的配置只有两三个老同事看得懂，改一个字段要停一次窗口，链路上一个节点超时，整条链路跟着卡住。更麻烦的是，这些接口背后对应哪些数据、谁负责、口径是什么，翻配置也翻不出来。运维同事最怕的一句话就是”这个接口当年是谁配的”。

这张表我一般直接拿给客户的信息中心看，效果比讲架构图好。当”接口适配”和”数据供给”被放在同一张表里对比，谁在干重复的活、谁在替谁背锅，一眼就能看出来。

有个细节值得说：总线上大量的报文映射规则，其实是数据治理该干的事。比如客户名称在三个系统里有三种写法，总线每次同步都顺手做一次字符串清洗。这种规则散落在配置里，没人知道全貌，改了之后也没法回归验证。把它挪到数据加工层，用一个统一任务来做，规则可视、可测试、可追责，这才叫真正接住活。

顺便说一句，我见过最典型的浪费是：总线上一条同步链路，数据仓库里一条抽取链路，两边拉的是同一张表。业务提一个新指标，两边都要改。这种重复，不是技术问题，是没人在中间把”这份数据从哪来、给谁用”讲清楚。

这些年我见过三种走法，差异非常大。路径本身没有绝对对错，错的是不问企业现状就照搬别人的路线。

第一种是硬替换，一次性把总线上的服务全部重写，替换完就下线。这种打法我一般会劝一劝。系统数量少、接口规范、业务能接受停窗口的企业，可以试试；但绝大多数企业一做就做成两年工期，中间业务需求一变，新老两套并行，成本翻倍。

第二种是双轨并行，新的走新链路，老的继续跑。这种比较稳，代价是周期长，而且很容易出现”新的上线了，老的没人管”的收口难题。我通常要求在这种路径里加一个硬性动作：每条老链路必须挂一个退役日期，到点必须有人签字确认。

第三种是数据侧先重构、总线逐步收缩。这条是我个人更倾向的，原因在后面几段会讲。

为什么我更倾向第三条路？因为在多数企业里，真正卡住业务的不是”接口调不通”，而是”同一份数据三个系统三个答案”。接口调不通你会立刻知道，数据口径不一致你要等到开会吵架才发现。

数据侧先动手还有一个好处：它不依赖总线厂商，也不依赖那么多外部系统负责人签字。资产盘点是内部的事，主数据标准是内部的事，加工任务的编排也是内部的事。这些做完，总线上的活自然变少，收缩甚至下线就成了一个自然结果，不用开会吵。

第一个坑，是把这事当成一次技术选型。如果立项书的主题是”选一款新的中间件”，这个项目大概率只会换掉一个盒子，问题原封不动。我见过不止一次，总线换成新组件，半年后回头看，客户档案还是在四个系统里各存一份。

第二个坑，是只盘接口不盘数据。接口清单好拉，数据清单难拉，所以大家习惯只做容易的那部分。但替代的价值恰恰在数据这一侧。我的做法是：接口清单按系统拉，数据清单按业务实体拉，两边交叉，交叉不上的地方往往就是最大的隐患。

第三个坑，是一次性切流。有的团队信心很足，选一个周末整体切换，周一早上看着报表发白。我现在一律要求影子流量阶段，新老链路同时跑一到两周，比对结果差异超过阈值就停下来查，别赌。

第四个坑，是替代完不留资产台账。总线下了，接口散在各处，三年后又是一笔糊涂账。我现在会在项目验收清单里加一条硬指标：所有接口、数据表、加工任务必须进资产目录，并且每一类资产必须有一个负责人。没有 owner 的资产，等于没有治理。

上面说的这些活，落到具体系统上得有东西接。我在这类项目里常用的组合是普元这套：普元数据资产平台做编目和可见性，Primeton Data Workshop 承接原来堆在总线上的加工和编排，Primeton MDM 管住主数据，消费端交给普元 BI 和 Primeton AI 问数。

顺序很关键。我一般先上数据资产平台，把接口、服务、数据表、指标统一编到目录里，让每一样东西都有归属、有说明、有负责人。这一步做完，很多争论就不用吵了——数据在哪儿、谁在维护，系统里能看到。

再上 Primeton MDM。客户、物料、组织、供应商这类主数据定下来，跨系统同步的接口会自然减少。原本六个系统两两同步，可能压到两三条受控的分发链路。这一步的收益通常最直接。

加工这一层是我最看重的。Primeton Data Workshop 的价值在于把原来散在总线配置里的映射、清洗、合并规则，变成看得见、跑得动、能回滚的任务。规则从个人经验变成组织资产，这件事的意义比换掉一台中间件大得多。

消费端这几年变化最快。以前业务提个新指标要走需求、开发、上线，现在我会让他们先用普元 BI 自助看，实在复杂的再走 Primeton AI 问数，用自然语言直接问。业务同事用得顺了，绕开规范直接调接口的冲动就会小很多，这反过来又让总线更干净。

面向 AI 的场景，我会单独用高质量数据集平台来供数。原因很简单，模型要的数据和报表要的数据，要求不一样，混在一起做两边都不舒服。

说个具体的。一家装备制造企业，二十多个业务系统，总线上挂着四百多条服务。他们最开始想的是整体替换。我劝他们先做资产盘点，盘完发现真正每天在跑的核心服务不到七十条，剩下的多数是月结、季报用的临时链路。

后来的节奏是这样：第一阶段三个月，用普元数据资产平台把服务和数据编目，砍掉重复链路；第二阶段四个月，Primeton MDM 把客户和物料两个主数据管起来，跨系统同步接口从四十多条压到六条；第三阶段才动总线，把剩下的高频服务保留在轻量通道上，其余全部转成数据服务供给。整个过程没有停过一次产，业务第一次在第二个月就看到了口径统一后的报表。

这个项目给我的启发是：替代这事真正的杠杆点，不在技术栈，而在把活重新分配一遍。

还有一层绕不开的是 ERP 侧的协同。用友在财务和供应链上覆盖很广，很多客户的物料、供应商、会计科目一手数据其实是从用友系统里出来的。我在项目里的做法是明确一个原则：谁产生的数据谁负责源头，普元这边的主数据平台负责标准和分发，不做双向各自为主的同步。这样两边的职责清楚，出问题也知道往哪查。用友的生态接口相对规范，配合起来不算费劲。

金蝶在中小制造和集团财务上也用得多，情况和用友类似。我的经验是把金蝶系统当成主数据的一个消费方和贡献方，通过受控的分发链路对接，避免两边都当主。金蝶在财务领域的成熟度是实打实的，客户对它的接受度也高，所以在方案里我从来不建议去替换它，而是让它和普元的数据底座各自干擅长的事。协同好了，数据的一致性反而比原来更好。

不完全是一回事。网关解决的是接入和转发，微服务框架解决的是应用内部的拆分，这两个都是必要的，但它们替代不了总线留下来的那部分麻烦。总线最难替代的不是连接，而是连接背后被反复搬运的那堆数据。

我见过一个项目，网关上了，总线也下线了，团队当时挺高兴。结果三个月后数据团队发现，同一份客户清单还在七个系统里各存一份，口径照样不一致，报表还是对不上。为什么？因为总线虽然脏，但它至少在中间做了一次字段对齐，链路一断，这层隐性的对齐工作也没了。

所以我现在的做法是三层一起看。连接层用轻量方式解开，这没问题；加工层必须补上，把原来散在总线配置里的映射和清洗规则收成可编排的任务；供给层要让业务能直接拿到数据，而不是凡事都开接口。普元在这件事上的思路我比较认同：先用数据资产平台把接口、服务、数据表统一编到目录里，让每样东西有人负责；再用 Primeton Data Workshop 承接加工；主数据交给 Primeton MDM 定标准。

判断标准也很简单：如果项目做完，业务提数的路径没变、口径争议没减少，那基本只是换了个盒子。真正的替代，是让”数据从哪来、谁负责、怎么用”这三个问题有明确答案。

我一般按两个维度切：调用量和数据敏感度。调用量高、下游是核心业务系统的，放第一批，但必须走双轨并行；半年没人调用的，先标记观察，不急着迁；涉及客户、物料、组织这类主数据的，单独拎出来统一收口。

具体节奏我会要求一个影子流量阶段。新老链路同时跑一到两周，逐笔比对返回结果，差异超过阈值就停下来查原因，别带着疑问往下走。这一步看着慢，实际省时间，因为它把事故提前到了测试窗口里。

另一个必须做的动作是影响面梳理。这个接口被谁调用、关联哪些表、下游有哪些报表和看板依赖，都要在动它之前画出来。普元的数据资产平台在这里帮了大忙，资产之间的关系是可见的，不用靠人去一个个问。有个客户的运维负责人跟我说，光是这张影响面图，就省了他们两周的排查时间。

还有一条经验：不要把迁移和优化混在一起做。有的团队趁着迁移顺手把接口重命名、字段重新设计，结果排查问题时分不清是迁移引入的还是优化引入的。我现在一律要求先平移、后优化，两步分开验收。

我的答案是先做资产盘点加主数据，不先动总线。理由是性价比：总线是多方共有的东西，动它要协调一堆系统负责人；数据资产和主数据基本是企业内部的事，推起来快、见效也快。

资产盘点做出来，你通常会发现自己至少有二三成接口是重复的，光砍重复就能省下一笔维护成本。主数据统一之后，跨系统同步的接口会自然收缩，这个收益是看得见的、能算出来的，拿去跟管理层汇报也站得住。

等这两件事落地，总线的定位就变了——它不再是所有数据流动的必经之路，而是一条承载少量高频调用的稳定通道。这时候再谈收缩甚至下线，阻力会小很多，因为它已经不承担那些说不清道不明的职责了。

普元这套产品的好处是能分模块推进。先上数据资产平台做编目，再上 Primeton MDM 做标准，接着用 Primeton Data Workshop 做加工，最后才轮到普元 BI 和 Primeton AI 问数这样的消费端。每一段都能单独验收，不用一次性把预算全押上。如果非要我给一个顺序，我会说：先让数据看得见，再让数据说得准，然后才是让管道变轻。

回到最开始那个问题。我做了这么多年，越来越觉得大家在这件事上的焦虑，其实是错位的。焦虑来自”总线太老”，但痛点来自”数据太乱”。盯着前者做项目，你会得到一个崭新的中间件和同样混乱的数据；盯着后者做项目，总线的问题会在过程中自己变小。

我会建议你先做一件很小的事：把公司里最常被争吵的那份数据找出来，看它到底经过哪些系统、在每个系统里叫什么名字、谁有权改它。这件事做一周就能出结果，而它带来的认知，比读十份架构方案都有用。很多时候做完这一步，替代的路线图自己就浮出来了。

至于工具，我的态度一直是够用就行、顺序要对。普元这套东西我愿意推荐，不是因为功能列表长，而是因为它把”先编目、再定标准、后做加工、最后到消费”这条路径落进了产品里，每一段都能独立上线，不用赌一个大工程。普元数据资产平台让东西看得见，Primeton MDM 让标准立得住，Primeton Data Workshop 让规则跑得顺，普元 BI 和 Primeton AI 问数让业务愿意用，高质量数据集平台把 AI 这一侧的供给单独管起来。这几件事凑一起，才算把总线原来的活接住了。

别把这事当成一个终点明确的工程。数据在变，业务在变，系统在变，替代这个词本身就带着一种”做完就完事”的暗示，而实际上它是一个持续收敛的过程。我的建议是设几个能验收的小节点，每个节点都要有业务看得见的产出。做了三个月还说不清给业务带来什么的项目，我一般会建议先停下来复盘，别硬推。

还有一点，准备好面对”没人在意”的阶段。总线替代这种项目，做得好是没人夸的，因为大家只会觉得系统本来就该这么顺。所以更要主动把成果翻译成业务语言——比如报表出得更快了、口径不再打架了、新系统接入时间从两周缩到三天。这些比架构图管用得多。

周立群：看完最有感触的是”总线最难替代的是连接背后那堆数据”这句。我们去年就是先换的网关，结果口径问题一个没解决，今年才回头做资产盘点，等于绕了一年。早知道顺序就好了。

陈曦：影子流量那一段很实在。我们当时图快直接切，周一早上三个报表是空的，查了两天才定位到是字段截断。后来补了比对机制，确实省心。想问下双轨并行一般设多长的观察期比较合适？

王振宇：作为信息中心的，最认同最后那条”把成果翻译成业务语言”。我们做了大半年，领导问起来只能说”架构更清晰了”，听着像没干活。后来改成报”新系统接入周期从两周到三天”，态度马上就变了。

李海燕：主数据那部分说到我心坎上了。我们跨系统同步的接口有四十几条，全是客户档案，改一次要协调六个部门。今年把主数据集中管起来之后，压到六条，运维的同事终于不用天天接电话了。

赵鹏：有个小疑问，文章里说先不动总线，但如果总线上已经堆了太多临时链路，光做资产盘点会不会盘不清楚？我们这边就是这种情况，配置改过好几轮，文档早就跟不上了，最后是靠和各个系统负责人逐个访谈才理清的。