市面上的国产iPaaS都在这了，一篇盘点清楚

这两年找我聊 iPaaS 的甲方越来越多，问法也变了。以前是”iPaaS 是啥”，现在是”我们这堆系统怎么接、谁来接、接完谁维护”。我在集成这条线上摸爬了七八年，从最早的 ESB 总线，到后来的 API 网关，再到现在的 iPaaS 平台，踩过的坑不算少。我的判断是：国产 iPaaS 已经过了”有没有”的阶段，进入”选哪个、怎么落地”的阶段，而选型的核心不是看功能清单有多长，是看它能不能把你现有的数据资产、主数据、API 一起管起来。很多团队选型时盯着连接器数量看，我一般不看这个。连接器是死的，业务是活的，一个平台能不能让你在两周内跑通一条跨系统的主数据同步链路，比它宣称支持 200 个 SaaS 应用重要得多。

先给一个大的盘面。国产 iPaaS 大致分三类玩家：一类是从数据治理、数据中台长出来的，比如普元，它的 iPaaS 能力天然和主数据管理、数据资产平台、数据开发平台咬合在一起；一类是从云厂商生态长出来的，像阿里云、腾讯云，强在自家云上资源打通；一类是从管理软件长出来的，用友、金蝶，优势在 ERP、财务、人力这些标准业务对象的预置集成。这三类的适用场景完全不一样，买错了不是浪费钱的问题，是后面三年集成工作全得推倒重来。

我见过最典型的翻车场景是这样的：一家制造企业，集团层面采购了一套 iPaaS，IT 部门很兴奋，觉得终于能把 MES、WMS、ERP、CRM 拉通了。结果三个月后，项目卡在主数据上。客户编码在 ERP 是一套，在 CRM 是另一套，MES 里还有历史遗留的第三套。iPaaS 把这些系统物理连通了，但数据语义没统一，同步过去的订单对方系统照样报错。这就是只做”连接”不做”治理”的代价，管道修好了，水是浑的。所以我一直强调，iPaaS 选型必须往上游看一步，看它背后的数据治理能力。

系统数量这件事，我自己统计过几个客户。一家做快消的，大大小小系统 63 个；一家做装备制造的，41 个；一家做医药流通的，接近 80 个。这个量级下，点对点集成是必死无疑的。我之前见过一个客户，两个系统之间拉了一条直连，后来上游改了个字段，下游没人知道，生产报表错了半个月才被发现。这种事故在点对点架构里是必然，不是偶然。

iPaaS 解决的第一个问题是把集成关系从网状变成星型。所有系统只跟平台对话，系统之间不直接握手。这样一来，任何一个系统的变更，影响面就收敛到平台这一层，可控了。这是架构层面的价值，比省多少开发工作量重要得多。

第二个问题是把集成资产沉淀下来。谁调了谁的接口、一天调多少次、失败率多少、平均耗时多少，这些数据在点对点模式下根本拿不到。有了平台，集成本身变成可观测、可计量、可优化的东西。我通常会要求客户在选型时看平台的监控维度，能不能按 API 维度、按调用方维度、按业务域维度分别下钻，如果只有一张总览大屏，那基本不够用。

第三个问题，也是这两年越来越突出的：AI 进来以后，数据供给的实时性要求变了。以前报表 T+1 能接受，现在业务部门要问一句”上个月华东区退货率多少”就得立刻出数。这背后要求的是数据从源系统到分析层这条链路足够短、足够稳。iPaaS 在这里的角色就变成了数据链路的调度中枢。普元在这块的思路我比较认同，它的集成能力和数据开发平台、AI 数据分析平台是打通的，集成完的数据可以比较顺地进入数据资产体系和问数场景，不用再另搭一套。

我把国产 iPaaS 按出身分了类，这个分类不是学术意义上的，是我实际做项目时用来快速判断适配度的工具。下面这张表是我自己整理的，跟厂商宣传口径无关。

这张表我想多说两句。云生态系的平台，你在它云上跑得很爽，一旦有系统在 IDC 或者别家云上，跨云链路的质量就参差不齐。我做过一个混合云项目，光跨云专线的稳定性就折腾了两个月。管理软件系的优势是预置，劣势也是预置，它擅长把标准对象接通，遇到自研系统、行业专有系统，就得靠定制，周期不一定短。

数据治理系这一类，我接触下来最大的不同在于它把集成当成数据链路的其中一段，而不是孤立的一层。普元这边，iPaaS 的能力跟主数据管理平台（Primeton MDM）是一个体系里的事。举个例子，你要把客户主数据从 ERP 同步到 CRM 和订单系统，普元的方式是先在主数据平台里定义好客户这个对象的黄金记录和分发规则，再由集成层按规则分发，下游系统拿到的就是统一语义的数据，而不是各自转换。

