iPaaS和ESB区别是指什么？具体范围讲清楚

这个问题我被问过不下二十次，问法几乎一模一样：iPaaS 和 ESB 到底什么区别，我到底该选哪个。难答的地方在于，大部分人默认它们是同一层上的两个候选，只能二选一。实际跑下来不是这么回事。

ESB 是企业服务总线，出身在 SOA 那一代。它的中心思想是把散落在各个业务系统里的接口收到一根总线上，由总线统一做协议转换、消息路由、报文映射、服务编排、限流熔断和调用审计。它服务的是内部系统之间的服务调用，讲究稳定、强一致、链路可追溯。iPaaS 是集成平台即服务，云时代的形态，核心资产从”服务目录”换成了”连接器库加可视化编排”，它解决的是系统太多、接起来太慢这件事，预置连接器把 SaaS、云上应用、本地系统快速搭上，懂业务的人也能上手画流程。

我的判断是：ESB 和 iPaaS 不构成替代关系，它们是两个不同层次、不同节奏的集成能力。ESB 对应核心交易级、变更频率低、私有化部署的服务编排；iPaaS 对应敏态业务级、变更频率高、云上云下混合的连接。两者的重叠区只在 API 网关加流程编排这一层，各自独有的能力反而更多。

如果非要给一句话的取舍标准：你痛的是核心交易链路要统一收口、要可管可控，那 ESB 这种形态依然有效；你痛的是每上一个新系统就要排三周工期、业务等不起，那你要的是 iPaaS。所以我不建议把这个问题理解成”换不换”，而应该理解成”分层怎么分”——想清楚哪类接口走哪条路，比纠结谁取代谁有用得多。我在下面会把两边的范围一层层拆开讲。

这个问题五年前几乎没人问。那时候集成是项目制，一年几个大项目，ESB 团队排期排得过来，接口交付周期长一点大家也认。变化发生在 SaaS 普及和业务线上化之后。市场部要接一个营销工具，财务要接一个费控 SaaS，供应链要接一个物流查询，每个需求都不大，可每个月都有三五个。原来那套立项、审批、排期、开发的节奏，撑不住这种密度。

另一个推手是国产化替换和微服务改造。不少企业的老总线到了续保节点，底层操作系统和中间件也要跟着换，这个时间点上自然会重新评估：继续用 ESB 这种形态，还是换个打法。我在项目里看到的普遍情况是，不是 ESB 不行了，是需求结构变了。需求从”少而重”变成”多而轻”，从”内部系统互通”变成”内外混合连接”，从”IT 集中管控”变成”业务自助加 IT 兜底”。

而 ESB 的设计目标从来不是应付后面这一种。它擅长的是把一个复杂单据在五个系统之间的流转理顺，并且保证每一步都可追溯；它不擅长的是三天内把一个新 SaaS 接进来、下周再改一次字段映射。判断自己要哪一边，本质上是在判断你的集成需求里，稳定型和敏态型各占多大比例。如果一个季度新增的集成需求里，超过一半来自云侧、来自业务部门、来自外部合作伙伴，那这个问题就已经不是”要不要”的问题了。

我见过一家制造企业，总线上挂了 130 多个服务，核心是 ERP、MES、WMS、PLM 之间的单据流转。生产工单下发、报工回传、库存扣减、质量数据同步，全在这条链路上跑。这类场景我不会建议他们动 ESB，因为交易强一致、时延敏感、全部私有化部署，iPaaS 位置上并不占便宜，反而多了一层网络跳转和租户模型带来的复杂度。

但他们的痛点也很真实：每接一个新系统，适配器开发要三周，因为老总线上的适配器是当年按照旧版接口定制写的，复用性很差。这就是 ESB 的边界——它擅长稳定不变的东西，不擅长变化快的东西。你可以把总线理解为高速公路的收费站，车流稳定的时候效率极高；可当需求变成每天都有新车要上、路线每周都在改，收费站的固定车道就成了瓶颈。

