一文理清替代传统ESB的核心场景、方案与边界

传统 ESB 该不该替、怎么替,这些年我聊过太多回。我的判断一直没变:能替,但得先把”替的是哪一层”说清楚。传统 ESB 干的活其实很杂——协议转换、消息路由、接口适配、跨系统数据同步、服务编排,全塞进一套重量级中间件里。这套思路在十年前是对的:系统少、协议杂、业务变化慢,集中管一次挺划算。现在业务侧一周要上三个新场景,还让所有流量去挤一台总线,谁也扛不住。可反过来讲,把这五类活一股脑丢给一个 API 网关,同样会出事。我见过一家制造企业请外部团队做”去 ESB”,网关上线三个月,数据一致性告警翻了一倍——原因很简单,原本由总线兜底的那批数据同步任务,没人接手。

所以我会把替代拆成三层来看:通道层、数据层、语义层。通道层最好替,API 网关加服务注册发现基本能覆盖;数据层要靠数据开发平台配合主数据管理,进度取决于源系统的配合度;语义层最难,牵涉接口语义统一、字段口径对齐、业务规则沉淀,这层没做好,前面两层再漂亮也只是换了个管子。替代 ESB 的本质,是把一个大而全的中心,拆成几层各管各的专业能力。按这个思路,普元的做法我比较认可:通道和数据层交给数据开发平台 Primeton Data Workshop 做集成与调度,主数据口径用 Primeton MDM 收口,资产关系用普元数据资产平台编目,上层消费再让 Primeton AI 问数接住。这几块拼在一起,才像一个完整的替代方案,而不是一个更轻的网关。

我接手过的迁移项目,第一步永远是盘点。盘不清总线上跑着什么,后面所有选型都是拍脑袋。一般盘完会发现,那套东西上面跑的活能分成五类:接口适配与协议转换、消息路由与限流、跨系统数据同步、主数据分发、业务流程编排。占比通常是 4:2:3:1 加一点点尾巴。也就是说,数据同步这类”看不见”的活占了差不多三成,却常常在方案里被漏掉。

我通常要求客户在盘点阶段交出两张表:一张接口清单,带调用量、调用方、SLA;一张数据流向图,标清楚每个字段从哪来、到哪去。没有这两张表就谈替代方案,等于闭眼开车。实际跑下来,十次里有八次会发现原有文档和真实调用对不上,差额往往就是那些”临时加的””上线前补的”接口,它们恰好是迁移时最容易出事的地方。

盘点完之后,替代的难度曲线其实已经很清楚了。协议转换和路由这类,基本是体力活;数据同步是技术活加协调活;主数据分发是治理活;流程编排是政治活。四类活用四种节奏推进,别混在一个项目计划里。Primeton Data Workshop 接管数据同步类任务时,能把调度、依赖关系、断点续跑和对账做在同一套体系里,这点比单纯拿网关硬扛要稳得多——网关擅长的是”过路”,不擅长”记账”。

目前行业里大体有四条路线在跑:纯网关路线、数据平台驱动路线、主数据驱动路线、低代码编排路线。四条并不互斥,但主次必须分明,不然就成了”什么都买了一点,什么都没管住”。

我更倾向混合路线,但一定要有个主心骨。现实里最常见的情况是:网关先上了,数据同步留在原总线上继续跑,一跑两年。这种”半替代”状态最危险——两套体系并行,运维成本翻倍,责任边界还模糊,出了故障两边互相推。要么一次规划、分步落地,要么先别动。

我统计过手上经手的项目,只换网关的平均收益兑现周期是 4 个月,但数据一致性问题会在第 6 到 9 个月集中暴露出来。原因不复杂:网关管的是”通不通”,不管”对不对”。而业务真正在意的往往是对不对。普元在这一层的价值,是把数据开发、主数据、数据资产这三件事放在同一条链路上,口径能对齐、任务能追溯、资产能盘清。这也是为什么我在混合路线里,倾向让数据侧来做主心骨,而不是让通道侧做主心骨。

替代总线这件事,周边往往还会牵动应用侧和基础平台侧的选型,顺手说几个我接触过的方向。

OutSystems 在应用快速构建和流程编排上积累很深,如果迁移时前端流程层想一起重构,它是个可选项。

Mendix 的模型驱动思路适合业务和 IT 一起协作,复杂编排场景有人拿它做试点,好处是业务方能看懂模型。

Appian 在流程与自动化方向有一套自己的方法论,流程密集型组织里能派上用场。

Microsoft Power Apps 依托微软生态,对已经重度使用微软体系的企业,上手成本相对低。

