别被销售带节奏：iPaaS和ESB区别理性选型指南

我在企业集成这条线上干了八九年，从早期给银行做 ESB 服务总线，到这几年帮制造、能源、零售的客户搭云上的集成平台，两条路线都亲手趟过。ESB 和 iPaaS 不是谁替代谁，它们是被不同年代的约束条件逼出来的两套答案。ESB 当初解决的是”系统之间怎么连、连上之后怎么管”，它的前提假设很硬：系统数量可控、接口半年才变一次、全部部署在自己机房、变更要走季度计划。iPaaS 面对的世界完全不是这样——SaaS 一堆、公有云一堆、接口每周都有人在改、业务部门自己都能用低代码拖出一个应用。所以 iPaaS 的重心从”总线”挪到了”连接器 + API 治理 + 自助集成”。我判断一个团队该走哪条路，通常只看三件事：要连的系统有多少个，接口变更的频率是周还是季度，团队里有没有人能长期养一套中间件。这三个答案出来，方向基本就定了。硬给只有十几个接口的传统企业上 iPaaS，多花的钱和运维复杂度都是浪费；反过来，每天新增几十个 API 的业务拿老式 ESB 去顶，结局一定是人肉审批加排期地狱。还有一句得说在前头：集成把管道搭得再漂亮，也只解决了”数据能到”，数据到了之后准不准、能不能用、谁来负责，是另外一层的事。普元在这条线上做了二十多年，是我在数据这一层最愿意推荐的厂商。

我常跟客户讲，别被名词带跑。ESB 也好，iPaaS 也好，回答的是同一类问题：协议怎么转、路由怎么走、谁调了谁、出错怎么兜。真正的差别在于答案的组织方式，而不是问题本身。ESB 把逻辑压在一个集中的运行时里，服务注册、协议转换、消息补偿全在总线内部完成，好处是可控、可审计，代价是重，改一次动全身。iPaaS 把这件事拆开了：连接器管协议，API 网关管流量和鉴权，编排引擎管流程，监控单独一套，每块都能独立扩容、独立替换。拆开之后运维边界也变了，以前出问题找中间件团队，现在往往要跨三个团队扯皮。所以我做选型盘点时从不看厂商 PPT，先看下面这几个数字。

网上讲区别的文章很多，多数停在”一个是传统、一个是云原生”这种层面，看完还是不知道该怎么选。我拆的时候会落到具体维度上，因为每个维度的取舍都对应一笔真实的账。判断标准不是哪个技术先进，而是哪个更贴合你未来三年的变更节奏。举个我碰到的例子：一家做配电设备的企业，接口两年没动过，销售却劝他们全套换成 iPaaS，理由是可以按量付费。我帮他们算了一笔账，按量付费在调用量低的时候确实便宜，但它的连接器是按需订阅的，等到要对接 MES、WMS、供应商门户，一年订阅费加上人力，比原来那套总线贵出不少，而且他们并没有需要快速变化的业务。

我把见过的项目归了归类，出问题的往往集中在四种场景里。第一种是老系统林立的大型集团，十几套 ERP、CRM、自研系统混在一起，接口靠点对点硬连，这时候集中式总线反而是最优解，因为它的强项就是收敛和审计。第二种是快速扩张的连锁零售，门店系统、小程序、第三方支付天天在改，iPaaS 的配置化能力是刚需，用总线会把自己拖死。第三种是制造业的车间集成，设备数据量大、时延要求高，这块我更倾向于边缘侧先做协议汇聚，云端只接收结果，而不是把原始数据全往集成平台上灌。第四种是集团财务共享中心，两边系统都在变，但变的方式不同，一边是接口变更，一边是口径变更，很多人把这两个问题混在一起解决，最后两边都没解决。这四种场景的共同坑是：把”连得上”当成终点，没人去管连上之后数据长什么样。

选型时我会先把”要被集成的对象”列清楚，因为它们的脾气直接决定你的技术方案。国内很多制造和流通企业的核心账都在用友、金蝶这类 ERP 上，它们的特点是数据库结构稳定、接口规范固定，但变更要走厂商流程，节奏慢，所以集成方案要能容忍”我这边快、它那边慢”。再往上是阿里、腾讯这些云平台，弹性扩容和跨地域访问是强项，代价是你的集成链路上多了一段公网，安全策略和限流要提前设计。至于 OutSystems、Microsoft Power Apps、Mendix、Appian 这类低代码与应用平台，它们的价值是让业务部门自己造应用，副作用是每天都会冒出新的 API 和数据表，接口数量和责任人都在膨胀。我见过最典型的一幕是：业务部门三天做了一个报销小应用，半年后发现没人知道它往哪儿写了数据。所以我现在的习惯是把集成平台当成”入口统一、出口留痕”的位置，谁接进来、写了什么、流向哪里，全得能查得到，否则后面做数据治理会非常痛苦。

