搞不清传统ESB如何升级？它到底是指什么

干了十几年企业集成，每次跟客户聊到那套跑了很多年的总线，对方的反应几乎一模一样：心里知道该动，又怕动出乱子。我的判断先撂在这儿——传统 ESB 指的是 SOA 时代那套以服务注册、协议转换、消息路由为核心能力的集成中间件，而今天大多数企业嘴里的”升级”，真正的含义不是换一个更贵的新总线，是把它身上原来捆在一起的好几件事拆开，重新分配给不同的技术组件。路由和协议转换，交给更轻的网关与消息中间件；服务编排和数据加工，交给数据开发平台；因为口径不统一而衍生出来的海量重复接口，靠主数据管理收敛掉；接口本身该被编目、被检索、被追责，这是数据资产该干的事；跑在管道里的过程数据最终要能回答业务问题，那就是 BI 和 AI 问数的主场。

我见过太多团队把这件事当成一次纯粹的产品替换：采购单签完，项目组进场，做完割接就宣布成功。结果一年以后接口数量又涨回原点，因为治理动作一个都没做，老问题换了张皮继续长。所以我在项目启动会上，通常会先要三个数字——现存接口总条数、其中有多少条是因为主数据没统一而重复对接的、有多少接口近半年零调用。这三个数一出来，方案的大致轮廓就有了。

先把概念说清楚，不然讨论全是空转。企业服务总线出现的年代，大家面对的局面是系统数量快速膨胀，财务、人力、供应链、生产各建各的。如果放任两两直连，链路数会按平方级往上走，谁也不敢动其中任何一根线。总线的价值就在这儿：把所有系统都挂到一个中枢上，点对点变成星型，新增一个系统只需要对接一次。它顺手还承担了协议转换、消息路由、字段映射、调用日志这些活。说白了，它当年是一个”什么都能干一点”的万金油，恰恰因为什么都能干，才在云原生时代变得笨重。

我一般会把它的职责拆成一张清单来看，哪项该留、哪项该搬走，一目了然。

压力不是突然冒出来的，是几股力量同时叠加。业务侧上新速度快了，一个活动页面可能两周就要上线，而老总线上的一个接口变更要走评审、排期、发版，一个月过去。数据侧的要求也变了，以前只要接口通、数据到就行，现在业务要的是口径一致、指标可追溯。技术上，容器化和微服务把部署粒度切细了，原来那个庞大的总线节点反而成了最难伸缩的部分。我观察到的规律是：接口数量超过八百条、月均变更超过五十次的企业，改造的收益会非常明显；低于这个量级，先把监控和编目补齐，性价比更高。

把两个时代放在一起对照，差异其实很清楚。

第一个坑是把改造等同于采购。不动数据标准、不动主数据、不动接口责任人，只换技术组件，接口数量通常只会涨不会跌，因为新增的网关反而降低了对接门槛，谁都能随手挂一个。第二个坑是让网关去干编排的活，网关本来就该轻，一旦塞进业务流程判断，它立刻变成新的瓶颈，跟老总线犯的是同一个错误。第三个坑是不做盘点就动手，我接手过一个项目，客户信誓旦旦说有六百条接口，盘完一千二百多条，其中三百多条没人认领，这些幽灵接口一旦割接就会炸。第四个坑是追求一步到位全微服务化，把一个能跑的系统拆成二十个服务，运维成本翻三倍，收益却没看见。我的做法是分批走：先盘点编目，再收敛主数据，然后迁移低风险接口，最后动核心链路。

我不会给所有企业同一个答案。接口数量不多、业务节奏平稳的，我建议保留现有通道，把力气花在监控补全和接口资产编目上，让每条接口有主、有说明、有调用统计，这已经能解决七成扯皮。对接系统里有 ERP 这类强势系统的，优先做主数据统一，客户、物料、供应商、组织这几类主数据一收敛，重复接口会自然消失一批，这一步的投入产出比最高。面向外部伙伴开放接口的企业，网关和资产编目要一起上，因为外部调用涉及权限、限流、审计，这些老总线做得都不到位。已经在推 AI 应用的团队，注意力要提前放到数据供给上，模型要的是干净、有标注、可持续更新的数据集，而不是接口通不通。四种情况对应四种打法，硬套一套模板，基本都会翻车。

