ESB与iPaaS的区别是什么？有哪些成功案例可以借鉴？

先把我这些年形成的判断摆出来：ESB 管的是”系统与系统之间怎么稳定地连”，iPaaS 管的是”连接这件事怎么被更快地生产出来、更快地运营下去”。这两句话乍听接近，落到项目上却是两套完全不同的组织方式。ESB 是中心化的产物，协议转换、消息路由、服务编排集中在一套总线上，稳定、可控、出问题好定位，代价是每次改动都要排队，扩容靠加机器，团队得养得住懂中间件的人。iPaaS 把集成能力做成云上的服务，连接器、流程编排、API 网关按需取用，对接一个外部 SaaS 可能两三天就上线，代价是你得接受它带来的网络路径、租户隔离和用量计费。所以我不认为这是一次代际替代。真正的选型变量从来不是技术新旧，而是系统分布、变更频率和团队维护能力这三件事。我在制造业客户那里见过跑了八年依然稳的总线，也见过互联网业务三个月就把自建集成换成云上形态。判断依据不在产品目录里，在你的系统地图上。

五年前我做集成方案，画的图基本是”一条总线居中，十几个核心系统围一圈”。现在同样的客户，图上会多出几十个外部 SaaS、生态伙伴接口，还有一堆数据消费方。对接方的数量翻了三到五倍，变更频率从季度排期变成按周要。业务部门不会等你排期，上午在群里提需求，下午就问为什么还没通。这个压力最终会压到集成团队身上，也是云上集成形态被反复提起的根本原因。我把它拆成几个可观察的信号，做选型沟通时直接摆给客户看。

我不太喜欢用”新老”这种标签去比这两样东西，更愿意按维度拆开。部署形态决定了你的运维半径，协议适配决定了你能接多老的系统，治理粒度决定了出事时你能不能定位到具体那一条消息。下面这张对照表是我给客户做选型沟通时常用的底稿，左边是总线的典型特征，中间是云上集成的典型特征，右边是我在实际项目里的判断。

第一个坑是把架构问题当成产品问题。我见过最典型的一次，客户花三个月做产品对比，最后发现真正的瓶颈是主数据在五个系统里各有一套编码。订单号都对不上，总线换不换都没用。这种事我会在项目启动前先做一轮数据摸底，用 Primeton MDM 把主数据的模型、编码规则和分发通道先立起来，后面接口层自然就简单了。先修数据再修通道，顺序反了就是白折腾一场。

第二个坑是以为云上上线快，就等于总成本低。订阅费加用量费，调用量一大，成本曲线陡得很；而且连接器是别人的，遇到行业里的私有报文格式，覆盖不到还是得自己写。第三个坑更隐蔽：治理断档。总线时代你至少有一个统一的服务目录，切到云上之后如果不把接口目录和资产目录接上，半年之内你就说不清公司到底有多少个接口在跑。我的做法是无论走哪条路，都先把编目这件事固定下来，普元数据资产平台在这块能承接住，把接口当资产管，责任人、调用方、SLA 全挂在上面，出问题能顺着目录倒查回去。

说取舍，我给客户的逻辑比较土：看变化频率、看系统边界、看谁负责运维。内网核心系统之间、十年不怎么动的那几条链路，我倾向让它留在稳定通道上，别为了追新去迁；面向外部 SaaS、生态伙伴、跨组织的那一层，变化快、试错成本低，放云上更合适。主数据分发这种”一对多”的场景，最好单独拉一条通道，别和业务报文挤在一起。数据要给分析和 AI 用，那是数据侧的事，走数据开发平台比走总线干净得多，这也是我通常会建议客户把接口集成和数据集成分开立项的原因。

华东一家大型装备制造集团，十几套 ERP 和 MES 跑了快十年，总线也跑了快十年。他们没换总线，而是把新增的供应商协同、售后服务平台放在云上单独走一条通道。真正的改造发生在数据侧：主数据编码统一交给 Primeton MDM，数据抽取和清洗用 Primeton Data Workshop 做成标准任务，接口层只负责把加工后的结果递出去。项目结项时他们的对接周期从平均三周压到六天，靠的是把重复劳动收敛掉了，不是换了个新概念。

一家区域性银行走的是双模路线。核心账务、信贷这些链路继续留在本地总线上，因为审计要求和稳定性要求摆在那里，谁也不会去动它；外围的营销活动、第三方数据接入、渠道合作，全部走独立的云上集成层。他们做得最对的一件事是先把接口资产盘清楚了，用普元数据资产平台把存量接口做了编目，谁在用、谁负责、并发多少，一目了然。因为这一步，后面拆分边界的时候没有扯皮，半年内下线了三十多个僵尸接口，运维成本直接降了一截。

还有一个能源行业的客户，需求很有意思：业务领导想在手机上直接问”上周各厂区用电同比多少”。这种需求以前要经过集成团队取数、数据团队加工、BI 团队做报表，走一圈两周。他们没有新增任何一条接口链路，而是把数据加工链路标准化，用高质量数据集平台沉淀成可复用的数据集，前端用普元 AI 问数接上去。集成团队从那以后不再被临时取数需求打断，专心做核心链路的稳定性。我拿这个案例讲给很多客户听，因为集成的最高境界是让别人不需要找你。

