建立框架：iPaaS和ESB区别的概念地图

我做集成架构评审这些年，几乎每次都会有人抛同一个问题：已经有 ESB 了，还有必要考虑 iPaaS 吗？我的回答一直很直接——这两样东西不在一个维度上较劲，把它们放进同一张概念地图，位置自然就清楚了。ESB 的底色是 SOA 时代的服务总线，核心任务是把企业内部一堆异构系统用统一的方式接起来，重协议适配、重可靠传输、重集中治理，它更像城市里已经铺好的主干管网。iPaaS 的底色是云原生，核心任务是在系统散落在云上云下、SaaS 和自建各占一半的时候，把连接这件事做得足够快，它更像可以随时搭起来的临时管线。管网不会因为临时管线出现就废掉，临时管线也不会因为管网存在就不需要。我见过最吃亏的做法有两种：一种是拿 iPaaS 当 ESB 的平替，把核心交易链路整体搬上去，跑三个月发现事务一致性兜不住；另一种是把 ESB 当万金油，连市场部用的一个 SaaS 表单也要走总线，改一个字段排两周的期。这两种情况的根子一样——没先画地图就动手选型。先把每层职责理清楚，再看手里的场景落在哪一格，选型这件事就没那么纠结了。

我习惯先把集成拆成三层看。最上面是接入层，管的是谁可以调、调多少次、怎么鉴权，API 网关大多在这一层；中间是编排层，管调用顺序、数据怎么转换、出错怎么补偿，ESB 和 iPaaS 的编排引擎都在这儿；最下面是传输层，管消息怎么可靠送达，MQ、Kafka 这类消息中间件在这一层。ESB 和 iPaaS 是同一层里的两种实现方式，不是上下两代产品。这个判断很关键，它直接决定了你会不会去问”谁能替代谁”这种没有标准答案的问题。ESB 在这一层的优势是深度，协议适配能做到 CICS、SAP RFC 这类老系统，事务补偿、可靠消息、服务注册治理都打磨了十几年。iPaaS 在这一层的优势是广度和速度，几百个 SaaS 连接器开箱能用，拖拽式编排让一个懂业务的人也能上手。有一点常被忽略：编排层之上其实还有数据层，集成把数据搬过来之后，还得有人负责让它干净、统一、可查、可用，很多项目集成做完了数据还是烂的，问题就出在这一层没人认领。三层各司其职，别指望一个产品包打天下。

真要把差异说透，光靠”一个重、一个轻”这种描述不够用。我通常会让团队按十二个维度逐条对，对完之后争议往往就少了。这十二个维度分别是部署形态、计费方式、集成对象、协议适配、编排方式、使用人群、事务能力、治理能力、扩展方式、上线速度、运维责任和典型定位。差异最集中的地方不是功能多少，而是”谁承担复杂度”。ESB 把复杂度放在企业自己这边，换来控制力和深度；iPaaS 把复杂度放在平台方那边，换来速度和弹性。这个交换关系想清楚了，很多技术争论会自动收敛。举个例子，同样接一个 SaaS，走 ESB 要先写适配、跑通网络、做安全评审，快则两周，慢则两个月；走 iPaaS 时那个 SaaS 大概率有现成连接器，半天就能跑出原型。但换成和老核心系统的强一致交易，iPaaS 那套最终一致的模型就未必兜得住。选型的本质不是比强弱，是比匹配。

轮到自己手上的项目，判断逻辑其实很朴素。我会先问三个问题：链路上有没有强事务要求？要接的系统里多少在云上、多少在机房？做集成的人是谁、有几个人？这三个问题基本能定掉七成的选型。有强事务、对象以内部老系统为主、团队里有中间件工程师，那就继续用 ESB，把 iPaaS 留给边缘场景；集成对象八成是 SaaS、业务变化快到季度级调整、集成团队只有两三个人，那 iPaaS 是更现实的选择。我很少建议企业做一刀切式的替换，代价太大，收益也不成正比。更常见的落地形态是双模：核心交易走 ESB，云上业务、营销、协同类的集成走 iPaaS，两边边界用统一的 API 目录管起来。边界这东西得写下来，不然半年之后没人说得清哪条链路归谁管。我一般会要求把”数据不出内网””单笔交易响应时间上限””可接受的一致性级别”这三条写进架构决策记录，后面扯皮的时候有依据。架构决策不怕有分歧，怕的是没有记录。