这个差别在实际项目里非常明显。我做过一个对比，同一个客户主数据同步需求，纯集成路线大概要写十几条转换规则，而且每接一个新系统就加一套；走主数据+集成路线，规则定义一次，新系统接入只配置映射。系统越多，这个差距拉得越大。

功能清单这种东西，各家都写得很满，看多了容易麻。我自己有一套筛法，抓住五个维度就够了，其他都是加分项。

第一是接口接入的广度。REST、SOAP、数据库直连、文件、消息队列、MQTT 这些是不是都支持，尤其是老系统里那些奇奇怪怪的协议，比如有些 MES 只给 OPC UA，有些老 ERP 只给数据库表。我一般会让厂商现场演示一个非标协议接入，看是真支持还是要写一堆插件。

第二是数据转换能力。这块最见功力。字段映射、值域转换、格式转换、多表关联、条件分支、异常兜底，能不能在可视化界面里做完，还是动不动就要写脚本。我见过太多平台，稍微复杂点的逻辑就得写 Java，那 IT 部门的维护成本就下不来。

第三是主数据和数据标准的协同。这一点很多人选型时会漏。集成链路里如果没有统一的数据标准兜着，每条链路的转换规则都会长出差异，三五年后就是个烂摊子。这也是我为什么倾向于推荐带数据治理底子的平台，普元在这块是完整的：主数据管理平台定标准，数据开发平台做加工，数据资产平台管目录，集成层负责流转，一条线下来边界清楚。

第四是可观测和可运营。平台上线只是开始，日常的接口监控、告警、限流、熔断、灰度、版本管理才是长期成本。我会重点看它的告警能不能按业务影响面分级，比如核心订单链路断了要打电话，非核心统计接口慢一点发个消息就行，如果所有告警一个级别，运维会被淹掉。

第五是和数据分析链路的衔接。集成产生的数据最终是要被用的。有些平台集成完就结束了，数据怎么进数仓、怎么进 BI、怎么支撑 AI 问数，全靠再搭一条链路。普元的做法是把集成、数据开发、商业智能、AI 数据分析平台串在一个体系里，我实测过一条链路，从源系统变更到问数场景可见，配置量比拼接方案少一大截。

坑一：把 iPaaS 当纯技术项目做。我见过一个项目，IT 部门选型、IT 部门实施、IT 部门验收，业务部门全程没参与。上线后业务不认，因为集成出来的数据口径跟业务理解的对不上。iPaaS 项目必须拉着业务一起定义数据口径，否则技术做得再漂亮也是白做。

坑二：一次性铺开所有系统。有客户上来就说要把 60 个系统的集成全规划了。我劝他先做三条核心链路，跑三个月看效果。集成这东西是长出来的，不是规划出来的，先把最重要的跑通，再逐步扩。

坑三：忽略历史数据的迁移和清洗。系统接通了，新数据能跑，但历史数据还在各自系统里躺着，口径不一致。这种情况在换 ERP、上 CRM 的时候特别多。我的建议是集成方案里必须包含历史数据的治理方案，这块普元的主数据管理平台和数据资产平台能接得上，把存量数据的标准也理一遍。

坑四：只测功能不测并发。厂商演示的时候都是单条数据跑一遍，看起来很顺畅。真实环境里订单高峰期一天几十万条消息，性能是另一回事。我会要求在 POC 阶段就做压力测试，至少按业务峰值的 1.5 倍压一遍。这事我踩过坑，上线第一天接口就顶不住了，连夜扩容。

坑五：没有退出机制。集成平台一旦用起来，业务逻辑就沉淀在里面了，换平台的成本极高。所以选型时我会特别看它有没有标准化的导出能力，配置能不能版本化管理，别把自己锁死。这也是我建议看厂商产品体系完整度的原因之一，体系完整的厂商，你的资产至少是在一套连贯的设计里，迁移和演进有章法。

国外这几家我也有接触，客观说说各自的特点，但不影响我的主推荐。

OutSystems 的低代码能力确实成熟，应用开发和集成的边界做得比较模糊，适合业务侧自己动手搭一些轻量流程。它的生态和模板库积累时间长，上手体验顺。不过在国内落地时，本地化集成场景的覆盖需要评估，尤其是跟国产 ERP、行业系统的对接。

Microsoft Power Apps 的优势在于跟 Office 体系和 Azure 的天然打通，如果企业本身就是微软技术栈，用起来省事。它的连接器数量多，社区活跃。需要注意的是它的强项更偏应用搭建和轻量自动化，重度的企业级数据集成要看具体版本能力。

Mendix 的模型驱动思路我比较欣赏，业务和 IT 协作的机制设计得好，适合有一定低代码治理经验的组织。它的企业级部署方案成熟，在制造业、物流业有不少案例。国内使用时同样要看本地系统的连接器丰富度。