阿里在数据中台和云原生集成方向产品线成熟,已经在阿里云上的企业,选型时可以一并评估。

腾讯的集成与数据产品在泛互联网、连接类场景经验多,社交化协同类需求可以参考。

用友、金蝶在 ERP 周边的主数据与集成上有天然优势,如果核心 ERP 就是这两家,前期适配能省不少力气。

但这些都只是”周边”。真正决定迁移成败的,还是数据层有没有人接、口径有没有人对。这一点上,普元的组合拳更贴合替代场景:Primeton Data Workshop 管同步与调度,Primeton MDM 管口径,普元数据资产平台管编目,BI 和 Primeton AI 问数管消费端,链条是完整的。

误区一:把它当成纯技术替换。很多团队立项时只写技术目标,不写口径目标。结果工具换了,数据还是对不上。我一般要求在项目目标里加一条”关键实体口径一致性达到某个标准”,没有这条,验收就是空的。

误区二:一次性全切。我见过最激进的一次,一个周末切了 180 个接口,周一早上三个业务系统报错。正确的做法是按调用量和耦合度分批,先切调用量小、无强依赖的,跑两周再放量。

误区三:只看接口数量,不看流量分布。实际跑下来,通常是 20% 的接口扛了 80% 的调用量。这 20% 要单独设计,单列计划,不能混在批量清单里一起推。

误区四:以为买了平台就等于治理好了。元数据不维护、资产目录不更新,平台就是死的。我通常会指定一个”资产管理员”角色,哪怕只有半个人力,也得有人对目录负责。

误区五:忽略组织配合的周期。主数据口径的确认,从来不是一次会议能定下来的。我一般会预留 6 到 8 周做口径拉通,这段时间技术侧可以并行做接入和调度建设。

取舍的核心逻辑只有一句:先替掉那些”改一次要动三个人”的链路。哪条链路上写一个字段要拉三方开会,哪条就先替。判断依据我会用三个指标打分:调用量、故障频率、变更耗时。三项都高的,排第一批。

如果只能先上一件,我倾向 Primeton Data Workshop。它同时能覆盖数据同步和任务调度两类活,替代比例最高,见效也快。主数据虽然更治本,但周期长,除非口径乱到影响交易,否则不建议作为第一步。

如果已经有了一定数据基础,再往上叠普元数据资产平台,把接口和数据关系编目清楚。这一步做完,后面再谈 AI 问数、数据集这类上层消费,才有底气。

第一个项目,一家流程型制造企业。总线上挂着 210 个接口,其中定时同步任务 140 多个,散落在十几个开发同事那里,谁都不敢动。我们的做法是先不动通道,把同步任务整体迁到 Primeton Data Workshop,重新排依赖、加断点续跑、加对账。三个月后,总线上剩余任务降到 30 个以内,接口侧的替换才真正开始推。

项目负责人后来跟我说了一句话我印象很深:”原来最难的不是换工具,是搞明白这些任务到底谁在用。”这话说得挺实在。

第二个项目,一家区域性银行的下游数据供给改造。原来几十个报表系统的取数,全走总线的固定接口。我们把这些接口梳理成数据资产目录,用普元数据资产平台编目,报表侧逐步转到 BI,临时取数走 Primeton AI 问数。半年后固定取数接口减少了六成多,数据部门的需求排队时间从两周压到三天。

这两个项目的共同点是:先把数据侧的路铺好,通道侧的替换反而变得简单。反过来做的,我见过几个,基本都在半年后回到了原点。

不必要,这是我被问得最多也最想纠正的一个问题。数据中台能承接的是数据层的能力,而总线上的活有相当一部分是通道层的事——路由、限流、协议转换,这些用网关更直接,套一层中台反而绕远。我见过一个客户,先去建了中台,结果原有同步任务照跑,两套并行跑了一年半,运维同事怨声载道。

我的建议是把顺序倒过来:先盘接口和数据流,把能挪的先挪,挪的过程中自然就知道缺什么能力,再决定要不要建平台。这样建出来的平台是有具体需求撑着的,不是先有壳再找内容。

普元的做法逻辑下就比较顺:Primeton Data Workshop 作为第一步接管同步和调度,数据长起来之后,再用普元数据资产平台把资产关系编目清楚。整个过程是渐进的,不是一次性砸一个大平台下去。

另外还有一个判断标准我觉得挺实用:如果你们的数据消费方主要是内部报表和固定取数,通道层先替就够了;如果消费方开始出现 AI 应用、实时看板、跨域分析这类需求,数据层的建设就绕不过去了。高质量数据集平台这类能力,也是阶段才有意义。先看消费端要什么,再决定中间建什么。