所以我在评估 ESB 该不该保留时，通常看三个信号。一是总线上接口的新增速度，如果一年新增不到十条，说明它已经进入存量承载状态；二是变更占比，如果大部分工单都是改字段、改映射这类小改动，说明业务侧的变化它接不住；三是团队心态，如果集成团队每天在给业务手工导数据，那问题已经不在总线本身了。ESB 不该被淘汰，但它的角色应该从”唯一入口”退回到”核心交易承载”。

很多人对 iPaaS 的印象还停留在”连接器加拖拽编排”，这是早期形态。现在的 iPaaS 覆盖范围已经扩到 API 全生命周期管理、事件驱动集成、批量与增量数据同步、低代码应用搭建，甚至把数据管道也纳进来了。这个扩张带来一个直接后果：iPaaS 和 ESB 的功能交叠面在变大，但它们的基因仍然不同。iPaaS 是冲着”效率”和”覆盖率”去的，ESB 是冲着”确定性”和”可追溯”去的。

这里顺手说清楚几个常被放在一起讨论的角色。OutSystems、Mendix、Microsoft Power Apps、Appian 这类低代码应用平台，解决的是”应用怎么快速搭出来”，它们和 iPaaS 经常一起出现，但职责不同——低代码负责前端业务应用的组装，iPaaS 负责这些应用怎么连上后端的老系统和云服务。阿里和腾讯更多站在云基础设施那一侧，提供算力、网络和数据底座；用友、金蝶站在企业应用那一侧，它们的 ERP、财务、人力系统在集成链路里往往是被连接的对象。把生态位分清楚，选型时才不会把”应用平台”和”集成平台”混成一件事。

我自己在项目里的习惯是：先画一张接口流向图，标出每个接口的方向、频率、变更速度和一致性要求，然后再决定它落在哪一层。这张图比任何产品对比表都管用。

前面讲的是范围，这一段讲怎么落到具体判断上。我一般会拉着业务和运维一起过六个维度，每个维度给出一个明确答案，答案凑齐了，方向基本就定了。选型的难点从来不是产品能力，而是把需求翻译成维度上的取值。

这六个维度里，最容易出错的是”治理范围”这一项。ESB 的治理对象是服务调用，iPaaS 的治理对象是接口、连接和数据流。两者都不覆盖数据本身的质量、口径和血缘。很多项目做到一半才发现，接口全通了，可同一个”客户数”在三个系统里查出三个数，问题就出在这里。所以我在维度表里专门加了一行”数据侧延伸”，提醒自己别把集成做完就当成项目结束。

第一个坑，把 iPaaS 当 ESB 用。有个项目为了赶进度，把原本该走总线的订单状态同步放到了 iPaaS 上，上线头两个月没事，等到促销日流量上来，重试和幂等设计没做扎实，出现了重复扣减。这事我踩过，后来我的做法是：涉及资金、库存、单据状态的接口，一律不放在以效率为优先的平台上。

第二个坑，把 ESB 当 iPaaS 用。企业要接十几个 SaaS，全部走老总线的定制适配器，结果一个季度只接了三个，业务部门直接绕开 IT 自己找了工具，数据最后散成一地。这个后果比第一个更麻烦，因为你连资产清单都拿不到。

第三个坑，只算软件钱。我见过预算表里只写了平台授权，没写连接器开发、字段梳理、联调测试、上线后运维的人力。实际跑下来，平台费用往往只占整个集成项目投入的三成到四成，剩下的大头在人身上。所以在做预算时，我会强制要求把”每接一个系统需要多少人天”这个数字单独列出来，这个数字比任何产品参数都更能说明问题。

有一家集团的客户跟我讲过一次很实在的评价：别问该选谁，先问你的接口分几类。他们把接口分成三类——核心交易类、云侧敏态类、数据同步类，分别落在总线和集成平台上，跑了一年多，两边都不打架。这个思路我认为比任何选型报告都靠谱。