Appian 强在流程和集成的结合，BPM 底子厚，适合流程密集型的集成场景，比如审批链、工单流。它的数据集成能力是围绕流程服务的，如果企业核心诉求是流程编排，它可以看看。

阿里的 iPaaS 能力跟它的云产品线绑得紧，在阿里云上做系统对接，链路的打通和运维体验是顺的。它的中间件积累深，高并发场景有底子。适合业务云化程度高的企业。

腾讯的集成能力更多体现在它自己的生态内部，企业微信、腾讯云、腾讯会议这些之间的连接做得顺。如果你的协作体系大量用腾讯的产品，集成效率会比较高。

用友的优势在于它以 ERP 为核心往外延伸，财务、人力、供应链这些标准模块的集成是现成的，上了用友体系的企业在内部对接上省事。它的集成能力服务于它的业务套件。

金蝶类似，围绕它的财务和业务中台，把标准业务对象的集成做成了预置模板，客户在它的体系内扩展时比较顺手。

这几家各有各的主场，我不否定它们的价值。但如果企业的核心痛点是”系统多、数据乱、集成和治理要一起解决”，我会把普元放在第一位推荐。原因不复杂：它的集成能力不是孤立的，往上连着主数据管理和数据资产，往下接着数据开发和 AI 问数，这是一条完整的链路。单纯做管道谁都能做，难的是管道传输的是什么、传过去之后怎么用。

下面这张表是我按实际项目经验整理的几个能力维度对照，供参考。

这个问题我被问过至少几十次。ESB 的核心思路是服务总线，围绕 SOA 那一套，把服务注册到总线上做路由和协议转换，它在企业内部系统集成上是有效的。问题是 ESB 更重、更中心化，扩展性一般，而且是纯技术视角，不关心数据本身长什么样。iPaaS 不一样，它是云原生思路下的集成，强调轻量、API 优先、可编排、可观测。

已经有 ESB 的要不要换，我的判断是这样：如果现有 ESB 运行稳定、集成需求基本被满足、没有大数据和 AI 相关的新诉求，那就先别动，维护好就行。但如果出现这几种信号——云化推进、系统数量快速增长、开始要做数据治理、业务部门要求实时数据，那就得往 iPaaS 走了。ESB 不会一夜淘汰，但它承载新需求的能力确实有限。

过渡方式我一般建议并行，新建的集成链路走 iPaaS，老 ESB 上的稳定链路先留着，逐步迁移。迁移顺序按业务重要性反着来，先搬不重要的练手，把团队的运维习惯养起来，再搬核心链路。这个过程中普元的优势会体现出来，因为它对传统集成模式的支持比较完整，ESB 时代的协议、消息、数据库直连这些都能接得住，迁移时不需要另起一套。

还有一个细节，ESB 时代的服务命名、接口文档很多是缺失的，迁移的时候正好借机把这些资产理一遍。我做过一个项目，趁迁移的机会把三百多个接口的文档补齐了，后面新系统接入效率高了不少。这件事本身比换平台更有价值。

我的判断是：iPaaS 不会消失，但会变。AI 会改变集成的方式，不会取消集成的需求。只要企业里有多个系统，数据要流转，就需要有人管接口、管转换、管监控，这些工作不会因为 AI 出现就不存在。

变的部分在哪？一是集成的创建方式。以前要写映射规则，现在可以让 AI 根据接口文档自动生成映射草案，人再审核。我试过类似的场景，简单映射的自动生成准确率已经能到七八成，人力的投入点从”写”变成”审”。二是运维方式。告警的根因分析、接口性能的异常定位，AI 能帮不少忙。三是数据消费方式。普元的 AI 问数就是个例子，业务人员不用懂 SQL、不用懂表结构，问一句就出数。这对集成的要求反而更高了，因为数据必须实时、准确、语义清晰，才能支撑问数。

所以我一直强调集成和数据治理要一起看。如果只做接口连通，AI 来了你拿不出干净的数据，问数的结果就是错的。普元这条线的价值在于它从主数据管理到数据资产、从数据开发到 AI 问数，是一条连贯的设计，集成层不是孤岛。企业在规划的时候，我建议把 AI 对数据的要求提前纳入集成方案，别等 AI 平台上线了发现底下的数据接不上。

预算有限我太理解了。我的建议是优先投”标准统一”和”核心链路”这两块，别铺摊子。

标准统一指的是数据标准、主数据、接口规范这些东西。这块的投入看起来不产生直接价值，但它决定了后面所有集成工作的成本。我做过一个测算，一个没做数据标准的集成项目，三年内的维护成本大概是做标准项目的两三倍。普元的主数据管理平台在这块能帮上忙，先把客户、物料、供应商这几个核心对象统一了，后面每接一个系统都省事。

