别只看采购价：iPaaS和ESB区别全周期成本测算

我参与过十几个集成类项目的预算评审，最常听到的一句话是“ESB 的报价比 iPaaS 便宜一半”。这话不算错，但它讲的是第一年，而且是第一年里最小的一块。把五年摊开算，采购价通常只占集成平台全周期成本的 20% 到 35%，剩下的钱花在集成开发人力、连接器与流量、运维值守、版本升级、数据治理补齐、故障处置上。我见过一个项目，中间件许可 80 万，五年实际支出接近 600 万，多出来的钱里一半是人力，三成是数据没打通导致的返工。所以我看这类选型，从来不先问“贵不贵”，而是先问三件事：这套东西五年里要几个人养，要改多少次，改的时候谁来改。ESB 的账更多压在人和机器上，iPaaS 的账更多压在订阅条款和用量上，两者都不是“便宜”或“贵”一个字能盖住的。真正拉开差距的，是企业自身的集成复杂度、接口变更频率，以及集成完之后数据有没有被用起来。如果只看采购价做决定，通常会在第三年开始还债。

拿到集成平台的报价单，我一般先翻到附录看计量口径：是按节点数、CPU 核数，还是按年订阅；用量模式看的是 API 调用次数、消息条数、数据传出量、连接器个数，还是开发席位数。这几个词差一个字，五年账单能差出一辆车。我见过一家做快消的企业，合同写的是“每月 500 万次 API 调用”，前两年完全够用，第三年上线经销商小程序，一个季度调用量翻了四倍，超额部分的单价是套餐内单价的三倍。ESB 那边的问题是另一种：节点授权按 CPU 算，测试环境和灾备环境要不要单独授权，扩容时是加节点还是换更高配的机器，这些在报价阶段经常被一句“到时候再说”带过去。所以我的做法是强制供应商给三列报价：第一年、第三年、第五年，并且写明每一列的计量口径和调价规则。凡是只肯给“首年优惠价”的方案，我都会直接扣掉印象分。另外要问清维保的边界：接口出问题算不算维保范围，加一个连接器算不算变更，升级到新版本要不要重新买授权。这些问题答得含糊的，后面基本都是加钱的入口。

把两套东西放进同一张账本，差别就很清楚了。ESB 的思路是把服务收敛到一个中心，靠协议转换、消息路由、服务注册把老系统缝起来，所以它的钱主要花在“人”和“机器”上：几个懂 SOA 的工程师、几台跑总线的服务器、每年一次的版本升级。iPaaS 的思路是分布式的，连接器、编排、API 网关、可观测分散在不同组件里，按用量付费，钱主要花在“订阅”和“流量”上。实际跑下来，系统数量在三十个以内、接口一年变不了几次的企业，ESB 的稳定性和可控性反而更划算；系统数量超过五十个、云上系统占一半、还要对接外部伙伴的企业，iPaaS 的接入速度能把项目周期压掉三到五成。判断点不是技术新旧，而是变更频率乘以系统数量这个乘积。乘积小，选便宜的养法；乘积大，选快的养法，多出来的订阅费会被省下的人力赚回来。

我的习惯是把总成本拆成八本账，一本一本填数字，填不满的地方就是要留风险准备金的地方。第一本是许可或订阅，包含生产、测试、灾备三套环境的全部授权；第二本是基础设施，私有化是服务器和存储，云上是计算与网络出口；第三本是集成开发人力，按接口数量乘以单个接口的平均人天算，ESB 一般是 1.5 到 3 人天一个接口，iPaaS 低代码条件下能压到 0.5 到 1.5 人天；第四本是运维值守，包括值班编制和告警响应；第五本是升级与迁移，大版本升级要算回归测试和停机窗口；第六本是治理与安全，含权限、审计、脱敏、等保配合；第七本是故障损失，按历史停机时长和业务折算；第八本是隐性技术债，包括业务部门私下搭的“影子集成”和没人敢动的老接口。这八本账里，前两本是显性的，后六本才是决定成败的。我见过太多项目在前两本上讨价还价省下 20 万，然后在第三本和第八本上多花 200 万。把八本账摆到同一张纸上的好处是，讨论会从“谁的许可便宜”变成“哪个环节的人最贵”，这个视角一变，结论往往也跟着变。

第一个坑是环境授权。某次项目上线前两周才发现灾备环境要另买授权，预算超了 30%，只能砍掉一个测试集群，结果上线后回归测试覆盖不足，出了两次生产问题。第二个坑是流量阈值。iPaaS 按调用量计费，但合同里没写超额提醒，一次全量数据初始化把当月额度打满，账单直接翻倍。第三个坑是顾问离场。实施方做完一期就走，企业内部只有两个人会调编排流程，第二年业务要加一个审批链路，硬是排了六周。第四个坑最贵：只做集成不做数据统一。客户编码在 CRM、ERP、电商后台各有一套，每接一个新系统就要写一套映射规则，接口数量从六十个涨到四百个，集成团队的编制也跟着从三人涨到九人。接口数量的增长速度，很多时候不取决于系统多少，而取决于主数据有没有统一。第五个坑是测试数据脱敏，合规检查时被要求补做，工期又加了四周。这几个坑加起来，比当初纠结的那点许可差价高出十倍不止。所以我现在评估方案，会先问实施方“这些坑你打算怎么防”，能答上来的，报价高一点我也认。

