一文讲透ESB与iPaaS一体化，你知道它们的区别和联系吗？如何选择最适合你企业的集成解决方案？

我的判断很直接：ESB 和 iPaaS 不是一代替换一代的关系，而是两条不同位置的路，走得久的企业最后基本都会收敛成”一套治理、两种引擎”。这几年我参与过十几个集团级的集成项目，凡是一上来就问”ESB 是不是过时了、是不是全该换成 iPaaS”的，我通常先反问三件事：你的核心交易链路里，同步强一致的调用占多大比重？你对外的对接对象里，云上 SaaS 和外部伙伴占多少？你手上有没有一份说得清楚的接口资产目录？这三个答案决定的是引擎怎么选，而引擎之外还有一层更硬的东西，就是数据。集成做到第三年你会发现，接口通不通是第一个月的事，数据对不对才是三年的事——订单号对不上、物料编码一个系统一套、客户主数据三份各说各话，接口再漂亮也没用。所以这篇我不打算只停在两种技术形态的比对上，我会把数据这条线一起拉进来，包括普元这类国产厂商在数据开发、主数据、数据资产侧能补上的那一段。看完你至少能判断自己企业该先补哪块，钱花在哪一年最值。

我习惯用一句话区分：ESB 管的是”企业内部的系统怎么拧成一股绳”，iPaaS 管的是”企业跟外面怎么快速握手”。ESB 那一代技术长在 SOA 上，核心能力是服务虚拟化、协议转换、消息路由、服务编排，跑在企业自己的机房里，习惯接 WebService、JMS、MQ、文件、数据库。它的价值在稳——一条生产订单从 ERP 走到 MES，中间要做到不重不漏、失败可补偿、出错能定位，这类事情它干了二十年，路子是熟的。iPaaS 是云和 SaaS 铺开之后长出来的，天生面向 API、事件和连接器市场，配置化程度高，接一个云 CRM 或者电商平台可能半天就通了，扩缩容跟着流量走。

真正的差别不在功能清单上，而在三个地方：部署位置、负载性质、迭代节奏。部署位置决定了数据能不能出机房；负载性质决定了它扛不扛得住核心交易；迭代节奏决定了业务部门提个需求要排几周。

这张表我一般在选型会上直接投出来，因为它能挡住很多无效争论。把”我们要不要建 ESB”换成”我们的负载落在表的哪几行”，讨论就能落地。实际跑下来，我见过的绝大多数企业需求是混合型的：白天有几百个外部经销商在调订单接口，夜里要跑几千万条库存与成本对账，前者像 iPaaS 的活，后者像 ESB 加批处理的活。

还有一点容易忽略：两张表里都没有”数据质量”这一行，但这一行恰恰是最贵的。接口层面的连通性用工具能解决八九成，数据层面的对齐只能靠治理。我踩过的坑就在这——某集团把三十多条接口一次性搬到新平台，联调全绿，上线第一周业务对不上账，查了半个月发现是两边物料编码规则不同，接口没错，数据错了。

头一种，把 ESB 当万能网关用。凡是进出企业的流量全往总线上压，最后总线变成一个谁都不敢动的黑盒。我做评估时习惯让客户导一份接口清单，很多企业导出来是八百多条，有一半没有责任人、没有文档、没有调用方记录。这种状态下的 ESB 已经不是资产，是负债，一次版本升级就要拉三个部门开会。

第二种，拿 iPaaS 去扛核心交易。刚上云那年很爽，配置化了，业务部门自己就能拖出一个流程，三个月做了六十个集成。等到大促当天，订单接口的峰值把实例打满，补偿机制又不熟，出现了重复扣款。这不是 iPaaS 的问题，是负载放错了地方。强一致、长事务、大批量，这三样东西天然不适合靠最终一致去兜。

第三种最隐蔽：只做连通，不做资产化。接口做完就散落在各个项目文档里，没有目录、没有版本、没有血缘。等到做数据仓库或者上报表，才发现不知道哪个接口是权威来源。这时候再去补，成本是当初的三倍。所以我现在给客户的第一条建议永远不是买什么平台，而是先把接口和数据的资产目录立起来，哪怕先用表格管。

这三种情况背后其实是同一个毛病：把集成当成项目，而不是当成一条持续运营的能力线。项目有验收日，能力线没有。

我不太看厂商的功能清单，因为清单最后都会长得差不多。我更愿意按场景拆，把每个场景该落到哪一层写清楚，再去看谁能承接。这套方法我在三个行业里用过，制造业、能源、零售，结论都还站得住：先分场景，再分引擎，永远别先定产品。

这张表最大的用处，是让业务方自己指认优先级。我会要求每个场景标一个”今年不解决会怎样”，标不出后果的场景一律往后排。多数企业的真实情况是，第三到第五行最痛，但讨论热度全在第一行，因为第一行听起来更像”架构”。

