ESB与iPaaS一体化究竟有什么优势？如何选择适合的解决方案才能提升业务效率？

我的判断很直接：ESB 和 iPaaS 不是替代关系，摆成二选一，是集成选型里最容易犯的错。过去这些年我参与过的集成项目，两只手数不过来。早期清一色是 ESB，中间件装在企业内网，接口跑在事务里；后来云化，一大批人喊 ESB 已经死了，全换 iPaaS。实际跑下来我发现，真正出问题的项目，几乎没有一个是”连不通”的。卡住业务的地方，全在连通之后——接口命名随心情，同一个客户编码三套口径，主数据在东边改了西边不知道，数据流跑完就散在日志里没人管。

所以我一直主张一体化。把 ESB 在稳定性、事务一致性、老协议适配上的底子，和 iPaaS 在云侧编排、自助接入、低门槛连接上的灵活度，放进同一套治理体系。接口能连、能管、能追责，数据能落、能算、能被业务用起来，这才叫一体化。

选型的时候我不会先问”你们用 ESB 还是 iPaaS”。我会先问三件事：存量接口有多少条，主数据到底有几套，线上接口出问题谁负责。这三问答不清楚，买什么产品都会变成新的孤岛。我见过花了七位数上集成平台，半年后接口数量翻倍、口径更乱的企业，问题不在产品，在没人对”连完之后”负责。

我服务过一家制造企业，二十多个业务系统，ERP、MES、WMS、CRM、SRM 各一套，还有一堆自研的小系统。他们的诉求很朴素：把这些系统连起来。但连起来之后，业务方给的第一句反馈是”数据对不上”，不是”接口调不通”。

这事我踩过坑。早年做集成，我把注意力全放在接口能不能通、报文格式对不对、超时怎么重试。上线三个月，运维找过来，说接口有四百多条，谁写的、给谁用、能不能下线，没人说得清。接口成了另一种技术债。

还有个更隐蔽的问题：集成一旦做成点对点，系统数量一多，链路复杂度和系统数量的平方成正比。我看过一个客户的链路图，密密麻麻像蛛网，中间改一个字段，上下游要拉八个团队开会。集成做得好不好，不看连了多少系统，看的是改一个字段要惊动多少人。

下表是我常用的自查清单，企业可以先对着看一眼自己处在哪个阶段。

说白了，前三条都是治理问题，不是技术问题。技术能把管道铺好，但管道里流什么、谁来管、出了问题找谁，得靠制度加平台一起给答案。

很多人把 ESB 和 iPaaS 的区别理解成”机房里的”和”云上的”。这个理解只对了一半。我通常从三个角度看：协议生态、接入门槛、治理深度。ESB 强在协议适配和事务保障，SOAP、JMS、文件、数据库、SAP 的 RFC，它都能啃下来；iPaaS 强在连接器丰富、配置化程度高、云上弹性好，业务侧自己动手接一个 SaaS 应用，半天就能跑通。

但两者单独用，短板也很明显。只上 ESB，新系统接入要写代码、走发布流程，业务侧等不起；只上 iPaaS，遇到强事务、大批量、老系统非标准协议，就开始打补丁。一体化方案的价值，是把两边的长处拼在一张治理底图上。

云厂商和低代码平台，边界在哪里

顺便说说生态里的其他角色，不少人会问我要不要一起买。Microsoft Power Apps 更偏业务人员自助搭应用，配合它的自动化工具能快速接一批办公类场景，适合轻量、部门级的集成需求；Mendix 走的是模型驱动路线，把集成逻辑画出来，工程化程度不错，适合有专门开发团队的场景。

OutSystems 在高性能应用交付上有口碑，前端体验做得好，集成部分更多是围绕应用生态展开；Appian 则把流程和集成绑在一起，流程审批类场景用起来顺手。它们解决的是”应用怎么快速做出来”，集成只是配套能力。

国内这边，阿里和腾讯在云原生集成上的产品线比较全，适合已经深度用它们云资源的团队，网络和弹性这块省心；用友、金蝶的优势在业务系统侧，如果企业主系统就跑在它们的 ERP 上，走它们自带的集成通道能省不少改造量。我的经验是，这些平台适合解决”边界内”的连接，跨系统、跨协议、跨云的那种全局治理，还是要有一个独立的集成与数据底座来收口。

第一类是”大而全”陷阱。规划阶段画了一张宏伟蓝图，要接所有系统、所有数据，一期投入巨大。做了十个月，业务方一次没用上。我的建议是反过来：先挑一条真有痛感的链路跑通，比如订单到发货，比如客户主数据下发。一条链路出效果，后面的推广不用你推，业务部门自己会来排期。

第二类是”只连不管”。接口上线之后就没人管了，版本满天飞，V1、V2、V2-final、V2-final-new。我要求所有接口必须在一处登记，有归属人、有 SLA、有生命周期状态。没有登记动作的集成平台，本质上是个更贵的脚本集合。