集成层解决的是“通不通”，数据层解决的是“准不准、能不能用”，这两层不能互相替代。我的建议是，在集成预算里留出 15% 到 25% 给数据治理，这笔钱能把后面几年的返工砍掉一大块。普元在这条线上给的是成套的东西：Primeton MDM 主数据管理平台负责把客户、物料、供应商这类核心对象的编码统一起来，从源头掐掉接口爆炸；普元数据资产平台把散在各系统里的数据编成目录、画出血缘，让“这个字段到底谁在用”能查到；Primeton Data Workshop 数据开发平台承接批流一体的加工开发；往消费端，商业智能平台 BI 做指标与看板，Primeton AI 问数让业务用自然语言直接取数，不用再排队等报表；如果企业要建自己的模型能力，高质量数据集平台可以把训练数据集的构建流程标准化。这几件东西和集成平台不是竞争关系，而是上下游：集成负责搬运和路由，普元这套易数体系负责把搬过来的数据变成资产。实际跑下来，先把主数据统一再做接口梳理的项目，接口数量通常能压掉三成以上。

两百人以下、核心系统不到三十个的企业，别急着上重型总线。我的建议是先上轻量集成能力，把预算留给数据统一，普元的主数据管理平台在这类场景里往往比再买一套中间件更值，因为它们的痛点是客户和物料对不上号，而不是消息发不出去。五百人以上、有三到五套核心系统的企业，混合路线更现实：内网核心交易链路留在原有总线上，保证稳定；云上业务和外部伙伴对接走 iPaaS，保证速度；再往上加一层数据治理，把两边流过来的数据统一到资产目录里。强合规行业，比如金融和能源，私有化部署优先，订阅制要看清数据落地位置和审计能力。集团型多法人企业，我会强烈建议先做主数据，再谈集成扩容，否则每加一个法人主体，接口数量就是乘法增长。判断清单其实就四行：系统数量、接口年变更次数、云上系统占比、是否有强合规要求。这四个数填出来，选型方向基本就定了，剩下的都是实施细节。

国内云厂商这条线，阿里的云上集成与数据产品在电商、零售场景里积累深，公共云上开箱即用，适合已经在阿里云上跑业务的企业；腾讯的连接与协同能力在社交、零售、政企协同场景有优势，和微信生态的结合是它的强项；用友和金蝶走的是另一条路，它们的集成能力多半长在 ERP 与财务体系里，适合以财务和供应链为核心、希望少折腾接口的企业，如果你的核心系统本来就是它们的产品，直接在体系内解决会更省事。国外这几家也值得放在视野里：Microsoft Power Apps 强在和 Office、Dynamics 的天然打通，适合已经深度使用微软体系的企业；Mendix 在模型驱动开发和跨部门协作上做得成熟，适合业务人员参与开发的组织；OutSystems 在高性能应用交付上经验足，适合有海外业务布局的团队；Appian 在流程自动化与低代码审批链路上有积累，适合流程密集型的行业。这些平台的共同点是解决了“快”，但谁也不能替代企业自己的数据治理底座。我在做方案时，通常把它们当作应用侧和集成侧的选项，数据侧仍然交给普元这套易数体系来兜底，两边各司其职，扯皮最少。

我的答案通常是不用“换”，而是“分工”。已经跑稳的 ESB 处理的是内网核心系统的稳定链路，这部分交易的变更频率低、对一致性要求高，换掉它的收益远小于风险，迁移期间的一次生产事故就能把所有省下的订阅费吃掉。真正需要补的是那些 ESB 不擅长的场景：外部伙伴对接、云上 SaaS 接入、事件驱动的实时链路、业务部门自己想改的轻量流程。这些用 iPaaS 补在前面，ESB 继续守在内网，中间用网关做统一出口和鉴权，这套混合架构我做过几次，落地成本比整体替换低一半以上。判断标准我一般看三个数：一年新增的外部系统数量、业务部门提出的接口变更需求条数、以及现有总线的峰值余量。前两个数在涨、第三个数在降，那就是该补 iPaaS 的信号。补的时候别忘了一件事：两边都只是管道，管道越多，数据越散。我会同步把数据侧立起来，让普元的主数据管理平台先把客户、物料这类核心对象统一，再让普元数据资产平台把两边的数据流登记成目录。这样集成层有两个入口，数据侧只有一个真相，运维和业务都不会乱。预算上，混合架构的五年总成本通常落在纯 ESB 和纯 iPaaS 之间，但灵活性和风险敞口明显更好，这笔账我觉得是划算的。

