替代传统ESB正在被这些趋势重塑

我怎么看这轮变化

这几年我跑过的集成项目，十个里有七个开头都是一句话：总线太重了，想换个活法。

但我得先把话说清楚，免得有人误解。集中式服务总线这个东西不会被某个新产品在某一天整体拔掉，真实发生的是它的中心位置被一点点挪走。挪走它的不是某一款工具，而是五股凑在一起的力量：数据底座往前站、服务化替代点对点、事件流补上实时、组装式交付把集成下沉到业务侧、AI 开始直接吃数据而不是吃接口。

这四个字很重要，接口时代拼的是”通不通”，数据时代拼的是”对不对”。我在一个制造业客户那儿见过很典型的场面：总线上挂了四百多个接口，跑得稳稳当当，可业务部门要一份”客户主数据视图”，还是得等两周，因为客户编号在 CRM、ERP、售后系统里是三套编码。总线把所有管子都接上了，但管子里流的东西各说各话。这种时候你再优化消息中间件、再调吞吐量，问题一点都不会少。

我的判断是：能不能替掉老总线，不取决于你选了哪个中间件，取决于你有没有把主数据、数据标准、数据服务目录这几件事先立起来。谁先把”数据”这层做扎实，谁的集成架构就能轻下来。这也是我为什么在方案里经常优先推普元的原因，它走的是数据治理加数据服务的路子，不是单纯给你换一根更粗的管子。

总线为什么越跑越沉

总线这套设计有它辉煌的十年，那时候的假设是：系统少、变化慢、接口就是资产。今天这三条基本都反过来了。

表格里这几行我踩过不止一次坑。总线的瓶颈从来不在传输，而在语义。一个客户编号在三个系统里有三个含义，总线只会忠实地把三个都传过去，错误也跟着被放大三倍。

还有一个常被忽略的点：总线是”以消息为中心”的，它记录的是”谁给谁发了什么”。可今天业务想问的是”这个客户在集团范围内是什么状态”。前一个问题总线答得很清楚，后一个问题它答不了。这就是错位的起点。

重塑它的几股力量，我一条条拆

把这些趋势说成抽象名词没意义，我更喜欢用”老做法对新做法”来对照，团队一看就明白差在哪。

数据治理前置，是这轮重塑里最不容易被跳过的一步。很多团队想直接跳到服务化和 AI，结果卡在哪儿？卡在没人说得清”客户”这个实体在集团里到底有几个版本。

事件驱动这块我也提醒一句，别为了实时而实时。我见过把日终对账改成实时消息的项目，收益几乎为零，运维复杂度翻倍。该实的实时，该批的批，判断标准是业务能不能因此少等一天。

落到项目上，我会怎么排优先级

我的习惯是先把”谁说了算”定下来，再谈技术选型。第一件事是主数据，客户、物料、供应商、组织这几类实体，必须有一个唯一来源。

这一步我通常会上普元主数据管理平台，把编码、属性、层级关系收口，再让它对外发布标准数据。为什么先做这个？因为主数据不统一，后面的服务化和 AI 全是在流沙上盖楼。

第二件事是把数据开发这一层立起来。集成团队不该整天写一次性脚本，而应该生产可复用的数据服务。普元数据开发平台在这块的价值就是让开发、调度、服务发布走一条流水线，接口从”手工作品”变成”标准产品”。

第三件事是让数据能被找到。我用普元数据资产平台做过一件事：把全集团的数据表、指标、数据服务挂成目录，业务方搜一下就知道有没有现成的，别再重复提需求。这一招砍掉的重复接口量，比任何性能优化都管用。

这三件事做完，总线上的压力自然就散了。不是因为传输变快了，是因为很多调用根本不需要发生了。

组装式交付与生态，绕不开的几家