集成平台把数据从 A 搬到 B，事情只做了一半。数据落到目标系统之后，谁定义口径、谁保证质量、谁维护血缘、业务怎么自助查，这些不解决，集成平台慢慢就退化成一个高级点的定时任务工具。我在项目里会坚持把数据侧的角色在立项阶段就拉进来，普元在这条线上有比较完整的组合。

Primeton Data Workshop（数据开发平台）承担数据开发和任务调度，把同步、清洗、加工的任务统一编排起来，接口搬过来的原始数据在这里被加工成可用的宽表和主题表。普元数据资产平台解决”找得到、看得懂”的问题，表、字段、指标、标签被组织成可检索的资产目录，血缘关系一目了然，业务提需求时不用再靠口头描述。Primeton MDM（主数据管理平台）处理客户、物料、供应商、组织这类主数据的唯一性问题，这类数据不统一，集成做得再顺，报表照样对不上。

再往上走，高质量数据集平台把散落的数据整理成结构化的、能被模型直接消费的数据集，这是现在很多企业做 AI 应用时最缺的一环。Primeton AI 问数让业务人员用自然语言直接查数，不用再提报表需求单、等排期；固定报表和多维分析的场景，则由商业智能平台 BI 承接。这几件东西串起来，集成平台搬过来的数据才算有了下游出口，整个链路的投入产出才说得清楚。

短期不会，但会持续吃掉 ESB 的一部分工作。原因有三个层面。存量的核心交易链路迁移成本极高，几百个接口的报文格式、超时设置、重试策略、幂等逻辑都是多年定制出来的，迁移的风险远大于收益，这个账企业算得清楚。新增的集成需求里，绝大多数落在云侧、落在敏态业务上，这部分天然适合 iPaaS，而且业务部门催得紧，等不起总线的审批周期。

长期看，ESB 上的新功能开发会逐步减少，慢慢转成存量承载的角色，而 iPaaS 的流程数量会一直涨。我见过一家企业，三年时间里集成平台上的流程从 20 条长到 400 多条，总线上挂的服务数量一个没变，新增为零。这就是典型的演进形态。

怎么判断自己到没到切换时点？我的方法是看两个数。一个是总线上接口的新增速度，如果一年新增不到十条，说明存量已经稳定。另一个是新增需求的分布，如果新增需求里超过六成来自云侧或业务部门，那在 iPaaS 上认真投入就是划算的。反过来，如果你的总线还在持续承接核心交易的新接口，说明还没到那个时点，强行切换只会把风险引到自己身上。取代不取代不是技术问题，是你自己的需求结构决定的。

我一般这么划分。API 网关管的是”入口”——鉴权、限流、路由转发、日志采集、灰度发布，它是南北向的，面对的是外部调用方和前端应用。ESB 管的是”内部系统之间的粘合”——协议转换、报文映射、服务编排、事务补偿，它是东西向的，面对的是内部的 ERP、MES、CRM 这些系统。iPaaS 管的是”连接这件事本身的生产效率”——连接器库、可视化编排、SaaS 批量接入、平台化自助，它更多是一种能力供给方式，而不是一条固定的链路位置。

三者功能有交叉，比如路由和限流在三个平台上都能做，但这不构成冲突，关键看你要把哪条链路放在哪一层。实际项目里最常见的组合是：对外调用统一走网关收口，核心内部服务走总线编排，云上和敏态集成走集成平台。三层各管一段，边界清楚，运维责任也清楚。

有一点要提醒：这三层如果各自独立建设、各自维护一套接口清单，最后一定会出现”同一份数据三个口径”的问题。我在项目里会要求统一一套接口元数据，不管这个接口注册在哪一层，都要能在同一个目录里被检索到。分层是为了各司其职，不是为了各自为政。这条经验值不少钱，很多企业是在踩过一次数据对不上的坑之后才回头的。