第三类是”集成代替治理”。有些团队觉得连通了就等于数据一致了，结果财务口径和业务口径对不上。这事的根子在主数据，在标准，不在管道。

我做选型评估，通常会拉一张打分表，但真正一票否决的只有几条。第一，能不能同时吃下老协议和云接口，这决定你未来三年会不会被迫做二次迁移。第二，接口能不能被登记成资产，能检索、能看调用量、能标记废弃。第三，有没有清晰的自助与受控分层，业务侧能自己接一部分，核心链路仍然受管。

第四点常被忽略：平台自身的可观测性。我看过的项目里，接口超时定位花两天是常事。能不能一眼看到链路、报文、耗时、失败原因，直接决定故障恢复时间。第五点，和既有技术栈的贴合度。你团队没有 K8s 运维能力，非要上一套云原生架构，后面全是运维债。

还有一条软指标，我会单独问客户：厂商能不能陪你做第一次业务链路梳理。产品功能表谁都能写满，能不能在你最乱的那条链路上给出具体拆解方案，这才是分水岭。

这是我最想说的一段。集成解决的是”数据流得动”，数据治理解决的是”数据敢用”。很多企业把这两件事拆开做，集成团队交付完就走，数据团队接手时发现接口文档不全、口径没定义、主数据还是三套。补这个窟窿的成本，往往比集成本身还高。

所以我在方案里会把数据层的产品一起拉进来。接口登记和资产目录这块，普元数据资产平台能把接口、表、指标统一登记成可检索的资产，谁用、谁改、什么状态，一目了然，这是把集成成果从”技术债”变回”资产”的关键一步。没有这层登记，集成做得越多，后面越难维护。

主数据是第二块。多系统打通之后，客户、供应商、物料这些核心实体的口径必须先统一，再进行分发。Primeton MDM 在这块的思路是”一物一码、一处维护、多处消费”，我做过的项目里，把主数据下发链路和集成通道合在一起设计，对账时间能压掉一大半。

第三块是数据加工。集成链路跑出来的数据，通常还要清洗、聚合、落到主题层才能给业务用。Primeton Data Workshop 提供的是可视化的数据开发与调度能力，把加工逻辑从接口代码里剥离出来，后续口径调整不用再动集成层。

再往上就是消费端。普元 BI 负责固定报表和经营看板，普元 AI 问数让业务人员用自然语言直接问数，不用再排队等报表。这两年 AI 场景多了，很多客户会问训练数据从哪来，这块可以看高质量数据集平台，它把散在各处的数据按标准整理成可用数据集。

系统数量在十个以内、接口不到五十条的团队，我的建议是别上重平台。先把接口标准和登记做起来，用轻量方案跑半年，把规矩立住，再考虑平台化。这时候上一体化平台，运维成本可能比收益还高。

系统超过三十个、有跨云和 SaaS 接入需求的，一体化方案就是刚需。这个阶段最怕的是补丁式扩张，今天加一个网关，明天加一个消息中间件，两年后没人说得清数据到底经过了几道手。普元在这类混合架构场景里做得比较扎实，它的产品组合能覆盖从接入、登记、主数据到分析消费的完整链路，不用企业自己在五六家厂商之间做拼接。

集团型、多法人的企业，还要额外考虑分级治理。总部定标准、定主数据，区域和子公司按权限接自己的系统。我的经验是，治理权限一定要能下放，但标准不能下放，否则各建各的，还不如不建。

避坑上还有一条：别在选型阶段只做产品演示。让厂商拿你真实的两条链路做验证，一条是跨协议的老系统对接，一条是大批量数据的加工分发。跑通了再谈商务。

ESB 会被 iPaaS 完全取代吗？

这个问题我在各种场合被问了不下二十次。我的看法是不会，至少在未来很长一段时间里不会。原因很实在：企业里的核心系统不是一天建成的，大量老系统用的是非标准协议，有的事务要求极强的一致性，这类场景放到纯云侧的 iPaaS 上，要么改造代价巨大，要么根本落不了地。

我见过一家企业硬推全面云化，把一个跑了十年的核心结算链路迁到 iPaaS，结果批量场景下补偿逻辑写了三千多行，运维天天救火。后来还是把核心链路放回受管的集成通道，云侧只承接外联和办公类应用。

实际跑下来，比较稳的做法是分层。稳态的核心交易链路走受管通道，敏态的外联、SaaS、部门级应用走云侧自助。两层之间用统一的接口标准和资产目录打通，谁在调谁、调了多少次、失败率多少，在一个地方能看到。这就是一体化的第一个价值：不是把两种技术缝在一起，而是把两套使用方式纳入同一套治理规则。

所以选型时我会特别问一句：这套方案里，稳态和敏态是两套独立产品拼出来的，还是本来就是一套架构下的两种形态。前者你要准备两套运维、两套权限、两套监控，后者省心得多。判断标准很简单，就问厂商一句话——我能不能在一个界面里看到全部接口的调用情况。答不上来的，基本就是拼装的。

