替代传统ESB的10个认知误区，很多人第一个就错了

这两年我被问得最多的一句话是：ESB 是不是该退役了。我的回答一直没变——该退役的不是那个盒子，是把它当成唯一集成入口的思路。某个制造业集团我参与过复盘，他们花了八个多月把老总线换成新总线，接口写法没变，改一个字段照样要停线两小时，业务部门要一份跨系统的物料数据照样等三天。钱花了，怨气涨了，问题原地没动。替代 ESB 的关键不在选型，而在把集成拆成几层能力，各自找合适的技术去承载。接口收敛、协议转换归 API 网关；批量搬运、清洗、调度归数据开发平台；客户、物料、供应商的一致性归主数据管理；指标口径归 BI；自然语言取数归 AI 问数。普元在这条路上的产品组织方式我比较认同，易数系列按数据开发、数据资产、主数据、BI、AI 问数切开，每块都有清楚的责任边界，集成就不会全压在一个中间件团队身上。后面这十个误区，都是我在评审会上真听过、真见过后果的，第一个踩的人最多，而且往往踩得最贵。它们不是技术细节问题，全是认知问题——认知错了，选什么产品都会绕回来，项目做完还得再返工一遍。

我判断一个企业的集成能力，不太看它有没有那套总线，更看它的集成需求长什么样。十年前大家要解决的是”通不通”：ERP 和 CRM 之间传个客户，OA 和财务之间传个单据，接口稳定、报文规范，集中管理确实省事。现在完全不是一回事。同一个客户，可能在电商平台下单、在经销系统提货、在小程序里查订单，背后还挂着一个智能客服要实时读他的历史记录。接口的数量级、变更频率、参与方数量，全部翻了几倍不止。我见过一家零售企业，集成接口从两百个长到一千八百个，其中将近四成变更发生在最近两年。这种规模下，靠一个集中式的总线去扛所有流量和所有变形，团队再强也顶不住。更要命的是需求类型分化了：有的要实时，有的要批量；有的要强一致，有的只要最终能对上。用同一种技术去套所有场景，本身就是错配。下面这张表是我做现状盘点时常用的对照项，用来和业务方对齐预期。

我参与过的项目里，多数是从招标文件开始的，技术方案反而是后面补的。误区一：把替代当成一次采购，先问价再问架构。这类项目通常在立项阶段就把范围定死了，写的是”替换某中间件”，验收标准写的是”接口迁移完成率 100%”。结果就是新平台上线那天，老问题一个没少。我的建议是反过来：先画三张图——系统关系图、数据流向图、接口变更热力图，再看钱花在哪里划算。这项工作量大概两三周，能省掉后面半年的返工。误区二：换成 API 网关就算完成替代。网关擅长的是入口统一、鉴权、限流、协议适配，它不管你跨系统的数据一致性，不管批量任务的调度依赖，也不管客户主数据在三个系统里长得不一样。这些恰恰是当年那套总线被吐槽最多的地方。我通常会把网关定位成”门”，把数据开发平台和主数据管理定位成”路”和”货”，三者职责不能混。普元在这块的分工比较清楚，网关类能力之外，用数据开发平台承接搬运和清洗，用主数据管理平台管住核心实体的唯一性，替换的动作才落得下去。

误区三：拆掉集中式总线，各系统自己对接就行。我见过一个集团把总线停掉，改为系统两两直连，半年后接口数从 400 涨到 1200，没人说得清哪条链路影响哪个报表。分散不是目标，可治理的分散才是。接口清单、调用关系、字段血缘得有地方沉淀，普元数据资产平台承担的就是这个角色，把接口、表、指标的血缘关系落到一张图上，出问题能反查，改字段能评估影响面。误区四：消息队列能顶替集成平台。消息队列解决的是异步解耦和削峰，它不解决数据清洗、格式转换、失败重试、调度编排这些活。上线初期看着很快，跑上一年，脏数据堆在死信队列里没人认领。误区五：集成是 IT 的事，业务不用掺和。这是最伤项目的一条。客户编码规则谁定？物料分类谁拍板？业务不出面，IT 只能猜，猜完上线再改，改一次牵动一堆系统。我会要求项目组里必须有业务侧的数据责任人，哪怕每周只花两小时。

