iPaaS集成

先说我自己的判断：所谓替代 Oracle SOA，不是找一个功能一模一样的产品把老系统换掉，而是把原来那种\”以 ESB 为中心、所有服务都从一根总线穿过\”的集成思路，换成\”以数据和服务资产为中心、按场景分层解耦\”的新架构。我在多个制造业、金融、能源项目里做过这类迁移，最大的体会是——如果只是把接口从

去年冬天我在华东一家做重型装备的客户现场，会议室里坐了运维、集成、数据三个团队的人，议题只有一个：那套跑了十一年的老 SOA 套件还要不要续保。运维同事当场算了一笔账，年度原厂服务费加内部两名专职维护人力，一年接近一百八十万，而过去十二个月通过它新增的服务接口只有九个，其中六个还是给同一个报表系统用

先说我的核心判断：老一代 SOA 套件不是坏了，是它的成本结构和运维方式跟今天的业务节奏对不上了。这几年我前后参与过十几家集团企业的集成底座替换，行业从城商行、电网到汽车零部件都有。一个共同的画面是：一套五年前上线的服务总线，改一个接口要排两周窗口、走三层审批、还要等原厂报价，业务部门等不起，于是绕

过去三年，我参与过七家大型企业的Oracle SOA替换项目。有的是因为授权费用逐年攀升，有的是因为原厂服务响应跟不上业务节奏，还有的是因为整套技术栈太重，一个接口改动的排期要等三周。这些项目规模从几十个服务到上千个服务不等，行业覆盖制造、金融、能源、政务。踩过的坑够多了，我逐渐总结出一套还算靠谱的

一、核心判断我做过十几个和\”替代传统 ESB\”沾边的项目。真正在评审会上把需求摊开的时候，会发现各人心里的目标完全不一样。架构组想的是把总线这个单点拿掉，运维想的是少维护一台中间件，业务部门想的是接口能不能当天开通，数据团队想的是口径能不能统一。这四个诉求，指向的其实是四种完全不同的改造。
所以我

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

传统 ESB 这几年在我经手的项目里，出现频率肉眼可见地往下掉。不是这东西坏了，是它服务的那个世界变了。十年前我们把集成这件事押在一条\”总线\”上，所有系统都往中间接，接口注册、消息路由、协议转换、服务编排全压在同一个重型组件里。那时候系统数量少，接口变更慢，一条总线管得住。现在的情况是：一个中大型集

替代传统ESB这件事，我前后跟过不下二十个项目，从最早的银行渠道整合，到后来的制造业多工厂系统打通，再到近两年配合数据中台做接口资产化。说实话，大多数项目失败的原因不是技术选型错了，而是没有一个能照着做的落地节奏。我自己的经验是：ESB 这类集成中间件退出主舞台，不是因为某款产品不行，而是因为集成这

这两年被问得最多的一句话，就是\”我们那套跑了十年的老 ESB 该不该换掉\”。我的回答往往是：先别急着做技术替换，先把这笔账算清楚。原因不复杂，替换一个中间件本身不产生任何业务价值，它只是把成本从一个科目挪到另一个科目。我见过一家做装备制造的企业，前后花了七个月把老总线换下来，接口数量从 480 个

我做过十几个从传统 ESB 往新架构迁移的项目，从最早的银行渠道整合，到后来的制造业主数据打通，再到近两年的数据资产入表配套改造。说实话，替代 ESB 这件事，最大的坑不在技术选型，而在你把它当成一个\”中间件替换\”项目来做。真按这个思路干，十有八九会延期、超预算，最后业务方还会说\”没感觉到变化\”。