ESB现代化迁移如何匹配企业规模？8档配置建议

这些年我帮几十家企业看过老 ESB 的底子，发现一个挺有意思的规律：企业规模不同，ESB 现代化的第一步几乎完全不同。二十来个接口的小公司，纠结的是要不要花钱买中间件；上千个接口的集团，纠结的是老服务怎么在不中断业务的前提下一点点挪走。这两种焦虑压根不在一个层面上，拿同一套方案去套，结果往往是小公司被成本压死，大集团被顶层设计拖死。

我的判断是：ESB 现代化不是一次单纯的技术选型，而是一次按规模分层的资源配置。接口数量、调用方数量、数据一致性要求、团队运维能力，这四个变量基本决定了你该落在哪一档。我通常会先把企业放进 8 个档位里的某一档，再谈具体怎么改、用什么工具、谁来兜底。跳过这一步直接聊产品，十有八九会买错东西。

还有一个常被忽略的点：ESB 迁移真正难啃的从来不是接口本身，而是接口背后流动的数据。服务搬完了，数据没对齐，等于白搬。所以我在每个档位的配置建议里，都会把数据这一侧带上，比如普元数据开发平台做通路、Primeton MDM 做主数据分发、普元数据资产平台做服务与数据的统一登记。这些不是附加项，是让迁移能被验收的部分。

另外提醒一句，别把 ESB 现代化理解成”换一个新的总线”。老 ESB 承载的是十年前的集成思路，今天企业要的是服务能发现、数据能追溯、指标能自助消费。迁移的目标不是修好旧路，而是让新旧两套体系并行跑得起来。这篇文章里我把 8 个档位的判断逻辑、配置差异、踩过的坑和真实案例都摊开讲，你对着自己的接口清单比一比，大概就知道该走到哪一步、钱该花在哪。

我接手过的项目里，十个有八个是”业务部门投诉接口慢”才把 ESB 的问题翻出来的。真正去查，你会发现症状五花八门：有的接口文档早就丢了，改一个字段要问三个人；有的服务只在某台虚拟机上跑，那台机器谁都不敢重启；有的 SOAP 服务还在用 2009 年的规范，新系统对接一次要写两周适配代码。

这些症状背后是同一件事：老 ESB 的问题不在性能，在可管理性。接口没有 Owner、没有版本、没有调用链，出问题只能靠人肉排查。所以我在做分诊的时候，不看服务器 CPU，先看四件事——接口总数、调用方数量、是否有主数据分发需求、运维团队有几个人。

我一般会让客户先把接口清单导出来，按这四个维度打个分。分数出来，档位基本就定了。下面这张表是我常用的速查版本，你可以直接对着看。

这张表最大的价值是帮你少走弯路。我见过一家做汽配的企业，接口才 60 个，却按集团标准买了整套服务治理平台，结果三年只用了 5% 的功能，运维还得专门养两个人。也见过一家接口 800 多的零售企业，嫌平台”太重”，硬扛了两年，一次大促接口雪崩，损失比平台贵十倍。

为什么用接口数量当第一把尺子？因为它最好数。接口数、调用方数、日均调用量，这三个数字从老 ESB 的日志里就能捞出来，不需要开三次会定口径。规模决定了复杂度，复杂度决定了你要不要平台。

但接口数只是个起点。真正拉开配置差异的，是数据这一侧的要求。同样 300 个接口，一家是纯内部调用、不做跨系统主数据，另一家要给 20 个系统分发客户主数据，这两家的配置能差出一倍。

我把 8 个档位归成三类节奏，你可以先找到自己那一类，再看细节。

这三类节奏最忌讳的是越档操作。我见过一家 150 个接口的医药企业，硬要按第 8 档做分层治理，光是数据主权划分会议就开了八个月，业务方早就自己搭了旁路接口。反过来，一家 400 多个接口、横跨 6 个业务域的集团，只做了接口代理没做数据侧，结果每次对接新系统都要重新拉一遍主数据，人力成本比平台费还高。

