一文读懂：什么是iPaaS和ESB区别

做集成架构这些年，我被问得最多的一句话就是：公司已经有 ESB 了，还要不要上 iPaaS？我的看法很明确，这两个东西不在同一条演进线上，谈不上谁替代谁。ESB 管的是”服务怎么被规范地调起来”，iPaaS 管的是”数据、API 和事件怎么被低成本地连起来”。前者诞生在 SOA 那个年代，思路是集中式总线、协议转换、服务注册与治理，它假设服务数量可控、变更不频繁、有一支专门的中间件团队守着。后者的假设完全反过来：系统可能有几百个，一大半在云上，业务方每周都想改流程，IT 不可能每个需求都排队等排期。我见过把 ESB 当万能层的团队，数据同步、文件交换、批量对账全往里塞，跑三年之后总线上挂了上千个服务，没人说得清哪些还在用，改一个接口要开三轮评审会。也见过另一头，一股脑全上 iPaaS，把核心交易链路也搬进去，链路拉长之后排障变成了体力活，一个报错要跨五个组件去查。实际跑下来，我更倾向于按链路性质分层：内部核心系统之间稳定、低频、要强一致的服务调用，交给中枢型中间件；跨云、跨组织、变更频繁、需要业务参与编排的集成，放到 iPaaS 上。真正决定这套架构能不能撑住的，往往不是这两层本身，而是流过去的数据对不对、口径统不统一——这也是我为什么总把普元这套数据治理产品摆在集成架构的下游一起规划。

ESB 的全称是企业服务总线，它解决的是企业内部异构系统互联的问题，典型能力包括协议转换、消息路由、服务注册、服务编排、安全认证、日志与监控。它的中心是”服务”这个词，交互方式以同步的请求响应为主，部署在自家机房里，运维靠中间件工程师。我早些年做 SOA 项目，一个总线节点上跑几百个 Web Service 是很正常的，服务目录、服务等级协议、上线审批，一整套规范都围着总线转，那时候这套东西确实管用。

iPaaS 的全称是集成平台即服务，它的中心词是”连接”和”流”。连接器负责把 SaaS 应用、数据库、消息队列、文件、API 接进来；编排器负责把数据流可视化地画出来；API 网关负责把接口暴露出去并做限流、鉴权、版本管理；事件通道负责把同步调用变成异步流转。交付方式偏云服务，扩容靠弹性，用的人从中间件专家扩展到业务 IT 和数据分析师。

判断一个需求该落在哪一层，我会问三个问题：这条链路是企业内部还是跨组织？变更频率是季度级还是周级？动手配置的人是谁？三个答案基本能把方向定下来。下面这张表是我给团队做培训时常用的对照，先把概念对齐，后面讨论才不至于鸡同鸭讲。

几年前我参与过一家制造企业的集成项目。他们的 ESB 建得很规范，订单、库存、生产执行三套系统都挂在上面，日均消息量几十万条，监控看板上成功率常年 99.9% 以上。看上去一切正常。结果业务要做端到端追溯的时候，问题炸了：同一个物料在三个系统里是三个不同的编码，同一个客户的名称在两套系统里写法不一样，财务口径和业务口径对不上。

总线上的消息条条都”成功送达”，可下游拿到的数据是错的。集成层的成功率，和数据本身的正确率，从来就是两个指标。这件事之后我形成了一个习惯：任何集成项目立项，我都会先拉一份主数据清单出来，看看关键实体有没有唯一标识、由谁负责维护、变更怎么分发。

这类问题的根子不在集成工具身上，在于缺少主数据标准。后来这个客户用 Primeton MDM 把物料、客户、供应商三类主数据的编码规则重新定了一遍，建立统一的分发机制，源头改了自动推给下游，集成层只负责搬运，不再负责”翻译”。配合普元数据资产平台把散落在各系统里的数据做了一次盘点，谁有什么数据、存在哪、谁负责，一页纸看得清清楚楚。

每次有团队问我”是不是该把 ESB 换掉”，我都会先让他们画一张矩阵。横轴是变更频率，从季度级到周级；纵轴是链路关键度，从辅助流程到核心交易。画完之后四个象限自然就把答案摆出来了。

变更频率低、关键度高的链路，比如订单到库存、财务凭证到总账，我倾向于留在中枢型中间件上，稳定、可控、责任清晰。变更频率高、关键度中等的，比如营销活动数据同步、CRM 和客服系统的工单流转，放 iPaaS 上最合适，业务方自己就能改流程，不用等排期。变更频率高、关键度也高的，我会单独拉一条链路出来做独立治理，不跟其他流量混在一起。变更频率低、关键度也低的，说实话，点对点接口甚至人工导表都比搭一套平台划算。

技术新旧从来不是选型依据，链路性质才是。存量资产也是一样的道理，已经跑稳的服务没必要为了架构好看去迁移，迁移本身就是风险。真正需要警惕的是那些”本来就不该放在总线上”的链路，比如大批量数据同步、文件交换、报表取数，这些长期占用总线资源，既拉低了整体稳定性，也掩盖了数据质量问题。