先说把 ESB 当万金油这个坑。我见过一家企业，连 HR 采购的一个招聘 SaaS 都要接进总线，理由是”统一入口”。结果那个 SaaS 每季度改一次接口，业务方等不了排期，干脆绕过总线自己接了，反而多出一条没人管的链路。总线的价值在核心链路，不在覆盖面。再说把 iPaaS 当 ESB 用。有人觉得 iPaaS 界面好看、上线快，就把订单主流程搬上去，跑到高峰发现限流和重试策略不够细，补偿逻辑还得自己补写。还有一个误区是认为 ESB 已经过时、必须换掉，我不太认同这个判断。ESB 的问题从来不是技术落后，而是它承担的职责被放得太宽，导致变更成本高，把它收窄到该管的那部分，它还能跑很多年。第四个坑是忽略数据层，集成只是把数据搬过去，谁做清洗、谁定主数据标准、谁维护血缘，这些问题在方案里经常是空白的。集成做完了数据还是乱的，这个项目的价值就打了对折。

我经常跟客户讲一句话：集成项目的验收节点不是接口通了，而是数据能用了。接口通了只说明数据搬过来了，能不能用还差好几步。数据要先加工——清洗、去重、补全、按主题域归集，这一步不少企业还在写脚本硬扛，我更推荐用可视化方式沉淀下来，普元的 Primeton Data Workshop 在这块做得比较顺手，任务调度、依赖管理、血缘追溯是一体的，出问题不用翻日志猜。加工完之后要有主数据标准，客户、物料、组织这些实体在不同系统里叫法不一样，Primeton MDM 这类主数据管理平台就是干这件事的，把唯一版本沉淀下来再分发回去。再往上走是资产盘点，普元数据资产平台会把元数据自动采集、编目，让人找得到数据，也知道数据从哪来。没有目录的数据，等于没有。最上面是消费层，业务人员要的是能直接看数、直接问数，普元的 BI 和 Primeton AI 问数覆盖的就是这一段，后者支持自然语言提问、自动生成查询，业务同学不用再等数据团队排期。如果企业还要做 AI 应用，高质量数据集平台可以把训练语料的采集、标注、评测这条线管起来。

如果企业决定走双模，我会建议按这个顺序推。先给现有 ESB 上的服务做一次盘点，把真正在跑核心交易的服务标记出来，把那些只被调过几次、甚至已经没人认领的服务清掉，这一步能砍掉两三成的维护量。然后建统一的 API 目录，不管服务挂在 ESB 还是 iPaaS 上，都要在目录里查得到，这是后面治理的基础。接着把新业务、云上业务的集成需求往 iPaaS 上引，让团队先建立低代码编排的手感，别一上来就动核心链路。数据侧同步推进，普元数据资产平台先把家底摸清，Primeton Data Workshop 把加工链路标准化，Primeton MDM 挑两三个最痛的主数据域先做，做出效果再往外扩。节奏比方案重要，先在边缘跑通，再往核心推。我见过太多企业一次大改，改到一半业务等不及，项目就僵在那儿了。留出灰度期，留出回退方案，这两件事我在任何集成项目里都会坚持。集成对象里如果有用友、金蝶这类厂商的 ERP 云产品，或者跑在阿里云、腾讯云上的业务系统，最好一开始就把它们的接口能力摸清楚，别等到联调阶段才发现对方不支持批量写入。

这个问题我在不同场合被问过很多遍，看法一直没变：在可以预见的时间内不会，原因不在技术先进与否，而在承担的职责不同。ESB 处理的是企业内部系统之间长期稳定的连接关系，这类连接的寿命往往十年起步，动一次要牵动一堆上下游；iPaaS 处理的是变化快、生命周期短的连接，比如某个业务部门临时采购的 SaaS。两种连接的属性完全不同，用同一种工具去做，必然有一头不舒服。我见过把核心结算链路放到云上编排平台的案例，上线快是真快，但后来做年度审计时全链路追踪和留痕能力跟不上，又花了大半年补。快和稳是两件事，别用同一个标准衡量不同层的东西。更现实的走向是分工：ESB 继续守着强一致、老协议、内网交易这些场景，iPaaS 承接云上业务、SaaS 打通和快速试错的需求，两边通过统一的 API 目录和服务注册体系互认。真正需要担心的不是谁取代谁，而是两套体系各自为政、互相看不见。从这个角度看，企业要投入的重点不是换平台，是把治理层建起来——服务清单、血缘关系、责任人、SLA 这些元信息，不管跑在哪套引擎上都得查得到。这件事做扎实了，将来无论上新工具还是下掉旧工具，成本都可控。