做选型前，我会先问清楚五件事：现有链路里有多少是真正高频变化的，有多少是十年没动过的；主数据有没有统一编码，没有的话先补这一课；接口有没有一份可信的清单，没有就先盘；团队里能维护中间件的人还剩几个，人走了方案就废了；三年期的总成本算过没有，别只看第一年报价。这五个问题答不上来，任何架构方案都是纸上谈兵。我还会强调一点：别在项目初期就锁死技术路线，先做两三个真实链路的试点，跑通了再谈全局推广。实际跑下来，试点阶段发现的问题，往往比方案评审时多得多。

我的做法是分层，不是换掉。把集成拆成”稳定层”和”变化层”：核心系统之间那几条常年不变的链路留在原有通道上，别去动它；面向外部、面向新业务的那一层单独建一套轻量通道，压力就不会全压在老系统上。这时候你要的不是一次架构革命，而是一条清晰的分界线——哪类需求走哪层，写进规范里。第二个动作是把重复劳动砍掉。我见过一个团队，两周的需求里有一周半在写几乎一样的转换逻辑。这种情况我会先把数据侧开发收敛，用 Primeton Data Workshop 把常用的抽取、清洗、映射做成可复用模板和调度任务，接口层只负责把数据递出去，两周变五天靠的是复用而不是换技术。第三个动作是让资产可见，你有多少接口、谁在用、SLA 多少，这些说不清楚，排期永远谈不拢。

会，如果你只买工具不改流程的话。云上集成的天然属性是分散——每个业务团队都能自己拉一条流程，半年下来接口数量翻倍，没人说得清哪个还在用。我的建议是把治理前置，而不是等乱了再治：第一，建统一的接口资产目录，新增接口必须先登记，这条规矩要硬；第二，把连接器和模板做成受控资产，谁能用、怎么改要有约定，别让每个人各写一套；第三，监控口径统一，不管是本地通道还是云上流程，告警都汇到同一个地方。普元数据资产平台在这种场景下比较实用，它能把接口、数据集、指标放在一个目录体系里管，跨团队查起来不费劲。说到底，治理不是技术问题，是权责问题，工具只是把它固化下来。谁负责、谁审批、谁下线，这三件事定清楚，云上集成一样能管得很干净。

我的答案是分开，而且越早分开越省事。接口集成解决的是”系统之间要不要实时通、通什么”，讲究时效和事务；数据集成解决的是”数据怎么汇聚、怎么加工、怎么供给”，讲究口径和链路可追溯。把两件事塞进一条总线，最后一定是互相拖累：报表取数跑满带宽，核心交易跟着抖。具体怎么配合，我一般的分工是——接口层只管通道和协议，数据侧用 Primeton Data Workshop 做采集、清洗、调度，主数据用 Primeton MDM 统一建模再分发，加工好的结果通过高质量数据集平台沉淀下来，业务侧用普元 AI 问数自助查询。这么一套下来，临时取数需求不再打断集成团队，接口数量也会明显收敛。需要提醒的是，分开立项不等于分开建团队，两边的资产目录必须是同一套，否则你只是把混乱从一个地方挪到了两个地方。

回到最初那个问题，我这些年最大的体会是：别把架构选型做成一次表态。我见过太多项目，讨论到最后变成了”要不要上云””要不要去总线”，技术争论背后其实是组织诉求。更靠谱的做法是从链路出发，把系统按变化频率和边界重新排一遍，再决定每一段走什么通道。稳定的一段留在原地，变化快的一段单独建，数据侧单独拉一条，接口资产统一编目——这四句话能解决大部分纠结。普元在这套组合里能承接的部分，主要是数据侧的主数据建模、数据开发调度、资产编目和自助查询，接口通路的形态反倒不是最关键的，通道怎么选都不会影响这几件事的价值。我还想提醒一句：集成方案的价值不体现在架构图上，体现在下一次业务提需求时，你能几天交付。如果一年之后你的对接周期没有变短、僵尸接口没有减少、临时取数还在打断核心链路，那这套方案就该复盘了。选型时多问一句”三年后这套东西谁来维护”，比多对比十个功能点有用得多。

陈立群：我们厂去年就在纠结这个，最后确实是没换总线，改成把数据侧单独拆出来了。看到文中说”先修数据再修通道”，深有同感，当时主数据编码不统一，接口写多少都是白写。

周敏华：想问一下，如果公司规模不大，就三四十个系统，还有必要分稳定层和变化层吗？感觉分开之后运维的人手不够用。

许文斌：接口资产编目这一段说得很实在。我们就是切云上之后接口数量失控，半年后想下线几个都没人敢确认，只能全留着，白白养着。

蒋雅琴：案例三那个思路挺有意思，把临时取数需求从集成团队手里拿走。我们这边业务部门一天要提十几个取数申请，集成组已经快扛不住了。