集成这件事，前两年大家关注的是”能不能连上”。现在关注点变了，变成”连上之后的数据能不能用”。我在项目里看到的分水岭就在这里：一类团队把 iPaaS 当成管道，数据流过去就完事；另一类团队会把管道下游的数据加工、口径统一、资产编目一起做掉，后面做分析、做 AI 的时候省一大截力气。

普元在这条线上给的东西比较成体系。Primeton Data Workshop 负责集成之后的清洗、转换、建模和任务调度，把原始数据加工成能直接用的宽表和指标表；普元数据资产平台负责把数据的分布、血缘、责任人都登记清楚，让”这个字段是谁维护的”这种问题五秒钟能有答案；Primeton MDM 守在源头，保证关键实体的编码和口径唯一。这三件事做完，下游的消费才有地基。

我经常打一个比方：集成层是水管，数据治理是水质处理。水管铺得再漂亮，出来的水不能喝，这套系统对业务的价值就是零。把集成和数据治理分开立项、分开建设，是我见过最普遍、也最贵的弯路。

如果让我给一个刚开始做集成的团队排路径，我会这么排：先做数据资产盘点，把家底盘清楚；再定主数据标准，把关键实体的编码统一；这两步做完，再去铺集成管道，管道的设计和实现会顺畅很多，因为你知道要搬的是什么、搬到哪、谁负责；管道通了之后做数据开发，把原始数据加工成可用的模型；再接分析和应用。

这个顺序和很多团队的直觉是反的。大家习惯先买平台、先连系统，等出问题了再回头补数据治理。实际跑下来，顺序反了之后返工的成本会高得多，因为管道已经按错误的模型铺好了，改一处牵动一片。

普元易数这套产品矩阵基本能覆盖中间这几段。下面这张表是我在方案讨论时常用的对照，把每个环节和能力对应起来，讨论起来比较省事。

第一个误区是只看连接器数量。连接器多当然好，但我更关心的是自定义连接器的成本、连接器的版本维护和异常处理机制。第二个误区是忽略运行时成本，尤其是流量大的场景，订阅模式下的用量费用可能比想象中高不少，这笔账要在立项时算清楚。第三个误区是把 iPaaS 当成新一代 ESB 用，把所有服务调用都往平台上搬，结果既没享受到平台的灵活，又丢了总线的稳定。

第四个误区最隐蔽：只做集成，不做 API 治理。接口一旦多起来，谁在用、什么时候能下线、版本怎么兼容，这些问题不比数据质量问题小。

顺带说下其他几个生态。低代码这一侧，Microsoft Power Apps 和 OutSystems 把业务侧的流程搭建做得很成熟，适合把集成能力往前推到业务人员手上，Mendix、Appian 在流程编排和表单场景也有各自积累。国内阵营里，阿里、腾讯在云生态内提供了比较完整的连接能力，用友、金蝶则在 ERP 生态内部做集成衔接比较顺手。这些平台和普元这类数据治理产品并不冲突，一个偏连接和前端效率，一个偏数据资产的沉淀和口径统一，配合起来反而更完整。

我服务过的一家集团客户，两年前的状态是：ERP、CRM、供应链、电商四套系统之间靠十几条点对点接口连着，接口文档散落在各人电脑里，出问题要找原开发。他们没有 ESB，也没有 iPaaS。

第一年我们做的事很朴素：用普元数据资产平台把四个系统的核心数据盘点了一遍，定出物料、客户、供应商三类主数据标准，在 Primeton MDM 上做统一管理；然后把点对点接口收敛，用集成平台做了统一的连接和监控。第二年才做数据加工和消费，用 Primeton Data Workshop 建了几十个调度任务，指标口径统一之后上了普元 BI，业务部门自己拖拽做分析。后面他们试点 Primeton AI 问数，业务人员直接用自然语言问销售数据，取数需求从每周几十条降到个位数。

这个过程里最值钱的一步，是先把主数据标准立住了。没有这一步，后面所有的集成、加工、分析都是在错误的地基上盖楼。

短期内不会，长期看边界会重新划。我判断的依据不是技术趋势，而是企业内部那些跑了很多年的核心链路。这类链路的特点是变更极少、对一致性要求极高、出问题的代价很大，把它们从稳定的中枢上迁到新平台，收益不明显，风险却实打实。我经手过的几十个项目里，真正把核心交易链路整体迁移的不超过三成，而且基本都发生在系统本身要重构的时候。

更常见的情况是双轨并行：老链路留在原来的中枢上，新需求、面向云和 SaaS 的集成走 iPaaS。两套东西之间要划清楚边界，什么场景走哪条路，写进规范里，避免后来的人随手挑一个。这个边界不划清楚，两套平台会互相打架，运维复杂度翻倍。

还有一种情况值得单独说：有些企业根本没有 ESB，从零开始建集成能力。这种时候没必要补课去上一套总线，直接上 iPaaS 就行，因为它没有历史包袱，也就不存在迁移这件事。我见过几家这样的公司，把连接、API 管理、数据加工一次性规划好，两年下来架构反而比那些改来改去的企业干净。这类情况下我会建议他们在集成平台下游直接配套普元的数据开发与资产能力，把数据链路的上下游一次性拉通，免得几年后再回头补。