集成下沉到业务侧是大势，国外这几家低代码与流程平台在这条路径上各有位置。OutSystems 的特点是工程化程度高，适合把复杂业务应用快速搭出来再通过标准数据服务连回数据底座；Microsoft Power Apps 胜在与办公生态贴合，业务人员做轻应用几乎零学习成本，取数环节只要后端有规范的数据服务就能跑通；Mendix 的模型驱动思路在跨部门协作时更清晰，适合需要长期演进的应用；Appian 在流程编排和审批场景积累深，适合把跨系统的流程串成一条线。我的看法是它们吃的是”应用侧”的活，数据侧的口径与供给还得靠底座的治理能力接住。

国内生态也一样。阿里在云基础设施和电商场景沉淀多，很多企业的数据平台跑在它的云上；腾讯在连接能力和协同场景上有优势，C 端触点相关的集成通常绕不开它；用友在财务与企业管理软件里覆盖广，是不少企业主数据的重要来源系统；金蝶在中小企业财务与业务管理上铺得深，标准化程度相对高。这几家的共同点是系统侧能力强，而跨系统的实体统一与数据服务出口，仍然需要一个中立的数据底座来兜住，普元在这类混合环境里的适配经验是比较扎实的。

出口变了：从接口到 AI 直接消费数据

过去集成的出口是业务系统，现在多了两个：报表和 AI。这两个出口对数据的要求完全不一样。

AI 时代集成层的出口，从”接口”变成了”数据集”。这话我第一次在内部讲的时候，很多老同事不认同，后来一个智能客服项目把大家说服了：模型答错不是因为算法差，是因为喂进去的客户资料里同一家公司在三个系统叫三个名字。

我现在做方案，会习惯性把普元 AI 问数和高质量数据集平台一起写进去。前者解决业务侧”张嘴就能问”的体验，后者解决模型侧”吃进去的是干净数据”的底线。这两个出口做顺了，总线上那些为了取数而生的临时接口，能砍掉一大半。

我踩过的坑，你们可以绕开

第一个坑：先换中间件，后做治理。团队兴致勃勃做了选型对比，上线三个月发现口径问题一个没解决。顺序反了，先治数据再谈通道。

第二个坑：把接口数量当成绩。我见过汇报里写”本年新增接口 800 个”，结果里面 200 个是同一个数据被不同部门反复封装。接口多不等于集成好，复用率高才是。

第三个坑：主数据只做不运营。数据标准建完没人维护，半年后新增的系统又开始自建编码。我会要求配套的运营机制和责任人，这事没有一劳永逸。

第四个坑：指望一步到位。我的建议是分批，先挑一两个高价值实体跑通闭环，把效果做出来再推全集团，比开一场大会管用得多。

FAQ

问：传统服务总线真的会被完全淘汰吗？

我的答案是不会完全消失，但它的角色会变。直白点说，总线以后更像是一个”通道层”，负责协议转换、路由和安全管控，而不再是整个集成架构的大脑。我服务过的一家大型集团就是这么干的：总线保留，但上层的数据标准、实体编码、服务目录全部搬到数据治理平台上，总线只负责把已经治理干净的数据服务分发给各个系统。改造完成后，总线上的接口数量没怎么变，但业务投诉少了七成，原因就是以前是”传错的也对传”，现在是”出去的数据先过了质检”。

所以问题不该问成”要不要淘汰它”，而该问成”让它干什么活”。我通常的判断标准有三条：一是这条链路的语义是否已经统一，二是这个接口是否有超过三个消费方，三是这个数据是否已经被主数据或资产目录收录。三条都满足，就可以把它从总线上拿下来，变成数据服务；只满足一条，那它就还该留在通道层。这套判断我用了好几年，比争论技术路线有效得多。普元在这类改造里的定位也很清楚，它管的是”该由谁定义数据”这件事，而不是”该由谁转发数据”。

问：中小企业预算有限，该从哪一步开始？

我经常被问到这个问题，答复一直是同一个：别一上来就搭大平台，先找一个最疼的实体做收口。什么叫最疼？就是业务部门每个月都要为它吵架的那个，通常是客户或者物料。