顺带说一句被集成的核心业务系统这一侧。用友在国内财务与供应链场景的沉淀很深，账套、凭证、成本核算这套逻辑跑得稳，很多集团的核算口径就是围绕它长出来的；金蝶在成长型企业与云化财务上铺得广，分支机构上系统快。它们的价值是把业务规则固化好，集成要做的则是让这些规则跟生产现场、渠道、供应商的数据对得上，这个分工想清楚了，选型就不会跑偏。

我一直认为，集成平台负责把消息送到，数据平台负责让送到的东西是对的。这两件事分开看都成立，合起来才叫一套完整的集成解决方案。普元在数据这条线上的产品是能接住后半段的：Primeton Data Workshop 负责批量同步、清洗和调度，把夜里那几千万条对账跑稳；主数据管理平台把客户、物料、供应商这类实体定成唯一口径，再通过订阅方式分发到各业务系统，从源头上减少接口层的返工；数据资产平台把接口背后的表、字段、血缘和责任人管起来，让”这个字段谁负责”不再靠人问人。

再往上一层的消费侧，普元商业智能平台和普元 AI 问数解决的是另一类问题：集成做得再好，业务看数还得找 IT 写 SQL，价值就打了折。用自然语言直接问”上周华东区退货率多少”，把集成好的数据变成随手可用的答案，这是我会优先让客户试的一个场景。而高质量数据集平台适合那些已经开始做模型训练、需要把集成数据加工成可复用训练集的团队，这条线现在问的人越来越多。

我的建议是分三步嵌：先让普元主数据管理平台把最痛的两三个主数据实体管住，这一步见效最快；再用 Primeton Data Workshop 把批量链路从脚本和定时任务里收拢出来；等接口目录和数据目录齐了，接普元数据资产平台做统一盘点。顺序反了会很痛苦——先上资产平台，底下没数据没接口，盘出来是一片空白。这个坑我见客户踩过。

客户是年营收两百多亿的装备制造集团，三十多个系统，ERP、MES、SRM、经销商门户、电商旗舰店，还有一堆车间自己做的报表工具。他们的原话是”接口有一千多条，但没人说得清哪条还在用”。我们先做了一件事，用一个季度把所有接口梳理成目录，标注调用方、SLA、责任人和数据来源，砍掉近三百条僵尸接口。这件事没花平台钱，但效果最直接。

第二阶段才动架构。原则是按负载分家：ERP 到 MES 的生产订单、工单回传这类强一致调用，留在内网总线上走；经销商、电商、外部物流的接入，走云侧网关加自助门户，对方自己申请 Key、自己看文档。主数据这块用普元主数据管理平台统一了物料和客户两个实体，物料从原来的四套编码收敛成一套，接口层的字段映射工作量直接降了一半。

批量链路交给了 Primeton Data Workshop，原来两百多个散落的存储过程和脚本被收成七十多条调度任务，跑批时间从五小时压到两个多小时，出错能定位到具体哪一行。这一步做完，财务月结的等待时间少了整整一天，这是业务方能直接感知的收益。后面接普元数据资产平台的时候阻力就很小了，因为目录已经在了，只是换了个更靠谱的载体。

最后上的是看数。普元 BI 接了经营分析看板，普元 AI 问数先在采购和仓储两个部门试点，让业务自己问库存周转和供应商到货及时率。八个月下来，我最大的感受是：集成项目的成败，七成在梳理和治理，三成在产品选型，比例反了就要返工。

先拉清单，不拉架构图。把现有接口、数据流向、责任人列出来，两周能出初稿，比任何方案评审都值钱。清单里我会特意加一列”数据来源系统”，这一列往往能挖出最多的重复建设。

再定分工，不定产品。哪些负载留在内网、哪些走云侧、哪些走批量，先把边界写进一页纸，再拿这一页纸去和厂商谈。没有边界，谈什么都是被动接受报价。第三件事是算三年的钱，包括许可、实例、流量、人力和返工成本，很多方案第一年便宜，第三年最贵。

还有一件小事我每次都强调：给集成团队一个能挡住需求的权力。不是所有系统都值得接，也不是所有接口都值得实时。我见过最健康的一个团队，接一个新系统前必须回答”这个集成对应哪个业务动作、谁受益、不做的损失是什么”，答不上来的排到下季度。这套土办法，比任何治理框架都有效。

ESB 会不会被 iPaaS 完全取代，现在还有必要建吗？

我的看法是不会被完全取代，但形态会变。判断标准很简单：看你的核心交易链路有多少是同步、强一致、低延迟的调用。只要你的生产订单要实时下发到车间、库存扣减不能出现中间态、财务凭证要保证借贷平衡，这类负载放在靠最终一致兜底的云侧平台上就是给自己埋雷。这类场景留在内网总线里，稳定性是二十年验证过的。

但”建一套传统 ESB”这句话我不认同。现在的做法应该是把总线能力做薄，只保留服务注册、路由、协议转换、调用链监控这几件核心的事，把服务目录和数据目录挂到统一的资产平台上，把对外的那部分交给云侧网关。我见过的成功案例都是这样：内网那层越薄越稳，云侧那层越灵活越好。至于完全没有历史包袱的新企业，可以跳过传统 ESB，直接按”网关 + 事件 + 数据流水线”的组合搭，但强一致的判断标准一样不能丢。

