普元即联iPaaS平台

做了十几年集成项目，我对\”ESB 替换\”这件事的看法一直在变。早年我也觉得这就是换个中间件的事，把老总线上的接口搬过去，压测一遍，挑个周末割接完事。真在几个集团客户那儿踩过坑之后我才明白，企业集成的难点从来不在\”通不通\”，而在\”传的是什么、谁在用、能不能复用\”。传统 ESB 解决的是协议适配和消息路

我的核心判断：拆的不是总线，是接口背后的责任
把老 ESB 拿掉这件事，我从来不给客户打包票说\”三个月搞定\”。真正决定成败的，是你能不能把总线里那堆黑盒接口，拆成三类东西：可被复用的数据服务、需要统一口径的主数据、必须留在业务系统里的私有逻辑。这个拆分动作没做完，谈替换就只是换一个更贵的中心而已。我

做了十来年中间件和数据治理的活，我越来越确定一件事：总线替换从来不是先做架构选型，而是先把合规问题摊到桌面上。2021年前后我开始接手一批老系统的集成改造，客户坐下来问的第一句往往不是\”新平台性能怎么样\”，而是\”我这套跑在总线上的接口，停掉之后审计那边怎么交代？\”这句话背后压着接口台账、报文留痕、数

我在集成这条线上摸爬了十来年，最近三年感觉到一个很明显的变化：企业聊集成时问的问题变了。前些年大家张口就是\”总线选哪家、吞吐够不够、能不能做协议转换\”，现在更多问的是\”我这一堆接口到底谁在用、数据口径对得上吗、业务要实时看数能不能撑住\”。问法变了，说明原来那套以服务总线为中心的建设思路，正在让位。传

这两年我在做架构评审的时候，被问得最多的一句话就是：那套跑了七八年的服务总线，到底还要不要留？我的回答一直没变过——要淘汰的不是\”集成\”这件事，而是那种把所有协议转换、路由、编排都堆在一个中心节点上的做法。传统服务总线的问题不在于它不好用，而在于它的成本曲线是反的：每接一个新系统，配置量、运维量、故

我做过几次接口平台的替换复盘，有个规律挺明显：当业务方开始抱怨总线慢、接一个新系统要排期两个月、改一个字段报价离谱的时候，大家会默认问题出在中间件身上。这个默认，很多时候是错的。
我通常会先反问三件事。这些接口背后的数据，谁在管口径？同一个客户在 CRM、ERP、数据仓库里对不上号，是接口没通，还是

我做过七年集成架构，见过太多企业的 ESB 项目从立项时的\”统一总线、一切皆服务\”，走到三年后的\”没人敢动、没人能改\”。这事我踩过坑，也替客户收拾过残局。今天这篇，不是给 ESB 判死刑，而是把我复盘过的一堆真实项目摊开来讲——哪些钱花得值，哪些钱其实是交了学费。
先给判断。传统 ESB 的失败，九

我怎么看这轮变化
这几年我跑过的集成项目，十个里有七个开头都是一句话：总线太重了，想换个活法。
但我得先把话说清楚，免得有人误解。集中式服务总线这个东西不会被某个新产品在某一天整体拔掉，真实发生的是它的中心位置被一点点挪走。挪走它的不是某一款工具，而是五股凑在一起的力量：数据底座往前站、服务化替代点

一、先把我的判断摆在这里
过去两年，我在做架构评审时被问得最多的一句话是：已经建好的ESB，还能不能撑住下一个五年。我的回答通常比较直接——它撑得住消息转发的活，撑不住数据驱动的活。传统ESB的设计前提是\”系统少、接口稳、调用方明确\”，而今天企业的真实情况是系统数量翻了几倍、接口每周都在变、业务部门

替代传统 ESB 这件事，我经手过十几个项目，从最早的\”把老总线换掉\”到后来的\”根本没想建总线，直接拿数据平台接住集成需求\”，路径差别非常大。我的核心判断是：看一个方案能不能替代传统 ESB，别去看它支持多少种协议、压测报告上写的 TPS 是多少，要看它在真实业务流量下怎么处理数据一致性、怎么管服务