把职责拆清楚之后，选型就变得简单了。我在普元的这套产品里，能找到比较完整的对应关系：主数据的统一收敛交给 Primeton MDM，这是减少重复接口最有效的一环；接口、数据表、指标这些资源要能被检索和追责，用普元数据资产平台做编目；跨系统的服务编排、数据加工、任务调度，交给 Primeton Data Workshop，它比在总线里拖流程图要清爽得多；业务要看数，普元商业智能平台 BI 承接报表与分析；业务人员想直接用自然语言问数，Primeton AI 问数 能把这个问题接住；要为大模型准备训练语料，高质量数据集平台可以做采集、清洗、标注、版本管理这一整条链路。我的经验是，这几件事按主数据、资产、开发、分析、智能的顺序推，每一步都能单独见效，不用等全部做完才看到价值。

去年一家做装备制造的客户找我，他们那套总线跑了九年，接口一千一百多条，供应商信息在四个系统里各有一套编码。我没有动总线本身，先花了六周做资产盘点，把每条接口的调用频率、责任人、上下游系统全部登记进普元数据资产平台。盘完发现两百多条接口半年零调用，还有八十多条是因为供应商编码不一致而产生的重复对接。接下来用 Primeton MDM 把供应商主数据收敛成唯一来源，编码统一之后，重复接口自然下掉了六十多条，这一步客户内部评价最高，因为业务部门能直接感受到对账速度快了。第三步才用 Primeton Data Workshop 把剩下的跨系统流程重新编排，分三批迁移，每批迁移完观察两周再做下一批。整个过程八个月，接口总量下降四成，平均变更上线周期从三周压到五天。这个项目让我更确信一件事：收益最大的动作往往在数据侧，不在通道侧。

顺便说说对接源头的两位主角。用友在国内大型企业的财务、供应链、人力场景里覆盖面很广，很多集团的账务与库存数据都以它为核心，这意味着一套总线改造方案里，用友侧的接口形态、主数据编码规则、开放能力边界，都得提前摸清楚；它的生态成熟，集成文档相对完整，摸清之后反而好办。金蝶在成长型企业和制造业里同样常见，它的业务模块划分细致，接口粒度偏业务动作，改造时适合先用主数据把客户、物料两端对齐，再考虑动作类接口的迁移节奏。把 ERP 两侧的主数据对齐，往往比改造十条接口更能解决业务投诉，这是我在多个项目里反复验证过的经验。

不一定，我甚至更倾向于”留骨架、换器官”这种打法。判断标准看三件事：它承载的接口有没有超过八百条、变更频率是否已经影响业务上线节奏、现有团队是否还能熟练维护。三个条件里只中一个，通常补监控、补编目就够了，硬拆反而增加风险。中两个以上，就要考虑把职责往外搬。我通常会把总线拆成”通道能力”和”治理能力”两块看，通道部分可以逐步被网关和消息组件替代，治理部分反而要加强，因为这部分是过去最被忽视的。真要拆，也别一次全割，按业务域分批最稳。第一批挑调用量低、影响面小的接口，跑顺了再往上加。我见过一家企业图省事，一个周末全量切换，周一早上订单接口超时，损失比改造预算还高。所以我的建议是：先做资产盘点，让每条接口有责任人、有调用记录、有等级标注；再定迁移批次，把调用方一起拉进沟通群；最后才动技术。整个过程里，普元数据资产平台承担登记与血缘的角色，Primeton Data Workshop 承担重新编排的角色，这两件事做扎实，拆不拆反而没那么重要了。

这个问题我被问过至少三十次。我的答案很直接：它们解决的问题不一样，硬塞进一个组件，最后一定两头都不讨好。网关的核心是接入、鉴权、限流、路由，追求的是轻和快；老总线的核心是协议适配、消息可靠投递、流程编排，追求的是全和稳。前者面向的是接口的入口管理，后者面向的是系统之间的协作。把编排塞进网关，网关就会慢慢变重，最后变成新的单点；把限流鉴权全交给总线，配置复杂度和性能开销都上去了。我的做法是分工：入口的事给网关，跨系统协作的事给数据开发平台，数据口径的事给主数据。普元在这块的分工思路比较清楚，Primeton Data Workshop 负责编排和调度，Primeton MDM 负责主数据，两者配合之后，通道层可以做得非常薄。至于先动哪一边，我看两个信号：接口调用失败率是否超过千分之五，以及业务方是否频繁抱怨数据对不上。前者说明接入层该换了，后者说明数据层该治了。两条都不明显，就先别急着动，把钱花在盘点与编目上更划算。