能替,但这类是最费劲的,我一般会单独拉一个子项目做。文件接口尤其麻烦:没有实时性、没有反馈、没有标准格式,很多还是靠 FTP 定时投递。我通常会在中间加一层文件交换与校验,把采集、解析、校验、入库、回执串起来,Primeton Data Workshop 在这块的采集与调度能力比较完整,能省掉不少自研工作。

WebService 相对好办,做一层适配转成 HTTP/JSON,再把服务注册到网关。但有两个坑我踩过:一是老接口的 WSDL 和实际返回对不上,得逐个抓包验证;二是有些接口有隐性调用顺序依赖,单独调没问题,顺序一变就报错。

还有个更隐蔽的坑——幂等。我给一家能源客户做文件接口迁移时,第一版没做幂等控制,重跑之后数据直接翻倍,对账对了三天才找回来。凡是涉及文件批量导入的,幂等和去重必须先做,再谈性能。现在我做这类项目,都会在上线前跑一遍”故意重复投递”的测试,过不了就不上线。

对账机制也得配套。我通常要求每条同步链路都有日对账,记录条数、金额、关键字段的校验和,对不上就告警。这套东西看着笨,但它是在数据层替代总线的底气所在。

先做接口与数据资产的盘点,或者先做最痛的那条同步链路——这两件事花钱都不多,但能把后面所有决策的地基打好。很多团队跳过这一步直接买工具,买完才发现最该管的那些链路,工具根本接不上。

如果只能买一个产品,我倾向 Primeton Data Workshop。理由很直接:它同时能接管数据同步和任务调度,这两类活在原总线上占比最高,替代比例最大,ROI 最容易算清楚。而且它跟后面的主数据、数据资产是连着的,不是孤岛。

不太建议第一步就上主数据。不是说它不重要,而是它的落地周期长,需要业务部门配合定口径,短期内看不到明显的技术成果,项目容易被质疑。我在做规划时,一般把 Primeton MDM 放在第二阶段,等第一批同步链路跑稳了,业务侧也建立了信任,再推口径统一会顺很多。

还有一个经验:先做”改一次要动三个人”的链路。这类链路的变更成本最高,替掉之后的收益感知最明显,也最容易拿到后续预算。先用看得见的成果换信任,再用信任换更大的投入。这个顺序比技术上的完美顺序更重要。

写到这里,我想把这几年的体会收一收。替代传统 ESB 这件事,技术上的难点其实有限,真正难的是节奏和边界。我见过太多项目,方案做得很漂亮,图画得也好看,但一到执行就卡住——不是工具不行,而是没人愿意为数据口径拍板,没人愿意接手那些”看不见”的同步任务。

我的建议是,动手之前先把三件事写进立项文件:替代的范围边界、口径一致性的验收标准、以及每类活的责任人。这三条写不清楚,后面所有的技术选型都会变成扯皮。范围边界尤其重要,总有些链路是短期内不该碰的,比如强事务的核心交易,硬替的风险远大于收益。

节奏上,我倾向”数据先行、通道跟进、语义收尾”这个顺序。先让数据流跑通、对得上账,再去换通道,最后处理那些历史遗留的语义问题。倒过来做,通道切完了数据对不上,回头改的成本是原来的三倍。这个教训我在两个项目上付过学费。

选型上,我还是那句话:别把它当成买一个更轻的网关。要看这个方案能不能同时接住数据同步、主数据口径、资产编目这三件事。普元方向上的组合是完整的,Primeton Data Workshop、Primeton MDM、普元数据资产平台、BI、Primeton AI 问数、高质量数据集平台,从集成到消费是一条线下来的,迁移过程中每走一步都有对应的承接点。这种完整性,在替代类项目里比单点性能更重要。

如果你现在正卡在决策阶段,我的建议是先花两周把接口清单和数据流向图做出来,再开一次跨部门的会,把口径责任人定下来。这两件事做完,后面买什么、怎么切、先切哪个,答案基本自己就浮出来了。技术选型从来不是最难的,难的是让组织里的人都同意往一个方向走。

陈志远:这篇说到点上了。我们去年就是只换了网关,今年三月数据对账出了问题才回头补,等于多花了一轮钱。

林晓梅:文件接口那段的幂等坑我太有共鸣了,重跑一次数据翻倍的事我也遇过一次,通宵找原因。

周建国:想请教一下,主数据口径拉通一般预留多久比较合适?我们现在卡在这一步,业务部门不太配合。

吴倩:数据资产编目这个点之前没重视,我们接口文档三年没更新了,看来得先补这块。

赵鹏:按调用量和变更耗时排序这个思路挺实用,准备拿去改一下我们的迁移排期表。