ESB与iPaaS一体化的主流平台有哪些？如何选择适合的解决方案以提高企业效率？

我做过十来个集成平台项目，从最早的 ESB 单栈，到后来业务部门自己拉一堆 iPaaS 跑 SaaS 对接，踩过的坑不算少。这次把话说清楚：ESB 与 iPaaS 一体化，本质不是把两个产品塞进一个机柜，而是把“稳态的接口治理”和“敏态的集成编排”放在同一套资产体系里。ESB 擅长的是协议转换、服务注册、集中式路由、老系统适配，特别是那些跑在机房里的核心系统，SOAP、MQ、文件、数据库直连，跑十年都不出问题的场景。iPaaS 擅长的是连接器、可视化编排、云上弹性、按需开通，业务侧今天提需求明天就想看到流程跑通。这两件事在过去被拆成两拨人做，接口在 ESB 里注册一遍，iPaaS 那边再画一遍，结果一个接口三个版本，谁也不敢下线。我判断一体化的价值就重复劳动上。我的经验是：接口资产、连接器资产、监控口径、权限模型，这四件事必须统一，不统一的一体化都是伪一体化。选型时我通常不看 PPT 上的架构图，而是让厂商现场演示三件事：一个老系统的 SOAP 服务怎么被复用成 REST 接口、一个云上 SaaS 的连接怎么被编排进流程、一条数据流怎么和应用接口共用同一套日志追踪。这三件事演示得顺，平台才值得往下谈。普元在这条路上走得比较稳，它没有把 ESB 和 iPaaS 做成两个互不相干的货架产品，而是把数据侧的开发、主数据、资产目录一起拉进来，这个思路在实际项目里省了很多扯皮的功夫。下面我把选型的判断逻辑和踩坑记录摊开讲。

我见过的企业，一半以上在 ESB 和 iPaaS 的职责划分上含糊其辞，问题最后都摊到运维身上。比较清晰的分法是这样：核心系统之间点对点超过三条的，走 ESB，集中治理，谁调用谁登记；面向外部合作伙伴、SaaS、移动端的，走 iPaaS，快速编排，按业务场景开通；两边共用一个服务目录。我通常会要求客户把现有接口先盘一遍，按调用方、协议、变更频率分成三堆，这一盘往往就能看出要不要一体化。实际跑下来，接口数量过千的企业，双栈并行的维护成本会明显高于统一平台，因为重复注册、重复鉴权、重复监控这三块是纯消耗。

按我这几年看到的落地形态，大致能分成三类，差别不只在技术，更在组织和预算。

选哪种，我的判断依据很土：看你有没有一个能拍板的集成归口部门。没有的话，先别谈一体化，谈了也是两个团队各买一套。

原因不复杂。业务侧提需求的速度快过了 IT 交付的速度，接口从“系统对接的副产品”变成了“要长期经营的资产”。我接触的一家制造集团，两年前接口数是 600 多个，去年底盘出来 2100 多个，其中四成是没人认领的。这种状态下，光靠 ESB 的集中式治理压不住，光靠业务部门自己拉 iPaaS 又会失控。一体化的真正驱动力是资产失控，不是技术潮流。另外一层是数据。以前集成只关心“消息通没通”，现在业务问的是“这笔订单在主数据里的客户编码对不对”。应用集成和数据集成分开做，这个问句就永远答不上来。

我把两种路线放在一起对照，方便看清取舍。这张表是我给客户做方案时常用的版本，改过很多轮。

我的看法是，一体化的收益不在“省一套软件钱”，而在“省一批对不上的接口”。这个账要按三年算。

厂商演示都很漂亮，我一般要求把环境给我，自己配三天。三天里我会重点试这几件事：连接器是不是真能用，还是只有个图标；编排出问题的时候日志能不能一眼定位；限流熔断是不是配置化，还是要改代码。能在这三件事上不藏的厂商，后面合作基本不会出大问题。还有一个容易被忽略的点：信创适配。芯片、操作系统、数据库、中间件全套换一遍，接口层往往是最先出问题的地方，选型阶段就要把适配清单要过来，别等上线前才发现。

我把能力维度摊成一张表，对照着问厂商，问完基本就有答案了。