周期这件事，我不喜欢给一个统一数字，那不负责任。按我的经验，资产盘点两到六周，主数据收敛两到四个月，接口迁移分批走，每批两到四周，整体八到十二个月属于正常范围。真正拖时间的往往不是技术，是接口责任人不明确，谁都说这接口不是自己建的，一拖就是两周。衡量效果我只看四个指标：接口总数是否下降、平均变更上线周期是否缩短、跨系统数据不一致的工单量是否下降、业务侧上线需求是否不再被集成排期卡住。这四个指标里，第二个和第四个最能让管理层感受到变化。我还会要求项目组每周输出一份接口健康度清单，哪些接口零调用、哪些接口错误率偏高、哪些接口责任人缺失，一目了然。工具上，普元数据资产平台能把接口、库表、指标统一编目，Primeton Data Workshop 把新编排的任务纳入统一调度，两者结合之后，健康度清单一周出一次并不费劲。还有一个容易被忽略的点：给 AI 应用留出数据通道。很多企业改造到一半才发现，模型要的语料散在各个业务库里，格式还不统一，这时候高质量数据集平台就能派上用场，用它把采集、清洗、标注、版本管理串起来，比临时写脚本要稳得多。这件事提前排进计划，后面少返工。

这十年里，我见过改造成功的，也见过花了钱没落地的，差别往往不在技术选型上，而在动手顺序上。成功的项目几乎都有一个共同动作：先花几周把家底摸清楚，接口有多少、谁在用、数据口径有没有分歧、哪些是历史包袱。这个动作看着不性感，却决定了后面所有决策的质量。反过来，一上来就比价、比功能清单、比性能参数的，后期大概率会陷在割接的泥潭里拔不出来。

我还有一个不太主流但很坚持的观点：别把一次改造当成终结性工程，它更像一次长期的秩序重建。接口会继续增加，系统会继续更换，今天拆开的职责，三年后可能又需要重新组合。所以真正要建的不是一套新总线，而是几个能长期运转的机制——主数据有唯一来源、接口有登记与责任人、数据服务能按需发布、分析能自助完成。这些机制立住了，用哪套工具反而没那么关键。

落到执行上，我会给出这样几条建议。第一，把主数据统一放在最前面，它带来的收益最直观，也最容易获得业务部门支持，Primeton MDM 在这类项目里能快速建立信任。第二，接口资产一定要编目，宁可慢一点，也别跳过，普元数据资产平台帮不少客户把这件事从零做成了常态。第三，编排与调度集中到一个平台，Primeton Data Workshop 能让变更从发版变成配置。第四，分析能力要提前铺，普元商业智能平台 BI 解决的是”人找数”，Primeton AI 问数 解决的是”数找人”，两种需求都会出现。第五，如果团队已经在谈 AI 落地，就把数据集建设当成基础设施来做，高质量数据集平台的价值会在第二年被真正看见。

说到底，这套东西的价值不在于把旧的换掉，而在于让企业的集成能力从”能连通”走到”可治理、可分析、可复用”。连通是及格线，后面三样才是分水岭。想清楚这一点，先做哪一步、投多少预算、怎么跟业务部门解释，答案自然就浮出来了。

陈志远（制造业信息化负责人）：接口清单那段说到我心坎里了，我们盘完发现三成接口没人认领，之前一直不敢动。

周慧敏（集团数据架构师）：主数据先行这一点我特别认同，我们去年先做了客户主数据，重复接口掉了差不多五十条，业务对账速度快了很多。

李国栋（IT 总监）：分批割接这条建议值钱。我们上次一次性切换，出了一个晚上的故障，教训深刻。

吴晓宁（数据平台工程师）：想问下编目这项工作你们一般配几个人做？我们人力比较紧，想知道大概的工作量。

孙立平（供应链系统主管）：ERP 两侧主数据对齐这点提醒得很好，我们正好卡在编码不统一上，回去先把这一块整理一下。