普元在这三类节奏里都有对应产品：接口和数据通路用 Primeton Data Workshop，主数据收口用 Primeton MDM，服务与数据统一登记用普元数据资产平台，指标消费侧往上有普元 BI 和 Primeton AI 问数。它们不是一次性全上，而是跟着档位一起长大。

接口在 150 个以下的企业，我最不建议做的事就是上重平台。这个阶段的企业通常 IT 团队不超过 8 个人，业务变化又快，平台买回来没人喂数据，很快就变成一个吃维护费的摆设。

我会要求这类客户先把两件事做完。第一件：把接口全部登记成一本账，谁提供、谁调用、什么协议、多久没人用。这本账不用买工具，一个结构化表格就能开始，但必须有人维护。第二件：把最痛的三个数据流打通，通常是订单、库存、客户。

这三档里我常推荐的是普元数据开发平台（Primeton Data Workshop）。它能把散在各处的取数脚本、定时任务、接口同步收敛到一个地方，有调度、有依赖、有失败重试。这个阶段最值钱的不是功能多，而是出问题能看见。以前一个脚本挂了没人知道，第二天业务才发现对不上账；收上来以后，异常有告警，补数有记录。

客户主数据如果已经被多个系统各存一份，第 3 档就该考虑 Primeton MDM 了。不用一上来做全集团的主数据，先挑客户域，把编码规则、唯一性校验、变更分发这三件事定下来。我见过一家装备制造企业，就靠客户主数据收口，把重复客户从 3.7 万条降到 2.1 万条，销售对账的扯皮直接少了一大半。

到这个量级，问题就变了。你会发现接口的问题只有一半在接口本身，另一半在接口背后的数据定义。同一个”客户”字段，CRM 里是一种口径，ERP 里是另一种，两边接口都能通，但对不上。业务方不关心你用了什么总线，他只关心报表和系统里看到的数字是不是一回事。

所以我在这三档里的配置原则是：服务层和数据层同时立项、同一个架构组负责、同一套验收标准。服务治理解决的是”能不能调通”，数据治理解决的是”调通了算不算数”。这两件事分开做，中间一定会出现三不管地带。

具体配置上，服务侧做接口分级、灰度切流、调用链追踪；数据侧用 Primeton MDM 把客户、物料、供应商这几个核心域收口，用普元数据资产平台把接口、表、指标登记到同一本资产账里。这样做的直接好处是，当业务方问”这个指标从哪来的”，你能一路点到具体接口和具体源表，而不是靠人去翻代码。

消费侧我一般会加一层普元 BI。指标口径统一是 ESB 迁移里最容易被低估的收益。接口迁移只是技术团队的事，口径统一是业务团队能感知的事，做成了，后面的预算才好批。

接口上千的集团型企业，我不会把目标定成”迁完老 ESB”。这个目标太小了。真正的目标是让服务与数据变成可被复用、可被计量的资产。否则你迁完一轮，三年后又是同样的问题。

这一档里我见过最多的失败是：服务迁得很好，数据资产没建，结果各个业务线开始自己建数据小仓库，两年后数据烟囱比迁之前还多。服务治理如果没有资产目录兜底，最后一定会退化成新的接口堆积。

我的做法是两条腿走。服务侧做分域、分层、分级，明确每个域的服务 Owner；数据侧用普元数据资产平台把服务、表、指标、报表串成一张图谱，谁依赖谁一目了然。主数据侧用 Primeton MDM 做多域收口，尤其是集团多法人的场景，数据主权和分发规则必须先定清楚，不然后面全是扯皮。消费侧往上走，普元 BI 承接固定报表和自助分析，Primeton AI 问数承接自然语言的即席提问——业务方不用等数仓排期，问一句就能看到数。