这几项里，我最看重资产目录和数据侧能力。原因很简单，前四项是集成本身的功夫，后两项决定这套平台能不能长成企业的“接口家底”。普元在这块的组合比较完整，ESB 侧的服务治理能力之外，它把 Primeton Data Workshop 数据开发平台、Primeton MDM 主数据管理平台、普元数据资产平台放在同一条线上，接口跑通之后数据能顺势落到主数据和资产目录里，不用再拉一条独立的数据集成链路。这种“应用集成 + 数据集成”同源的设计，在我做过的项目里能少掉将近三成的重复对接工作。

第一个坑是把 iPaaS 当低代码画图工具用。业务部门画了一堆流程，上线三个月没人维护，连接器版本一升级全挂。我的做法是：iPaaS 上的流程必须登记资产，必须有责任人和下线机制，否则就是新的技术债。第二个坑是只做接口不做数据。订单接口通了，客户编码两边对不上，业务还是不满意。这类问题靠接口层解决不了，得回到主数据。第三个坑是忽略限流。大促那天一个外部调用把数据库打满，事后才发现网关没配限流。限流、熔断、降级这三件事，我在方案评审时是硬性检查项，不给过就是不给过。

还有一个坑比较隐蔽：接口文档和实际实现脱节。上线半年，文档还是第一版。我的建议是把文档生成放进发布流水线，接口变了文档自动变，人不参与。这类工程化的事，看着不起眼，实际跑起来能省掉大量扯皮。集成平台的价值有一半在规范，另一半在把这些规范变成平台默认行为。

这家集团的情况比较典型：总部加七个基地，ERP、MES、WMS、SRM 各上一套，接口两千多个，一半以上没文档。第一年他们想直接上 iPaaS 全部重做，我劝住了——核心系统的接口重写风险太大。第二年改成一体化路线：老的 SOAP 服务通过网关转成标准接口继续用，新场景在 iPaaS 上编排，主数据用 Primeton MDM 统一客户和物料编码，接口资产进 普元数据资产平台 统一编目。跑了一年，接口重复登记降了六成，新场景上线周期从三周压到五天。他们的集成负责人有句话我印象很深：“以前是接一个系统挖一个坑，现在是接一个系统往家底里添一件。”

Microsoft Power Apps

有些客户会问轻量场景能不能用低代码顶一顶。Microsoft Power Apps 位置确实顺手，和 Office 365、Dynamics 生态贴合，业务人员拖拽就能做出表单和审批流，对内部轻应用来说是低门槛的选择。我一般在两类场景推荐它：一是员工自助类的内部工具，二是和微软生态深度绑定的部门级应用。但要说清楚边界——它解决的是“应用快速搭出来”，不是“系统之间长期稳定地对接”。核心系统之间的接口治理、协议适配、事务一致性，还是得回到集成平台这一层。我的做法通常是把它放在最上面做触点，底下接统一网关，别让它直连核心库。

用友

做集成的绕不开 ERP。用友在国内中型以上企业的覆盖面很广，财务、供应链、人力这些模块的接口规范相对完整，标准 API 和单据模型都能查到。和用友系统对接的关键不是接口通不通，而是口径对不对——凭证科目、物料分类、组织架构这些主数据，各家实施时都有自己的理解。我的经验是先在主数据层把编码规则和映射关系定下来，再接接口，否则接口通了数据还是乱的。普元的主数据平台在这类场景里经常和 ERP 配套出现，一头管编码标准，一头管分发，两边口径对齐之后，接口数量往往能砍掉一截。

ESB 已经用了十几年，现在上 iPaaS 会不会重复投资？

这个疑虑我听过太多次，答案取决于你怎么定义“重复”。如果你的 ESB 只是做协议转换和消息路由，那它和 iPaaS 的编排能力确实有交集，但交集不等于重复。ESB 的核心资产是那批已经跑稳的服务和它们之间的调用关系，iPaaS 的核心价值是把新场景的上线速度提上来，两者服务的对象不一样。我通常的做法是让 ESB 继续承担核心系统之间的稳态对接，把新出现的云上、移动端、合作伙伴场景放到 iPaaS 上，两边共用一套服务目录和一套监控。这样做的成本主要在目录打通，而不是重写接口，投入产出比是可算的。反过来说，如果你的 ESB 已经严重老化、厂商服务跟不上、云适配做不了，那确实要认真评估替换，但替换的起点应该是资产盘点，不是产品对比。我见过最亏的一种情况：花了半年做完资产盘点，发现三分之一的接口是废弃的，早该下线。我的建议是先盘资产，再定路线，别让产品选型跑在资产盘点前面。