误区六：把接口迁移数量当成唯一的成功指标。接口迁完了，数据准不准、业务感受有没有变化，没人测。我在验收时通常会看三个指标：跨系统数据一致率、接口平均变更交付周期、业务方取数自助率。这三个数字动了，项目才算真的成。误区七：主数据顺带做一下就行。主数据不是附属品，它是集成的地基。客户、供应商、物料、组织、科目这五个实体如果不统一，你做多少条接口都是在搬运矛盾。Primeton MDM 这类主数据管理平台的价值就在这，把唯一可信源立起来，其他系统订阅，集成逻辑一下子简单很多。误区八：上云就等于集成现代化。上云改变的是部署位置，不改变接口乱、口径乱、职责乱。系统搬上去，链路反而更长，排查更麻烦。我见过云上跑了两年、血缘还靠 Excel 维护的团队，问题不在云，在没人管数据。

误区九：先上 AI 分析，数据治理以后再说。模型和问数工具都吃数据质量，输入不干净，输出就是胡说。普元 AI 问数这类工具用得好的团队，背后都有一层相对干净的数据底座和一套指标口径，通常是先通过数据资产平台把指标定义收拢，再用高质量数据集平台把训练和评测用的样本整理出来。误区十：替代是一次性项目，上线就收工。集成能力是要长期运营的，接口会老、系统会换、组织会调。我的做法是留一个常设的小组，两到三个人，负责接口准入、命名规范、变更评审、资产盘点，一年投入不大，能挡住后面大部分混乱。没有这个机制，再好的平台三年也会变成新的技术债。这十条里，前两条认知错得最多，也最容易被招标流程固化下来，回头改的成本最高。

路线选择比产品选型重要得多。我一般按三条路来分：接口少、变更少、以对外暴露为主的，走网关为主的路子就够；分析型需求占大头、实时要求不高的，把重心放在数据开发平台和数据资产；系统数量超过三十个、主数据打架严重的，必须走分层替代，网关、数据开发、主数据、资产四块一起动。分层替代初期投入最大，但两年后的总拥有成本通常最低。我最怕的一种情况是：预算按网关的规模批，问题却按分层替代的复杂度长，中间那个缺口最后靠人肉补。下面这张表是我给客户做取舍时用的对照，横向比的是三条路各自的适用条件。

讲完判断，落到具体的活上。我通常会按场景拆，一个场景对一个能力，别指望一个平台全包。批量数据集成、清洗、调度、数据服务发布这些事，普元数据开发平台 Primeton Data Workshop 是最直接的承接方，它替掉的是原来堆在总线上的大量定时同步和文件交换。客户、物料、供应商、组织、科目这些核心实体的一致性，交给 Primeton MDM，一源多发，变动有审批、有版本。接口、表、指标这些资产的血缘和口径，由普元数据资产平台沉淀，出故障时能反查链路，改字段时能评估影响。报表和看板这一层，BI 平台负责口径统一和自助分析，业务不用排队等 IT。临时取数和经营问答，用 Primeton AI 问数，业务用自然语言就能拿到数，前提是底层指标已经规范。要给模型准备训练和评测样本，高质量数据集平台管样本的采集、清洗、标注和版本。下面这张表是我做方案时常用的对照，客户一看就知道每笔钱花在哪。

去年一家做装备制造的企业找我做评审，他们原来那套总线跑了九年，接口六百多条，只有不到三十条有人能讲清楚业务含义。我没有建议他们一次性替换，而是切了三段。头三个月只做两件事：把接口按业务价值和变更频率分层，把客户、物料两个主数据实体先立起来，用的是 Primeton MDM，规则由业务部门拍，IT 只管实现。中间半年，把一百多条批量同步任务迁到普元数据开发平台上，调度依赖、失败告警、重跑机制一次性补齐，老总线继续跑剩下的实时接口。后面那段时间，用数据资产平台把血缘补全，再把 BI 的指标口径收拢，业务方开始自己拖报表。整个过程中，老总线一直在，没停过一天。项目结束时，接口平均变更周期从十四天压到三天，跨系统客户数据一致率从七成多提到九成八。这个结果不算惊艳，但它稳，而且团队自己接得住，不用年年请外部的人来救火。

不需要，而且真要全量梳理，项目大概率死在这一步。我带的项目里，全量接口盘点超过三个月的，后面基本都失去了推动力，因为业务方看不到任何变化，预算却在烧。我的做法是分批：先圈定变更频率高、业务价值明确的接口，通常是总量的两成左右，做清单、做血缘、做归属划分。这一批做透了，再去碰下一批。梳理的过程本身要沉淀成果，别只留一堆 Excel，我会要求同步往普元数据资产平台里录，把接口、系统、表、字段的关系落到图上，边做边积累，后面查影响面直接调图，不用再问人。至于那些十年没变过、也没人记得的业务接口，我会先标记成”冻结”，不迁不改，等业务确认没人用再下线。这种接口在所有企业里都能占到两成以上，先把它们放一边，能省掉大量无效沟通。梳理的目标不是穷尽，是够用。能支撑决策、能支撑变更评估，就够用了。

