一个真实的选型困境
前段时间跟一个制造业的 IT 负责人聊，他们现在的情况很典型：ERP 是本地部署的用友 U8+，OA 是泛微，HR 上了云端的人事系统，销售团队在用一套 SaaS CRM，工厂那边还有一套 MES。五套系统，各自独立运行。
他们想把这些系统打通------采购订单进 ERP 后自动同步到 OA 审批，审批完回写状态；HR 的组织架构变更自动推送到 OA 和 ERP；MES 的工单完成状态回传 ERP 触发财务核算。
然后他们就遇到了所有多系统企业都会遇到的问题：选什么架构来做集成？
有人提 ESB，有人推荐 iPaaS，还有供应商在推"连接中台"。三个词，听着都像那么回事，但真要选的时候发现------大部分人其实没弄明白这三者到底差在哪。
▲ 泛微 OA 的流程表单------这是企业最常见的需要跟其他系统对接的场景：审批完的数据要同步到 ERP、财务等系统
这篇文章从技术架构的角度，把三种方案的设计思路、核心差异和适用场景梳理清楚。
先对齐一个概念：系统集成的本质是什么
无论叫什么名字，系统集成本质上只做三件事：
- 连接：让两套系统能够通信。你的协议是 REST 还是 SOAP，走 HTTP 还是消息队列，token 放在 Header 还是 Body------把这事搞定。
- 转换 ：让两套系统的数据能互相理解。A 系统的"客户编码"字段叫
cust_code，B 系统叫customerId；A 用"男/女"，B 用"M/F"。做映射。 - 编排：让多步操作按业务逻辑串联。"审批通过 → 生成凭证 → 推送 ERP → 回写 OA 状态"，这不是一次请求能搞定的，需要流程编排。
三种架构的区别，就在怎么设计这三件事的分工上。
ESB：中心化的企业服务总线
设计思路
ESB（Enterprise Service Bus）诞生于 SOA 时代，核心思想是在所有系统之间架一条"总线"，所有系统都接到总线上，通信、转换、路由全部由总线统一管理。
ESB 的核心抽象：所有系统只说一种语言（通常基于 SOAP/XML），总线负责把消息翻译、路由、转换后送达目标系统。
技术特征
- 通信协议统一：通常基于 SOAP over HTTP 或 JMS 消息队列，要求所有接入系统遵守同一套消息规范。
- 转换集中管理：数据映射（XSLT、XPath 等）在总线上统一配置，不分散在各系统。
- 重量级部署：需要独立的中间件服务器（如 IBM WebSphere、Oracle Service Bus、Mule ESB），部署和维护成本高。
- 强中心化：总线是唯一的通信中枢，总线宕机意味着所有系统之间的通信中断。
适用场景
大型企业，内部系统以 SOAP/XML 为主，有专职中间件团队，系统变更频率低，架构稳定。银行、保险等强监管行业的内部系统集成。
局限性
ESB 在设计上假设"所有系统都愿意迁就总线协议"。这在 2025 年的现实里越来越不成立------SaaS 系统几乎全是 RESTful JSON API，要求它们适配 SOAP 不现实。而且 ESB 的部署和维护成本决定了它对中小企业不友好。
iPaaS：云原生的集成平台即服务
设计思路
iPaaS（Integration Platform as a Service）是 SaaS 时代的产物。核心理念：把集成能力做成一个云服务，用户不需要部署中间件，在网页上配置连接器、设置数据映射、定义触发器即可。
iPaaS 的核心抽象：把系统对接变成"拖拽配置"，连接器是预制的、平台是托管的、你只管定义业务逻辑。
技术特征
- 预置连接器生态：主流 SaaS 应用（Salesforce、Workday、NetSuite 等）有现成连接器，几分钟完成对接。
- 低代码配置：数据映射、触发器、定时任务通过 Web UI 配置，不写代码。
- 全托管：平台负责运维、扩容、高可用，用户零运维。
- 事件驱动：通常以 Webhook 或消息队列作为触发器，支持准实时同步。
典型的技术栈是：预置 Connector + 可视化 Flow Builder + 托管的 Runtime。以 Workato、Zapier、Make（原 Integromat）为代表。
▲ 飞书工作台------典型的 SaaS 平台，这类系统是 iPaaS 的主要覆盖范围，但本地部署的 ERP 和自研系统就不在这个覆盖范围内了
适用场景
SaaS 系统为主的轻量集成：市场部要把 HubSpot 的线索自动同步到 Salesforce，HR 要把 BambooHR 的员工数据同步到 Slack------碎片化、轻量、高频的场景。
局限性
在严肃的企业集成场景下，iPaaS 有几个硬伤：
- 数据出境：所有数据流经第三方云端，对于财务数据、客户隐私、合规要求严格的企业是红线。虽然有私有化部署的 iPaaS 方案，但大部分主流 iPaaS 是纯 SaaS 模式。
- 本地系统接入困难：预置连接器主要覆盖主流 SaaS，遇到本地部署的用友 U8、金蝶 K3 等国产 ERP，或者企业自研系统，通常没有现成连接器。需要通过 Agent 或者自定义开发来桥接，复杂度和灵活性大打折扣。
- 编排能力有限：iPaaS 的流程编排偏向简单线性------"如果 A 发生，做 B"。面对复杂业务逻辑（条件分支、异常回退、事务补偿、人工审批节点），表现力不足。
- 成本线性增长：按连接数或任务执行次数计费，系统数量上去后，每月的费用不是小数字。
连接中台：介于 ESB 和 iPaaS 之间的第三条路
设计思路
连接中台（Connection Hub）可以理解为"私有化部署的 iPaaS + ESB 的编排能力 - SOAP 的包袱"。它的核心假设是：
不同系统说不同的协议是正常状态，连接中台的任务不是统一它们，而是适配它们------用连接器适配各种协议，用编排引擎串联业务逻辑，数据留在本地。
技术特征
- 多协议适配：不要求系统迁就统一协议。REST API、SOAP WebService、数据库直连（JDBC/ODBC）、SDK 调用、甚至 RPA 模拟操作------根据系统实际暴露的接口灵活匹配。
- 私有化部署：部署在企业自己的服务器上，数据不经过第三方。对于财务、人事、客户隐私等敏感数据的集成，这是硬需求。
- 连接器可扩展：主流系统有预置连接器，冷门或自研系统通过自定义连接器扩展，不依赖平台厂商的支持覆盖度。
- 流程编排引擎：支持条件判断、并行执行、异常回退、超时重试、人工审批------面向复杂业务流程而非简单数据搬运。
- 数据沉淀能力：数据在中台持续流转的过程中，客户、供应商、组织架构等主数据自然集中，天然形成 MDM（主数据管理）能力。不是另建一套 MDM 系统，而是在集成过程中自然实现数据标准化。
适用场景
3 套以上业务系统、混合了本地和云端、有敏感数据合规要求、需要复杂业务编排的成长型和中型企业。国内大量使用用友、金蝶、泛微、钉钉、飞书等混合生态的企业。
▲ 连接中台的典型界面：连接器管理 + 流程编排 + 数据监控，一站式管理所有系统对接
一张表看完三种架构的差异
| 维度 | ESB | iPaaS | 连接中台 |
|---|---|---|---|
| 部署方式 | 本地中间件服务器 | 公有云 SaaS | 私有化部署 |
| 协议要求 | 统一 SOAP/XML | REST/Webhook 为主 | 多协议适配，来者不拒 |
| 连接器覆盖 | 自建，无预置 | 主流 SaaS 预置 | 主流系统预置 + 可自定义扩展 |
| 数据位置 | 企业内部 | 第三方云端 | 企业内部 |
| 编排能力 | 强（BPEL 等） | 偏弱（线性为主） | 强（复杂流程+异常处理） |
| 运维成本 | 高（专职团队） | 低（平台托管） | 中（私有化但轻量） |
| 冷门系统支持 | 完全自定义 | 受限（依赖平台） | 自定义连接器 |
| 适合规模 | 大型/超大型企业 | SaaS 为主的中小企业 | 中大型、混合环境 |
| 数据沉淀/MDM | 不内置 | 不内置 | 天然形成 |
选型决策框架
实际选型时，不需要从这三个名词出发。从自己的实际情况出发，问四个问题：
- **数据能不能出境？**不能 → 排除纯 SaaS iPaaS。选私有化部署的 ESB 或连接中台。
- **系统都是什么协议？**全是 SOAP → ESB 有优势。REST + 数据库 + 自定义混合 → 连接中台更灵活。
- **对接复杂到什么程度？**只是传数据 → iPaaS 够用。有审批节点、条件分支、异常补偿 → 需要编排引擎。
- **团队有几个人？**有专职中间件团队 → ESB 能驾驭。IT 团队 3-5 人 → 需要轻量方案。
一个实用的经验法则：2 套系统以内，点对点够用。3-5 套且混合环境，评估连接中台。5 套以上或纯内部 SOA 架构，ESB 仍有价值。纯 SaaS 轻量场景，iPaaS 成本最低。
最后
三种架构没有绝对的好与坏，只有适不适合。十年前 ESB 是唯一选择，五年前 iPaaS 开始流行，现在连接中台作为第三条路提供了私有化 + 灵活适配的折中方案。
关键不是追哪个词热，而是搞清楚自己的系统环境、合规红线、业务流程复杂度和团队能力，然后匹配最合适的架构。以上方案在 S-HUB 中有对应实现，感兴趣的可以访问官网了解。