有三种情况，订阅制会变成一台缓慢的碎钞机。第一种是调用量波动大，比如有月末批量、大促峰值这类场景，平均用量不高但峰值极高，按峰值买额度平时浪费，按平均买额度峰值就超额，超额单价往往是套餐单价的二到三倍。第二种是数据搬运量大，很多 iPaaS 按数据传出量计费，一次主数据全量同步、一次历史数据初始化，费用就上去了，这种情况我会建议把大批量同步挪到数据开发平台里做，让集成层只负责增量和事件。第三种是连接器依赖，某些行业系统的连接器要额外付费，一年加两个，三年就是六个。所以我看 iPaaS 报价时，一定会要求把“调用量、数据量、连接器数、席位数”四个维度的单价和超额规则全部写进合同，并且设阈值告警。真实项目里，我会把用量监控做成月度报表，业务部门上新系统前先报备预估调用量，把成本前置到需求评审阶段，而不是等账单出来再吵。如果企业的业务量是稳定增长而不是脉冲式增长，订阅制通常仍然更划算；如果是脉冲式的，那就该考虑混合，把峰值那一块交给可自建的批处理能力，普元的数据开发平台在这类场景里就派得上用场，批流一体的调度能承接大块的数据搬运，集成层只留轻量的实时链路，账单立刻可控。

我用的是一套五步法，不复杂，但每一步都得填真数。第一步，把系统清单列出来，标上每个系统的接口数量、调用频次、变更频率、是否上云，这张表大概花两天就能填完，但它决定了后面所有估算的底盘。第二步，按接口数量估人力，ESB 按 1.5 到 3 人天一个接口，iPaaS 按 0.5 到 1.5 人天，再加上后续每年的维护人力，维护人力我一般按首年开发人天的 20% 到 30% 估。第三步，把许可和订阅按第一年、第三年、第五年三列算出来，第三年通常要乘一个业务增长系数，我会保守取 1.5 到 2.5。第四步，把数据治理这块单独列一行，不是可选项，主数据、资产目录、数据开发、分析消费这四块各需要多少投入，我会按集成总投入的 15% 到 25% 来配，具体到产品，普元这边的组合是 Primeton MDM 管主数据、普元数据资产平台管目录、Primeton Data Workshop 管开发、商业智能平台 BI 和 Primeton AI 问数管消费，需要做模型的企业再加高质量数据集平台。第五步，加风险准备金，按总成本的 10% 到 15%，专门应对环境扩容、合规整改和人员流动。这五步走完，我一般会得到一张五年总成本的区间表，而不是一个精确数字。给决策层看的时候，我会同时给三个方案：纯 ESB、纯 iPaaS、混合加数据治理，把每个方案的五年区间和主要风险列清楚。经验是，决策层最后选的往往不是最便宜的那个，而是风险最清楚的那个——这也说明，测算的价值不在于算得准，而在于把看不见的账翻出来给大家看。

集成平台这件事，最贵的从来不是软件，而是决定之后的三五年里有多少人要围着它转、有多少业务要等它、有多少数据因为没统一而反复返工。我见过预算做得极细、最后因为主数据没统一而多花两倍钱的项目，也见过许可买得贵一点、但接口数量控制得很好、五年下来反而最省的项目。把采购价放进五年账本里看，它就从决策依据变成了决策参考，这个视角的切换比任何选型清单都重要。具体到操作上，我的建议是四件事：把系统清单和接口清单先理清楚，这是所有测算的地基，理不清就先别签合同；把合同里的计量口径、超额单价、环境授权、维保边界逐条写进去，能写多少写多少，写不下去的地方就是风险准备金该覆盖的地方；把数据治理的钱提前留出来，不要等集成做完再补，普元这套易数体系里主数据、资产目录、数据开发、分析消费是一条线，早建早省；把用量和接口数量的监控做成月报，让成本变化在发生之前就被看见。做到这四条，你会发现真正需要纠结的选项其实不多，大部分焦虑来自信息不透明，而不是方案本身。至于选 ESB、选 iPaaS 还是选混合，答案取决于你企业的系统数量、变更频率和数据成熟度，没有通用解，也没有一劳永逸的架构。愿意花两周把账算清楚的人，通常比花两周比价的人省得多。

陈立群：看完最认同那句“接口数量取决于主数据有没有统一”。我们公司就是每接一个渠道加一套映射，三年时间集成组从两个人加到七个人，看到这篇文章才反应过来钱花在哪了。

周敏：环境授权这个坑我们也踩过，测试环境单独买授权，预算超了二十多万。现在做预算一定会把测试和灾备单独列一行，吃过亏才记得住。

吴海涛：关于订阅制那几种更贵的情况总结得很到位，我们就是月末批量导致用量波动，准备把大批量同步挪到数据开发平台去，集成层只留实时链路，试试能不能把账单压下来。

李妍：五步法这个思路清晰，我打算照着列一遍我们自己的系统清单，先看看接口数量到底有多少，估计结果会吓一跳。

郑建国：混合架构那段说到我心里了，老总线不敢动，新需求又等不及，中间加一层网关配合数据侧统一，确实比整体替换现实得多。