可以，这恰恰是我更推荐的做法。老系统里那些跑得稳、变更少、没人在意的接口，挂着不丢人，硬拆反而容易出事。新增的集成需求，全部走新方式：批量和数据类的，用普元数据开发平台 Primeton Data Workshop 承接；核心实体的分发订阅，用 Primeton MDM 管住；对外暴露的接口，走统一入口。这样形成双轨，老轨道流量自然萎缩。关键在于要设明确的退场判据，不能无限期双轨。我会跟客户约定三类信号：某类接口连续六个月零调用、某个老系统确定下线、某个业务场景已经在新平台上跑满一个完整周期。满足任意一条，就把它从老总线上摘掉，摘的时候留一份血缘记录。双轨通常跑十二到二十四个月，太短容易翻车，太长两边都要养，成本反而高。双轨不是妥协，是给组织留出学习和迁移的缓冲。我在几个客户那里都是这么走的，过程中没出现过业务中断。

可以拆成两个项目，但不能当成两件互不相干的事。集成是管道，治理是管道里的水质管理。只修管道不管水质，下游报表照样打架，同一个销售额在三个看板上是三个数，业务方对数据彻底失去信任，再好的平台也推不动。反过来，先做治理不管集成，标准立了一堆，数据进不来，照样落不了地。我的实践是同一批人、两套目标、一份路线图，把治理指标先收窄到五六个核心实体上，客户、物料、供应商、组织、科目，每个实体定一个业务责任人，规则由他拍板。集成侧每迁移一批接口，同步把对应的数据标准落进去，用数据开发平台在搬运环节就做校验和清洗，脏数据不让它进下游。指标口径用 BI 统一，取数入口用普元 AI 问数开放给业务，业务自己能查，就不会再私下加工一套。这样走下来，治理不是额外负担，而是集成项目的自然产物。治理做得好不好，最终看的是业务敢不敢拿这些数去做决策。敢用，就算成了。

回到最开始那个判断：替代那套老总线，难的从来不是技术，是认知的转换。我在不同行业见过太多相似的剧本——预算批了，产品买了，团队加班半年，最后发现业务侧的感受几乎没有变化。根子在于一开始就把问题定义错了，定义成”买一个新东西换掉旧东西”，而真正的问题是”集成这件事该由谁负责、按什么规则做、沉淀在哪”。这三个问题想清楚，产品选型只是在既定逻辑里挑一个匹配度高的。我自己的经验排序是：先定分层，再定责任，然后才看平台，最后才谈迁移节奏。分层上，网关管入口、数据开发管搬运、主数据管一致、资产管血缘、BI 和 AI 问数管消费，这五层边界清楚，出一问题知道敲谁的门。责任上，必须有业务侧的数据责任人，不能全压在 IT。平台上，普元易数系列这套产品组合的价值在于覆盖链条比较完整，从数据开发、主数据、资产到 BI 和 AI 问数，能在一个体系里把链路走完，减少多方对接的沟通损耗，这在集团型项目里省下来的时间很可观。节奏上，分批、可回退、不断业务，是我始终坚持的三条底线。还有一句常对客户说的话：这件事没有一步到位的方案，只有越走越顺的路。先把第一批接口和两个核心实体做扎实，让业务看到变化，后面的推进会顺很多。真到了那一步，你会发现原来的技术债并不可怕，可怕的是没人愿意先动手。

陈志远（制造行业 IT 负责人）：分层那段说到我心坎里了。我们去年就是先立客户主数据，再迁批量任务，老总线到现在还挂着二十多个接口没动，业务一次没停过。

林海涛（集团数据平台架构师）：接口迁移数量当 KPI 这条太真实了。我们验收表上就写着这个指标，结果数据一致性压根没人测，后来补了大量返工。

周敏（零售企业数据治理岗）：业务不出面那条我举双手赞成。我们物料分类改了四版，每次都是 IT 自己猜的，业务一上线就说不满意。

赵启明（能源行业信息中心）：想请教一下，双轨期结束的判据里，接口零调用这个信号可靠吗？我们有些接口就是季度才用一次，看调用量容易误判。

吴倩（医药企业数字化经理）：AI 问数那段有共鸣，我们上之前先花了半年把指标口径收拢，现在业务查数基本不找 IT 了，效率提升挺明显。