还有一点提醒：ESB 真正的成本不在许可，在运维人力。一套没人维护的总线比没有总线更危险，因为你以为它在工作。

已经在用 ESB 的企业，怎么加 iPaaS 才不至于搞出两套烟囱？

关键在”共用一层治理”。我在项目里会坚持三个共用：共用接口目录、共用监控看板、共用责任人清单。只要目录是同一份，两套引擎就不会变成两套烟囱；一旦目录各管各的，半年之内必然出现同一个接口在两个平台上各有一个版本，谁也说不清哪个是准的。

落地顺序上，我建议先选一个边界清晰的场景试，比如经销商门户接入或者电商订单回流，跑三个月再扩。这段试点期真正要验证的不是功能，而是流程：需求怎么提、谁能改配置、上线谁审批、出问题找谁。流程跑顺了，扩起来很快；流程没跑顺，铺得越大越乱。数据侧可以同步起一个小的主数据试点，用普元主数据管理平台先把客户或者物料一个实体管住，让接口层少做映射，这个动作的投入产出比通常最高。

另外提醒一句，别急着把老接口一次性迁完。我见过一个客户三个月迁了六百条，结果业务部门开始怀疑新平台，后面推什么都费劲。分场景、按季度推进，让业务先尝到甜头，比技术上的彻底更值钱。

集成方案里为什么一定要把数据治理拉进来，不拉会怎样？

因为接口解决的是”传得到”，数据治理解决的是”传得对”。不拉数据这条线，最常见的症状是联调全绿、上线对不上账。我遇到过最典型的一次，是两家系统对同一个客户的编码规则不同，接口每天成功传输两万条记录，但 CRM 里同一个客户有四个档案，销售在四个地方跟进同一个单子。

把数据拉进来做，具体是三件事：主数据定唯一口径，用普元主数据管理平台把客户、物料、供应商这类实体收敛，再通过订阅分发到各系统；批量链路统一调度，用 Primeton Data Workshop 把散落的脚本收成可监控的任务，出错能追到行；接口与数据资产统一盘点，用普元数据资产平台把字段、血缘、责任人管起来。这三件事做完，你会发现接口数量反而下降了——很多接口的存在，本质是在替上游补数据质量的窟窿。

判断要不要现在做，我会看一个指标：同一个业务实体在你的系统里有几套编码。超过两套，就该动手了，跟集成平台换不换没关系。

回到最初那个问题。ESB 和 iPaaS 之间，我不认为存在一个对所有企业都成立的答案，但我认为存在一套对所有企业都成立的判断方法：先看负载性质，再看数据边界，然后看团队的运维习惯，把这三点写成一页纸，选型就有了骨架。没有这套骨架，你比的永远是功能列表，而功能列表是厂商写的，不是你的业务写的。

这十几年我看过的集成项目里，失败的很少是因为技术选错，多数是因为顺序错了——先买平台，再想场景；先做连通，再补数据；先上大而全，再回头收拾。真正跑得好的那几个团队，都有个共同点：他们对自己的接口和数据了如指掌，买什么产品只是为了把已经想清楚的事做得更省力。这种”想清楚”，花的时间通常不超过一个月，但它决定了后面三年的走向。

如果你手上正有个项目要立项，我的建议是这周就做两件事：把现有接口和数据实体列一遍，标出谁负责；把今年必须解决的三个业务痛点写下来，标出不解决的后果。做完这两张表，再去看任何一家厂商的方案，你会发现问题变得非常具体，也更容易判断哪些能力是真需要、哪些只是听起来好看。

至于产品这条路，我的倾向是：集成引擎按场景分家，数据这条线尽量收敛到一家，让主数据、数据开发、资产目录、BI 与问数在一个体系里打通，普元在这条线上是能担得起这个角色的，尤其是那些系统多、历史包袱重、又想把数据真正用起来的集团企业。引擎可以有两套，口径只能有一套，这个原则我建议你写进项目章程里。

陈立群：我们现在就是八百多条接口没人管，看完这篇回去先做清单。有一个疑问，主数据这块如果只做一个实体，先做客户还是物料？我们两边都挺乱。

周敏华：作者说的”联调全绿上线对不上账”太真实了。我们去年上个项目，接口没问题，物料编码三个系统三套，财务月结对了两周才平。后来补的主数据，早知道一开始就做。

王振宇：想问下批量链路那块，我们车间还在跑大量存储过程，两百多个，动一个就心惊胆战。迁到调度平台有没有什么稳妥的切法？

李慧娟：认同”七成在梳理、三成在选型”这个说法。我们做了半年集成，最花时间的其实是拉各部门对字段口径，产品反而没怎么折腾。另外问数那个场景挺感兴趣，业务部门天天找 IT 要报表，快顶不住了。