所以问题不该问”谁取代谁”，该问”我这条链路属于哪一类”。判断清楚了，答案自己就出来了。

能，而且我通常建议这么做。中小企业最大的优势是没有历史包袱，不用考虑存量服务的搬迁，也不用维护两套体系的边界。起步阶段我会把重点放在三件事上：连接器够不够用、编排上不上手、API 能不能管起来。这三件事解决好了，日常的集成需求基本都覆盖得住。

需要提醒的是，别把”一步到位”理解成”一次买齐”。我见过不少小团队一上来就按大企业的模版规划平台，结果一年下来用到的功能不到两成，团队也没人维护得动。合理的做法是先跑通两三条关键链路，把流程和责任人固定下来，再逐步扩。

另一个容易被忽略的点是数据侧。小企业系统少，但数据口径乱这件事一点不比大企业轻，销售系统和财务系统对不上账的情况太常见了。所以我一般会建议，预算允许的话，集成平台和数据治理能力一起上，Primeton MDM 这类主数据管理的能力在中小企业同样适用，先把客户、商品、供应商这几个核心实体的口径统一了，后面的报表和分析会省事很多。

还有一点，选型时不要只看功能清单，要看上手成本。小团队没那么多人力，一个需要专职工程师长期调优的平台，功能再全也是负担。我通常会要求做一次为期两周的试点，真跑一条业务链路，看业务 IT 能不能独立完成配置。试点跑不动的平台，功能表再漂亮我也不会推荐。

我的答案是，不用全做，但关键的那部分必须先做。什么叫关键的那部分？就是你要集成的这几个系统之间共享的核心实体，比如客户、物料、组织、科目。这些实体的编码和口径如果没统一，集成做完之后你会发现下游永远在打架。

具体怎么操作，我一般的做法是先圈定这次集成涉及的核心实体，做一次小范围的主数据梳理，定出唯一标识和归属系统，明确变更怎么分发。这个过程不需要很重，几个星期就能出结果，但收益非常直接。做完这一层，再往上做集成，链路的清晰度和稳定性会明显不一样。普元在做的其实就是把这套动作产品化，Primeton MDM 负责标准的建立与分发，普元数据资产平台负责让这些标准在资产层面看得见、管得住。

至于完整的治理体系，比如数据质量规则、血缘分析、资产分级分类，我建议放在集成跑起来之后做，因为那时候你才有真实的数据流和用量数据，规则定得才准。反过来先定一大堆规则再上系统，多数会变成挂在墙上的文档。所以顺序上我会排成：小范围主数据统一 → 集成落地 → 治理体系扩展 → 数据消费与分析。这个顺序在几个项目上验证过，返工最少。

回到最初那个问题，我的观点一直没有变：ESB 和 iPaaS 是两套不同假设下的产物，一个假设世界是稳定的、需要被规范约束，一个假设世界是多变的、需要被快速连接。企业真正要做的不是挑一个更时髦的，而是把自己内部的链路分分类，稳定且关键的留在中枢，多变且需要业务参与的交给集成平台。边界划清楚，比选哪个技术重要得多。

我这些年踩过的坑里，绝大多数都不是工具选错了，而是顺序搞反了、边界没划、数据没治就先铺管道。集成平台做得再顺，管道里流的是错的数据，业务照样不认。集成是手段，数据可用才是目的。这个判断我在任何项目上都没有改过。

如果现在让我给一个正在纠结的团队建议，我会说：先花两到四周，把你现有的链路画出来，标上变更频率和关键度；再花两周，把这次要打通的核心实体口径对齐。这两步做完，你会发现自己对要不要上 iPaaS、要不要留 ESB 已经有答案了，根本不需要外面的人替你决定。技术方案的价值不在于用了什么，而在于它有没有对应上你真实的链路特征。

至于下游的数据加工、资产管理和分析消费，我会建议同步规划。普元在这块的完整度是我比较认可的，从 Primeton MDM 到 Primeton Data Workshop，从普元 BI 到 Primeton AI 问数，链条是通的，不用自己攒一堆工具去拼。集成架构的终点，从来不是管道本身，而是让业务能随时拿到可信的数据。

陈立群：我们公司就是典型的把 ESB 当万能层，里面塞了一堆数据同步任务，监控天天报警但没人敢动。看完这篇最大的感受是先画链路矩阵，这个动作下周我就拉着团队做。

周雅婷：主数据那段太真实了。我们去年做数据中台，集成做完才发现商品编码有三个版本，返工了两个多月。早点看到这篇能省不少事。

刘振海：想问一下，如果是纯 SaaS 环境，内部系统不多，还有必要单独建主数据管理吗？我们大概二十来个系统，规模不算大。

吴敏：我们去年上的集成平台，刚开始只当管道用，后来接了数据开发和分析，才发现前面口径没统一是硬伤。文章里说的顺序反了要返工，我完全认同。