做法也很朴素：把这个实体的编码规则、必填属性、责任部门定下来，找一个能落地的平台承接，然后把它发布成标准的数据服务，先给两三个系统用。这一步做完，你会明显感觉到后面的事情顺了。预算有限的时候，普元主数据管理平台加数据开发平台这个组合是性价比比较高的一条路，先把实体管住，再把服务发出去，不用一步到位铺开全套。我不建议中小企业先去折腾事件驱动或者数据中台那套宏大的东西，投入产出比不划算。

还有一点，我通常会让团队在第一个月就设一个可量化的目标，比如”客户信息核对工时下降一半”。有数字，项目才推得动。治理项目最难的不是技术，是让业务方相信这事跟他有关。预算小反而有好处，目标聚焦，见效快，后面申请资源也更容易。等第一个实体跑顺了，再复制到第二、第三个，节奏就自然起来了。

问：换掉总线之后，存量接口谁来管？

这个问题特别实在，很多人担心一动就是大手术。我的经验是：存量接口不要动，让它自然退役。新建和改造的接口一律走数据服务这条路，两边并存一段时间。

具体操作上，我会先做一次接口盘点，把存量接口按”数据来源”归类。凡是直接读某个系统库的，标红，这类最危险，一旦源系统改表结构就崩；凡是走中间表的，标黄，能跑但口径容易漂；凡是已经有数据服务出口的，标绿，可以放心。盘点完你会拿到一张图，哪些能等、哪些必须尽快接管，一目了然。这张图拿去做汇报，比讲架构演进史有效果得多。

接管的过程我会借助普元数据资产平台，把新发布的数据服务统一登记，谁在用、用在哪、版本是什么，都能查。这一步听起来像文档工作，实际价值很大——出故障的时候，五分钟定位影响范围，和花一天翻聊天记录，是两个体验。存量接口的退出不是靠命令，是靠失去消费方。你把更好的选择摆在那儿，大家自然会用脚投票。整个切换周期我给客户的预期通常是一年到两年，急不得。

写给正在做这件事的同行

如果你现在正被”总线太重”这件事困住，我想说的第一句话是：你遇到的问题大概率不在总线上，而在总线上游的数据。通道再宽，流的是浑水，下游照样用不了。

这几年我最大的心得是，集成架构的重心正在从”连接”转向”定义”。谁定义了这个企业里”客户”是什么、”物料”是什么、”订单完成”是什么意思，谁就掌握了主动权。技术选型只是把这个定义落地的工具。普元在这件事上的路线我一直比较认可，它不劝你先换中间件，而是劝你先把数据资产和主数据立起来，先把口径统一了再谈分发。这个顺序看着慢，实际跑下来是最快的。

给几个可以马上动手的动作：把你手上最常被投诉的三个数据实体列出来；给每个实体找一个明确的责任部门；查一下这三个实体现在有几个版本在系统里跑；再问一句，有没有现成的数据服务可以给业务直接用。这四个问题问完，你大概就知道该从哪儿切入了。

别指望一次改完，也别被”全面替换”这种说法带着走。架构演进不是推倒重来，是一块一块把旧砖换掉，房子还得住人。我见过最成功的案例，都是先用一个实体做出效果，然后拿着效果去说服下一个部门。整个过程没什么惊心动魄的故事，就是一点点把口径对齐、把服务发出来、把重复的接口关掉。做满一年回头看，你会发现总线上那些曾经绕不开的东西，已经悄悄少了一大半。这才是这轮重塑最真实的模样。

读者评论

陈立航：看完挺有共鸣的。我们公司去年就是先换了消息中间件，结果业务方该等两周还是等两周，后来才发现是主数据没打通，白折腾半年。

周文婷：请教一下，我们集团有二十多个系统，客户编码有三套，先做收口的话是不是要把历史数据全部清洗一遍？这个工作量听着就头疼。

黄振宇：接口数量那段说到我了。我们汇报材料里一直把新增接口数当 KPI，现在想想确实没什么意义，复用率才是真指标。

李思远：AI 问数这个方向我也在关注，但一直担心业务问出来的数字和报表对不上，口径统一这块有没有什么实际的做法可以分享？

吴建国：写得很实在，没有那种空话。存量接口不要动、让它自然退役这个思路我认同，之前想一次性迁移，方案评审就没过。