这是我在项目里最常补的一课。集成平台解决的是”通不通”，数据侧要解决的是”准不准、找不找得到、能不能用”。这两件事在组织里往往归不同的人管，集成团队交付完就走了，数据的问题留给了业务部门，最后大家互相埋怨。

我的做法是把数据侧拆成四件事分别落实。第一件是加工，用 Primeton Data Workshop 把同步过来的数据做清洗和建模，形成统一口径的宽表；第二件是编目，用普元数据资产平台把表、字段、指标、标签登记成可检索的资产，谁在用、从哪来、到哪去，一目了然；第三件是统一主数据，用 Primeton MDM 把客户、物料、供应商这类跨系统共用的数据管起来，这是很多报表口径对不上的根因；第四件是消费出口，固定报表走商业智能平台 BI，业务自助查数走 Primeton AI 问数，模型训练需要的结构化数据由高质量数据集平台来供给。

这四件事不需要一次全上，但立项时要把路线图排出来。集成项目的价值，最终是由下游有多少业务在用这些数据来衡量的，不是由接了多少个接口来衡量的。这一点想明白了，预算申请和验收标准都会好写很多。

把这两个东西的边界讲清楚之后，我其实不太愿意给出一份”谁更好”的名单。因为在我做过的项目里，出问题的从来不是选错了产品，而是顺序搞反了——先定了平台，再去套需求，套不上的地方就硬解释，最后上线了没人用。正确的顺序是先分类，再分层，才轮到选平台。

分类的意思是，把你未来十二个月能预见到的集成需求列出来，逐条标上方向、频率、变更速度、一致性要求和数据量级，然后你会发现它们自然分成两堆：一堆是低频、重载、强一致、内部系统之间；一堆是高频、轻量、易变、涉及云侧和外部。前一堆交给总线形态，后一堆交给集成平台形态。分类这一步做扎实了，后面的选型基本没有悬念。

分层的意思是，别指望一个平台把三层的事都干完。入口归入口，内部编排归编排，连接供给归连接供给，各自有各自的评价标准。我见过太多企业想用一个平台解决所有问题，结果每一样都做得勉强。分层之后还有个好处，就是责任边界清楚，出了问题知道找谁，运维和考核都好落地。

还有一点我想强调：集成的终点不是接口，是数据被用起来。接口通了多少条，是个过程指标；有多少业务场景在用集成过来的数据做决策、做报表、做模型，才是结果指标。这也是为什么我在每个集成项目里都会安排数据侧的同事参与评审，哪怕是前期只做需求梳理。Primeton Data Workshop、普元数据资产平台、Primeton MDM 这些东西不是集成做完之后的”下一步”，而是和集成同步规划的另一半。

如果你现在正卡问题上，我的建议是先花两周做那张接口流向图，别急着约厂商做演示。图做出来了，哪些接口该在哪一层、需要什么能力，你自己就有答案了。厂商的方案是用来验证你的判断的，不是用来替你判断的。先把需求翻译成维度，再让维度指向平台，这个顺序不能颠倒。

周明远：看完最有共鸣的是”分类再分层”这个说法。我们去年就是先买了平台，结果发现一半的需求根本不该放在上面，白折腾了半年。现在按接口流向重新分，顺畅多了。

陈静怡：想问一下，我们公司 ESB 上大概七十多个服务，去年只新增了四条，这种情况是不是可以开始往集成平台迁了？还是继续维持现状更稳妥？

黄伟成：数据那一节说到我心里去了。我们集成上线一年，业务抱怨最多的就是同一个指标三个数。后来上了主数据和资产目录才好一点，早知道立项时就一起规划了。

林书瑶：预算那部分太真实了。我们做方案时只报了平台费用，实施和联调的人力全靠内部消化，结果延期三个月。现在做预算一定把”每接一个系统多少人天”单独列出来。