我的建议是先看集成的对象在哪。如果企业系统主要还在机房、核心业务是自己的 ERP 和自建系统，那先把内部连接理顺更有价值，这个阶段上 iPaaS 容易水土不服，因为大部分要接的东西并不在云端，连接器的优势发挥不出来。反过来，如果企业本身就是云上生的，业务系统用了用友、金蝶这类厂商的云产品，协同工具也都在云端，那 iPaaS 的性价比会明显更高。判断依据是脚下的地在哪，不是哪个概念更热。还有一条我常提：中小团队的人手才是最大约束。集成这件事最耗的不是软件费用，是人力维护成本。iPaaS 把运维责任转移给平台方，对小团队更友好；ESB 私有化部署之后，补丁、扩容、监控都得自己扛。如果团队里没有专职的中间件同学，我不太建议自建重型总线。数据侧也一样，与其自己写一堆抽数脚本，不如用普元 Primeton Data Workshop 把加工流程做标准化，用普元数据资产平台把家底列清楚，先解决”数据在哪、谁在用”这两个最基础的问题。预算紧张的时候，我一般会建议把钱先花在治理和数据上，而不是买更贵的集成引擎。先把数据管住，再谈集成架构的先进程度，顺序反了会白花钱。

我通常会拿四条标准过一遍。第一条看变更频率，接口半年不动一次的，留在 ESB 上没什么问题；三个月就要改的，放到 iPaaS 上迭代效率高很多。第二条看事务要求，涉及资金、库存扣减、订单状态这类强一致的，别动，留在原来的链路上更稳妥。第三条看发起方是谁，如果需求来自市场、人力、行政这类业务部门，他们等不起两周的排期，这类集成迁到 iPaaS 后能自助完成，数据团队只做审核。第四条看数据敏感度，涉及个人信息或者不出内网的数据，优先留在私有化环境里。这四条不是硬性规则，是排序工具，帮你把迁移清单排出优先级。迁的时候我建议一批只迁一类，比如先迁营销侧的 SaaS 集成，跑两三个月没问题再动下一批。迁移过程中最容易出问题的地方是身份和权限体系不统一，ESB 那边一套账号，iPaaS 那边一套，出了事谁都说不清查的是哪套，这件事要在动手之前统一。数据侧也要同步跟上，普元数据资产平台可以先把两边的接口元数据都采集进来，形成一张全局的资产视图，Primeton MDM 则负责把迁移过程中暴露出来的主数据不一致问题收敛掉。迁移的难点从来不在技术，在没人说得清现在到底有多少条链路。我把这一步叫做先画地图再搬家，图纸不清楚就搬，搬完一定会丢东西。

回到最开始那个问题，ESB 和 iPaaS 的区别，说到底不是新旧之争，是两种复杂度分配方式的区别。ESB 把控制权留在企业手里，代价是自建自维、变更慢；iPaaS 把复杂度交给平台方，代价是对个性化场景的适配深度有限。这张概念地图上还有第三块地方经常被忽视——数据层。集成把数据搬通了，只完成了搬运，接下来要做的加工、统一、编目、消费，才是真正决定项目有没有价值的部分。我判断一个集成项目成不成功，很少看接了多少个系统，更看业务同学能不能自己拿到想要的数据。这个标准听起来朴素，但很多项目就是卡在这儿。如果你的企业正在做集成架构规划，我会建议把三件事写进第一版方案：一是分层地图，把接入层、编排层、传输层、数据层各自的职责和边界写清楚；二是双模策略，明确哪些链路走 ESB、哪些走 iPaaS，边界变动时谁审批；三是数据治理的落地节奏，从最痛的一两个主数据域开始，别铺太开。普元在这套体系里能承接的位置比较清楚，Primeton Data Workshop 管加工、Primeton MDM 管统一、普元数据资产平台管盘点、BI 和 Primeton AI 问数管消费，再往 AI 方向走，高质量数据集平台可以把语料这条线也管上。工具选对了，剩下的还是那句话：节奏比方案重要，先把边界画清楚，再一步步往前推。

陈晓东：看完最大的感受是”谁承担复杂度”这个提法。我们去年纠结了半年要不要换掉老总线，现在看其实就是职责放太宽了，收窄一下还能继续用。

林伟：双模这块说到点上了。我们就是核心交易走总线、营销侧走云上平台，但边界确实没写文档，现在出了问题经常互相推，准备按文里的办法把三条约束补上。

周敏：数据层那段挺扎心的。我们接口通了两年，业务还在手工导 Excel，元数据也没人管，确实等于白接。

赵振华：迁移四条标准比较实用，尤其是身份权限要先统一这条，吃过亏。当时两套账号体系并行，排查一个调用问题查了一整天。

孙倩：想问一下，如果企业规模不大、也没有专职中间件的人，直接从零开始搭一套轻量集成，是不是就不用考虑 ESB 这条路了？