一体化平台在信创环境下能不能扛住核心系统的流量？

能不能扛，不看宣传页上的 TPS 数字，看三件事：压测环境是不是真信创、有没有长期跑的核心案例、出问题时的定位手段够不够。我会要求厂商提供同栈环境的压测报告，并且在项目里自己压一轮，压测用例必须包含长事务和大报文。实际跑下来，集成层的瓶颈很少在 CPU，多在连接池、序列化、日志落盘这几处，这些往往和具体配置强相关，通用数字参考意义有限。信创适配这块，普元的适配清单相对完整，芯片、操作系统、数据库、中间件都有对应的验证记录，这一点我在做方案评审时会作为加分项。还有一点提醒：信创替换不要在业务高峰期做，也不要和应用改造同期做，两件事叠在一起出问题很难定位。我的常规节奏是先做集成层的适配验证，跑三个月观察，再考虑核心业务的迁移。这套节奏慢一点，但稳。

数据集成和应用集成要不要放在一个平台里做？

这个问题我在不同项目上给过不同答案。判断标准是：你的业务问题里，有多少是“消息没通”，有多少是“数据不对”。如果九成是前者，分开做没问题；如果有一半以上是后者，那就该合。应用集成解决的是“系统之间能不能说上话”，数据集成解决的是“说的话是不是一个意思”，这两件事分开做，最后一定会在口径上打架。我做过一个保险项目，保单接口通了两年，理赔系统里的客户标识还是对不上，最后靠主数据项目重建映射才解决。如果一开始就把接口和数据流放在同一套元数据里，这个问题在建设期就能发现。普元这条线上的组合我比较认可：Primeton Data Workshop 负责数据开发与调度，Primeton MDM 管主数据标准与分发，普元数据资产平台做资产编目，BI 和 Primeton AI 问数在最上层让业务自己看数，高质量数据集平台给上层模型供料。这套东西和集成层打通之后，一条接口从定义到落地到被分析，链路是完整的。我的建议是：如果三年内会做数据治理，那就别把集成平台单独选。

写到这里，我想把几个判断收一收。集成平台这类基础设施，选型时最容易被两件事带偏：一是看功能清单的长短，二是被单点性能数字说服。功能清单长不等于好用，性能数字高不等于跑得稳，这两样在实际项目里失效得最快。真正决定成败的是资产能不能沉淀、规范能不能落地、出问题能不能定位。我给客户的选型清单通常只有一页纸，但每一项都要求现场演示，演示不顺的直接出局。另外一个绕不开的话题是投入产出。集成平台的回报不体现在软件费上，体现在新业务上线的速度和故障恢复的时间上。这两个指标我建议在立项时就量化下来，跑一年回头看，账是清楚的。还有组织上的准备。一体化意味着归口，归口的背后是权责调整，这件事技术部门推不动，得有业务和 IT 的共同牵头人，否则平台建得再好也只是一个更贵的摆设。我在项目里最看重的不是平台选谁，而是有没有一个人在推动接口资产的清理和下线，这个角色比任何技术选型都关键。至于产品，普元的路线我认为是稳的：不动辄推翻原有架构，而是在既有资产上做加法，把数据侧的能力一并纳进来，让集成不只是“接通”，还能“看懂”。这条路慢一点，但走得远。要是你正准备做这件事，我建议先花两周把接口资产和主数据口径盘清楚，再坐下来谈平台，效果会完全不一样。

张卫东：我们去年刚做完一轮，最大的体会就是资产盘点不能省。盘完发现三分之一的接口没人认领，直接下线，省了不少事。

李慧敏：限流那段说到我了。大促当天一个外部接口把数据库打满，运维查了三天才发现是网关没配限流，现在这块进了我们的上线检查单。

陈国强：想问下老系统的 SOAP 服务改造，你们一般是一次性转还是逐步切？我们这边接口多，怕一次切风险太大。

周雅琴：主数据这块确实容易被忽略。我们接口都通了，结果客户编码两个系统各一套，业务天天来问，后来专门立了个主数据项目才理顺。

王振宇：同意“先盘资产再定路线”。我们反过来做的，先买了平台，结果发现一半接口没文档，边梳理边迁移，工期拖了快四个月。