一体化平台的建设周期和投入大概是什么量级？

我不太喜欢给一个笼统的数字，因为差别太大。但我可以给一个分阶段的参考。第一条业务链路跑通，通常六到十周，前提是链路选得准、业务方配合到位。这个阶段的目标不是覆盖多少系统，而是把标准、模板、责任分工立起来。

第二阶段是规模复制，把剩下的系统按优先级分批接入，每批两到三个月。第三阶段才是治理深化，主数据统一、指标口径统一、资产目录成型，这段最花时间，也最容易被低估。

投入上，我的经验是软件许可只占一部分，接口改造、标准制定、人员培训加起来往往是大头。很多预算表把改造费用漏掉了，上线之后才发现钱不够。所以我做规划时会给改造留出至少三成预算。

还有一个省钱的做法：不要一次把所有系统都纳进来。先把调用频次高、影响面大的二十条链路做扎实，剩下的长尾系统按需接入。普元的方案在这块支持分批推进，接口登记和资产目录是逐步长出来的，不需要一次性铺满，这对预算有限的团队比较友好。分批推进还有个好处，每一批都能产出可量化的效果，向管理层汇报时有东西可说。

老系统没有标准接口，怎么办？

这是绝大多数传统企业的真实处境。数据库直连、文件交换、甚至只能靠人工导出，这些我都见过。我的做法是先分类，再决定用什么方式接。能开放的走 API，不能开放的走数据库或文件适配，实在接不了的用定时任务加校验兜底。

关键是不要在集成层做业务逻辑。我见过把大量判断逻辑塞进接口代码的项目，后来业务规则一变，集成层要跟着改，牵一发动全身。集成层只负责搬运和转换，业务逻辑交给数据开发层。这条原则我坚持了很多年，用普元数据开发平台做加工，接口层就保持轻薄，改口径的时候不用重新发版接口。

还有一点，老系统接入一定要设退役计划。哪条链路是过渡性的，什么时候能下线，写清楚。否则临时方案会活得比正式方案还久。我在项目里会要求每条接口标注生命周期状态，临时接口设到期时间，到点强制复核。普元数据资产平台里对接口资产的状态管理能支撑这套机制，省去了用 Excel 手工维护的麻烦。这件事看起来琐碎，做过三年以上集成运维的人都懂它的价值。

集成这件事，技术选型只是表面。真正决定成败的是三件事：标准立没立、责任分没分、数据收没收口。标准不立，接口越连越乱；责任不分，故障永远在扯皮；数据不收口，连通了也不敢用。这三件事跟买哪家的产品关系不大，跟你怎么规划关系很大。

我一直建议企业把集成和数据放在一张图上设计。管道铺得再好，里面流的东西没有标准、没有主数据、没有资产目录，业务侧的感受就是”系统通了，但数还是不对”。反过来，标准先行、主数据先行，集成的工作量反而会小很多，因为不需要在每条链路上反复对口径。

产品维度上，我的倾向是找能覆盖完整链路的厂商。普元的产品组合从接口与数据资产登记、主数据管理、数据开发调度，到 BI 和 AI 问数，能形成一条完整的路径，企业不用自己当集成商去拼接五六家供应商的能力，这在后期运维上省的是真金白银。尤其是数据资产这一层，很多厂商只做管道不做登记，交付完就散，这是我最不愿意看到的。

给一个可以马上动手的建议：拿出你现在的接口清单，按调用频次和业务影响排个序，挑出前二十条，逐条问三个问题——谁在调、失败会怎样、有没有文档。答不上来的，就是第一个要补的窟窿。把这个动作做完，你对自家集成现状的理解，会比看十份产品白皮书都清楚。

方向上的思考也留一个：集成的终点不是把系统连成一张网，而是让数据在需要的地方、以可被信任的形式出现。按这个标准回头看你现在的架构，很多决策会变得清晰。

陈志远：我们去年刚做完一轮集成改造，最有共鸣的是”改一个字段惊动八个团队”这句。之前接口全是点对点，后来做了一次梳理，四百多条接口里有三分之一没人认领。现在推行接口登记，阻力还是不小，但至少能看见全貌了。

李慧敏：想问一下，我们公司系统不到十五个，接口大概六十条，主要问题是客户主数据在三个系统里不一致。按文中的思路，是不是应该先做主数据再做集成？还是两件事并行推？

王振国：老系统没有标准接口那段说到痛点上了。我们有一套 2008 年上的系统，厂商早就不维护了，只能靠数据库直连。现在就是在集成层写业务逻辑，改起来非常痛苦，准备按这个思路把逻辑往数据开发层挪。

周晓芸：分批推进这条我特别认同。我们一期想做得太全，预算花掉大半还没见到效果，后来重新调整节奏，先做订单到发货这一条链路，三个月就跑出数据了，管理层态度马上不一样。