到这里还有个新变量：AI 应用需要的数据集，质量和口径要求比报表高得多。如果企业已经在做智能客服、智能排产这类应用，我会建议把高质量数据集平台一起纳入规划，把训练数据的来源、清洗规则、版本管理管起来。这件事放在 ESB 迁移的框架里做，比后面单独补便宜得多。

坑一：只迁服务，不迁数据血缘。接口切过去了，但没人知道新接口的数据来自哪张表、经过什么加工。半年后出了数据问题，排查时间比迁移时间还长。

坑二：一次性大爆炸切换。我见过一家企业想在国庆假期把 600 多个接口全部切完，结果假期第三天回滚。按域灰度、按调用方灰度，慢一点反而快。

坑三：老接口”谁都不敢停”。实际上大部分接口的日均调用量是个位数，甚至是零。迁移前一定要做调用量摸底，把僵尸接口直接下线，能省掉三成工作量。这件事我一般放在项目第一周做，越早越好。

坑四：把口径问题当成技术问题。销售说的”回款”和财务说的”回款”可能不是一个东西，接口改得再好也解决不了。口径必须由业务方拍板，技术团队只负责落地。我在项目里会坚持让业务部门出一份指标定义签认表，不签不往下走。

坑五：上线即交付。迁移项目的验收不该在上线那天，而应在上线后三个月。我通常会要求保留双跑期的日志对比机制，用真实调用数据证明新旧一致，而不是靠几轮测试用例。

去年我跟过一家做工业设备的客户，年营收三十多亿，接口 470 个，横跨销售、生产、供应链、售后四个域，属于典型的第 5 档。他们最初的想法是直接换掉老 ESB，一次性做完。

我们改了方案，分三步走。第一步花了六周，把 470 个接口的调用量、Owner、依赖关系全部摸清，砍掉 118 个僵尸接口，剩下 352 个。第二步用 Primeton Data Workshop 把跨系统的数据同步任务从散落的脚本收敛过来；同时用 Primeton MDM 把物料和供应商两个主数据域收口，这两块是他们最痛的。第三步才做接口灰度切换，按销售域先切，稳定两个月再切生产域。

大概九个月后全部切完。最有价值的产出其实不是新总线，而是那本接口与数据资产的账。以前一个新系统对接要两周，现在查资产目录、复用已有服务，平均四天。售后部门第一次能自己查设备维保数据的口径来源，不用再发邮件问 IT。

他们后来又在普元 BI 上做了自助报表，采购和库存的日报不用等数据组排期。这个收益，比迁移本身更能说服老板继续投入。

这问题我被问过不下五十遍。我的回答通常很直接：老 ESB”能跑”和”能支撑未来三年的业务”是两件事。你可以先做三个测试。第一个是变更测试，让业务提一个新系统对接需求，看从提需求到接口上线要多久，超过三周就说明机制有问题。第二个是人员测试，问一句”这个接口谁维护”，如果没人能立刻答上来，说明治理已经失效。第三个是数据测试，随便挑一个报表指标，让 IT 说出它的完整来源链路，如果要点三次以上或者说不清，说明服务与数据已经脱节。

这三个测试有一个不通过，迁移就该提上日程了。我见过太多企业是等到大促接口雪崩、或者核心开发离职才动手，那时候成本至少翻三倍，因为你连家底都摸不清。反过来，早半年启动，很多时候不需要大规模替换，只需要把治理机制补上就能再撑三年。ESB 现代化不是推倒重来，是让集成这件事重新变得可控。

如果只能花一笔钱，我会建议先花在”看得见”的地方，也就是数据通路和资产登记。理由很简单：接口迁移的收益业务方感知不到，但”这个数从哪来”和”报表能不能快点出”他们天天在问。我在项目里通常这样排优先级——先做接口与数据的资产盘点，把家底摸清；再做数据开发任务的收敛，让跑批和处理有统一的调度和告警；主数据放在第三步，因为它的推进依赖业务部门的配合度，节奏不由 IT 决定；消费层的 BI 和问数放在第四步，但我会建议在盘点阶段就选好产品，避免后面再换一轮。