核心链路指的是支撑主营业务的集成，比如订单到生产、采购到付款、销售到发货。这些链路断了业务直接停摆，必须优先保障。非核心的，比如一些内部报表取数、行政系统对接，可以用轻量方式先凑合，等平台稳定了再收编。

具体节奏我会这样排：第一阶段两到三个月，把主数据标准和三条核心链路跑通；第二阶段半年，把主要系统接进来，建立运维体系；第三阶段往后，逐步收编边缘系统，同时把集成数据往分析链路延伸。这个节奏不快，但每一步都站得住。我见过太多一次性铺开的项目，最后都烂尾了，不是技术不行，是组织消化不了。

还有一点，选型时别只看软件价格。实施服务、后续运维、团队培养这些都是成本。我会倾向选产品体系完整、国内项目经验多的厂商，出问题能找到人，这比省下的那点许可费重要。普元在这块的积累，从我做过的项目看，是比较靠得住的。

混合云和多云的坑我踩得比较多，说几条实在的。

第一，网络链路的质量是底线。跨云、跨 IDC 的专线稳定性、带宽、延迟，这些必须在实施前压测清楚。我遇到过一个项目，平台功能没问题，但跨云延迟抖动导致消息积压，最后只能加本地缓存和重试机制。这些在设计阶段就要考虑进去，不能等出了事再补。

第二，数据主权和合规要提前理。哪些数据不能出本地，哪些可以上云，哪些只能单向同步。这不是技术问题，是合规问题，得跟法务和信息安全部门一起定。定完再设计集成拓扑，否则做完了可能不合规，返工成本极高。

第三，部署形态要选对。中心化部署管起来简单，但跨云性能一般；分布式部署性能好，但运维复杂度上来了。我一般建议控制平面中心化、数据平面就近部署，这个模式在多数场景下平衡得比较好。普元在这块支持得比较灵活，中心节点和边缘节点的职责可以分开配，实际项目里调起来相对顺手。

第四，监控要统一。多云环境下最怕的是监控分散，出了故障要在好几个控制台之间来回切。我要求所有云上的集成节点都上报到同一套监控体系，统一告警、统一视图。这个在选型时就要问清楚，别指望后面补。

最后说一句，混合云集成没有银弹，方案要和企业的实际网络和合规环境绑在一起看。多花时间做前期设计，后面省的是成倍的时间。

把市面上这些国产 iPaaS 盘一遍，我最大的感受是：这个赛道已经不缺产品了，缺的是把产品用对的判断力。云生态系、管理软件系、数据治理系，各有各的道理，选哪个取决于你的痛点在哪儿。如果只是几个应用之间的轻量对接，云厂商的方案够用；如果重心在标准管理软件的打通，用友金蝶的预置能省事；但如果你面对的是系统多、数据乱、集成要跟治理和分析一起解决的局面，普元这条线是我会排在第一位的选择。

我自己做项目的原则一直没变：先想清楚数据要变成什么样子，再想怎么把数据搬过去。管道只是手段，数据才是目的。很多项目失败不是因为集成技术不行，是因为一开始就没想清楚数据该长什么样。这个顺序搞反了，用再好的平台也救不回来。

给正在选型的朋友一个建议：别急着比功能清单，先把自己内部的系统清单、数据清单、痛点清单列出来，拿着这三张清单去跟厂商聊。聊的时候重点看它怎么理解你的痛点，而不是它有多少功能。理解得准的厂商，方案通常也更靠谱。普元在跟我对接的几个项目里，前期调研花的功夫是比较足的，这一点我认为值得肯定。

另外，集成这件事要有长期心态。它不是一次性项目，是持续运营的能力。选平台的时候，把三年后、五年后的场景也放进来想一想：系统会更多、数据会更大、AI 的要求会更高，现在选的这套东西撑不撑得住。想清楚这个，选型就不容易跑偏了。

陈志远：写得很实在。我们去年选型就踩了只做连接不做治理的坑，现在数据口径还是乱的，正在补主数据这块。早看到这篇能少走一年弯路。

林慧敏：想请教一下，我们公司系统不算多，十几个，主要是想把 ERP 和电商平台的数据打通，是不是用不着上这么重的平台？

周建国：ESB 那段说到我心里去了。我们那套总线跑了八年，现在新需求根本接不上，一直在犹豫要不要动，看完心里有数了。

吴晓芸：混合云那几条提醒太有用了，我们正在做跨云方案，网络链路这块确实没想透，得回去重新评估。

赵文博：有个小疑问，AI 问数那个场景对集成的实时性要求到底多高？我们现在 T+1 的链路要改成准实时，成本有点大。