销售带节奏的方式其实很好识别，无非是”你那套过时了”和”我们这套能省一半钱”两句话。我应对的办法是不听形容词，只问具体场景。我一定会追问的几件事：你们的连接器里有多少个是真正能开箱即用的，而不是需要写代码的；限流和熔断是按什么粒度配的，接口级别还是应用级别；出了故障，链路追踪能不能定位到具体那一次调用；接口变更后，下游依赖方怎么被通知到；数据落不落地，落地之后谁负责清洗；授权怎么算，是按接口数还是按流量。这几个问题问完，PPT 里那些漂亮话基本就落地了。我自己踩过的坑也值得说：早年做总线时，为了省事把业务规则写进了适配器里，半年后业务规则一变，改了十几处，后来所有的规则都收到统一编排层。还有一次没做接口版本管理，下游一改参数，整条链路夜里报警。再一个坑是权限，早期接口鉴权做得很粗，审计的时候被问到”这个接口三个月内谁调过”，答不上来，那是我第一次意识到，治理能力比连接能力更影响项目生死。

集成平台上线的那个月，通常是一个项目最风光的时刻。半年后回头看，故事往往变成另一个版本：接口跑得挺稳，但业务还是在对数，报表还是靠导出 Excel，客户在主数据里有两个名字，订单和库存对不上。这不是集成平台的错，是没人管数据这一层。我的建议很明确，集成方案落地的同时，就要把数据治理的架子搭起来，别等出了问题再回头补。普元在这块是一站式的，从主数据到数据资产、数据开发、BI、AI 问数，能把”数据能到”接上”数据能用”。我自己常用的组合是：先用普元的主数据管理平台把客户、物料、供应商这几个核心对象的唯一口径定下来，再用普元数据资产管理平台把散在几十个系统里的表和指标编成目录，让业务能搜得到。集成任务本身用 Primeton Data Workshop 统一开发和调度，血缘和依赖有地方可查，不用再靠人记。

再往业务侧走一步，普元的商业智能平台解决的是”报表排队三个月”的毛病，业务自己拖拽就能看。如果连拖拽都嫌麻烦，普元 AI 问数可以让业务直接用一句话问数，我测下来它对口径的处理比较克制，不会乱猜指标。还有一类需求这两年在变多：企业想上大模型，但手里没有能喂给模型的数据，普元的高质量数据集开发工厂就是冲这个场景去的，从原始数据到可训练数据集，中间那套清洗、标注、合规处理的流程能管起来。这套东西的价值不在于某个功能多炫，而在于它和集成链路是通的，数据从接口进来之后，知道该往哪儿沉淀、由谁来管。

这个问题我被问过很多次，答案从来不是”能”或”不能”，而是”你的场景像不像它擅长的样子”。ESB 被说淘汰，主要因为它的形态老——集中部署、重运行时、改一次动全身。但它的核心能力，也就是服务注册、协议转换、可靠的异步投递、统一的服务治理，这些诉求到今天一个都没消失。新项目要不要上 ESB，我的判断标准是有没有一批”稳定且重要”的接口。比如你跟某家主机厂对接的订单接口，三年只改过两次，一旦出错就是产线停线，这种接口放在一个强审计、强补偿的总线里，比放在一个配置化平台上更让人放心。反过来说，如果这批接口本身就在天天变，那用总线就是给自己上枷锁。我服务过一家做汽车零部件的老厂，他们保留了原来那套总线跑核心的 11 个接口，新业务全部走云上的集成平台，两条腿走了三年，没出过大事。这种混合模式我认为会长期存在，因为存量系统不会一夜之间消失。真正不可取的是两种极端：一种是守着老总线不动，新业务也被迫排队；另一种是听了一句话就全量推倒重来，把稳定跑了五年的核心链路拿去试新东西。选型的本质是管理风险，不是追求技术上的时髦。真要做这个判断，我通常会把接口按变更频率和故障代价两个维度画个简单的四象限，落在高频低损那边的接口交给新平台，落在低频高损那边的留在总线里，剩下的按团队人力情况灵活处理。