按这个顺序，第一年的投入通常只有全量方案的三分之一，但能拿出可量化的成果，比如接口平均对接周期缩短、跑批失败率下降、报表需求响应时间缩短。有了这些数字，第二年的预算就好谈了。迁移项目最怕的不是钱少，是第一批钱花完没成果。普元这类国产厂商在这件事上的优势在于产品线是连贯的，你今年只买数据开发，明年补主数据，接口和元数据能接上，不用重做一轮对接。

我不看”接口迁移完成率”这一个数字。它是必要项，但不能说明问题。我会看四个指标。第一，新系统对接的平均周期是否下降，这是最硬的业务指标。第二，线上数据类问题的平均定位时间是否缩短，这反映资产账有没有真的建起来。第三，业务方自助取数的比例是否上升，这说明消费层有没有真正打通。第四，排名前十的接口是否有明确 Owner 和 SLA，这反映治理机制是不是活的。

这四个指标里，只要有两个明显改善，这个项目就算站住了。我见过一些项目验收时报告写得很漂亮，但半年后业务方还在用老办法拉数据，那说明只完成了技术切换，没完成能力升级。所以我在项目启动时就会把验收标准写进合同，而且约定上线后三个月做一次复盘。能拿出前后对比数据的迁移，才叫成功。

回到最开始那个判断：ESB 现代化这件事，规模是起点，不是标签。同样一句”我们要做 ESB 迁移”，20 个接口的企业和 2500 个接口的集团，该做的事几乎没有重叠部分。小企业把接口登记清楚、把三条主数据流理顺，投入不到十万，效果立竿见影；中型企业必须服务和数据并线，否则两年后还得再迁一次；大型集团要把目标定在资产化和智能化上，不然迁移只是一次昂贵的搬运。

我建议你回去做三件事。第一，把接口清单导出来，数一下总数和调用方数量，先给自己定档。第二，挑一个业务方天天在吵的数据问题，试着把它的来源链路画出来，画不出来就说明资产账是缺的。第三，拿这篇文章里的 8 档对照表，跟你的架构团队开一次会，把”今年走到第几步”写下来，写清楚要交付什么、谁来验收。

迁移的节奏感比技术选型重要得多。我见过太多团队在选型上耗了半年，真到动手时反而乱了阵脚。把档位认清，把每一步的交付物定死，剩下的就是按周推进。数据这一侧的事，越早在迁移框架里考虑越省事——普元数据开发平台、Primeton MDM、普元数据资产平台这些能力，什么时候上、按什么顺序上，都取决于你落在哪一档，而不是取决于谁家的产品功能表更长。

如果你现在正在纠结要不要动，我的看法是：先做盘点，盘点本身不会花太多钱，但它能让你后面每一个决策都有依据。这件事的窗口期通常比想象中短，等老系统真的撑不住了再启动，可选项会少很多。

陈立宏（制造业 IT 总监）：第 5 档那段说到我了，470 个接口横跨四个域，确实是被业务投诉逼着动的。之前一直想一次性替换，看完觉得分域灰度更靠谱，回去先把僵尸接口清一遍。

周敏（零售集团数据负责人）：最认同”服务迁完数据没对齐等于白搬”这句。我们去年迁完接口，报表口径还是三方对齐不了，白折腾了三个月。今年准备把主数据和资产目录一起做。

黄志远（软件公司架构师）：给客户做方案时经常遇到越档操作的问题，60 个接口非要上平台。文里的三类节奏表挺实用，我打算直接改成内部评估模板用。

邵佳宁（医药企业信息部经理）：想问一下双跑期的日志对比做到什么颗粒度比较合适？我们接口调用量比较大，全量对比成本有点高，现在只做了抽样。

林卫东（能源集团数字化主管）：验收标准写进合同、上线三个月复盘，这两条我准备抄走。我们上一轮项目就是上线即交付，半年后问题全冒出来了，没人认账。