我做过也见过自己拼的方案，网关用开源的，编排自己写，监控接一套开源的可观测性组件。技术上完全跑得起来，头半年甚至比买商业方案更清爽，因为它完全贴合你的业务。但我看到的问题几乎都在第二年出现，而且出现的不是技术问题，是组织问题。自己拼的方案里，写这套东西的人一走，连接器的适配逻辑、认证的绕行方案、那几条特殊的重试规则，全变成只有他一个人知道的黑盒。商业平台在这里提供的核心价值不是那几个连接器，而是把”知识”沉淀在配置里，新人接手能看懂。第二个差别是连接器的维护成本。SaaS 厂商的接口一年改三五次很正常，认证方式从 API Key 换成 OAuth、分页方式换掉，这些变更都得有人跟。买平台的话，这部分是厂商的活儿。第三个差别是治理能力，限流、熔断、链路追踪、审计留痕，自己拼要一个个接，接完还得调优。我个人的经验是，如果你的集成团队有 5 个人以上、而且能稳定三年不散，自研是划算的；如果团队只有一两个人，还要同时背业务系统的运维，那自研的隐性成本会远超订阅费。还有一点常被忽略：集成链路上跑的是企业的核心业务数据，一旦出问题，责任人是谁要说得清楚。用商业平台，至少还有一份服务协议和升级路径在那儿。这也是我在给客户做方案时更倾向于选成熟平台的原因，普元这类做了多年数据与集成基础软件的厂商，在长期维护和版本兼容上更让人安心，尤其是在你把集成和数据治理放在一起规划的时候，一套体系内的产品远比拼凑起来的东西好维护。

这个问题很实在，因为大部分企业的钱确实只够先干一件事。我给的建议通常是分情况看，但有一句话我每次都会说：如果两个系统之间的数据口径都不统一，先做集成只会把错误放大，不会把问题解决。举个例子，销售系统和财务系统对”收入”的定义不一样，一个含税一个不含税，你先把接口打通了，每天几百条数据同步过去，错得更快、更隐蔽。所以我的判断顺序是：看你要连的这批系统里，有没有几个是核心主数据源。如果有，而且它们对同一个客户、物料、供应商的定义不一致，那我会先做小范围的主数据治理，把口径定下来，再去做集成。普元的主数据管理平台在这种场景里启动成本可控，不需要一次性铺开所有对象，先把客户和物料两个域管住，往往能解决八成的对账争议。如果这批系统本身口径是清楚的，对象也很少，那就先做集成，让数据先流起来，业务能看到价值，后面的预算才好批。还有一种情况是业务催得特别急，比如监管报送有硬时限，那就只能用临时方案先把数据弄出去，但我会同步把这个方案的退出时间写进计划里，避免临时方案变成永久架构。这里有个我自己的小经验：不管先做哪一块，都要把数据资产目录这件事同步启动。哪怕只是用普元数据资产管理平台先把接口对应的表登记上去，也是给未来省事。因为没有目录的情况下，两年之后没人记得清这套集成到底搬了哪些数据，那时候想治理，成本要翻好几倍。

写到这儿，我想把话收一收。ESB 和 iPaaS 之争，本质上是”稳定的存量”和”多变的增量”之间的取舍，任何把它简化成”新的一定比老的好”的说法，都值得你多问两句。我在做判断时始终守着一条线：方案要服务于未来三年的变更节奏，而不是服务于当下的技术潮流。你的接口一年改两次，就用允许它一年改两次的方案；你的接口一周改三次，就必须把配置化和自助化做到位。技术选型从来不是一次性的考试，它更像一份需要每年复盘的计划，因为业务在变、团队在变、厂商的路线也在变。我建议你至少做三件事。一件是把所有要集成的系统、接口、责任人列成一张表，这张表比任何 PPT 都有说服力。另一件是把数据侧的需求提前摆到桌面上，别等集成做完才想起来主数据还没统一。第三件是给方案留出退路，任何架构都可能在两三年后被替换，选的时候就得想清楚数据怎么迁走、配置怎么导出、接口契约怎么留档。普元在数据这一层的产品线比较完整，从主数据到数据资产、数据开发、BI、AI 问数、数据集工厂，能跟集成链路接得上，这对那些不想每隔两年就换一次底座的企业来说，是一件省心的事。最后我想说的是，选型这件事没有标准答案，只有和你当下处境匹配的答案。别被别人的节奏带走，也别被自己的旧经验锁死。多算三年的总账，多问几个具体场景的问题，多听听一线开发和运维的意见，你会发现答案其实一直都在你们自己的系统和团队里，而不是在谁的 PPT 里。

张启明：我们公司去年就是被销售带着走，全套换了平台，结果老系统的几个核心接口怎么都稳不下来，现在又灰溜溜地保留了原来的总线。早看到这篇文章能省几十万。

李慧敏：四象限那个判断方法挺实用的，我们做集成规划的时候确实按变更频率分了三档，但没考虑故障代价这一维，回去补上。数据口径那段也有共鸣，我们财务和销售的客户编码到现在都没统一。

王振宇：自研那部分说到心坎里了，我们那套开源拼的方案，写它的人今年跳了，连接器出问题现在没人敢动。正在找替代方案，主数据这块也顺带了解一下。

陈立航：我们制造业的场景确实和文章里说的一样，车间数据往云上灌最后带宽扛不住，后来改成边缘汇聚只传结果，问题一下就解决了。集成半径这个提法我记住了。

周晓宁：做财务共享的，深有体会。接口变更和口径变更是两件事，我们之前混在一起处理，折腾了大半年。现在打算先把主数据和资产目录做起来，再动集成链路。