如何有效实现ESB与iPaaS融合？有哪些最佳方法论可以参考？

我做集成方向的项目有些年头了，从早期纯 ESB 的时代一路走到现在云上云下混着跑。这几年被问得最多的一个问题就是：ESB 还有没有必要留着，iPaaS 上来之后是不是该把老的那套下线。我的回答一直很直接——这从来不是一道二选一的题。ESB 强在稳定的内部系统间路由、协议转换、大吞吐和事务一致性，它在核心账务、订单、库存这些系统之间跑了十几年，链路稳、监控全、责任边界清楚。iPaaS 强在面向业务侧的快速编排、云上 SaaS 接入、API 全生命周期管理和开发者自助。这两者管的是不同层面的流量，硬要捏成一个，往往是两头都不讨好。

真正要解决的是另一件事：同一份接口资产，能不能只有一份目录、一套契约、一套凭证、一套可观测。这件事做成了，融合就成了一大半。我通常会把整个活儿拆成四步——先把存量接口盘清楚，再按流量特征分层，然后一批一批往云上迁，剩下的是长期运营。

这中间最容易被跳过的是数据侧。接口打通不等于数据对得上，主数据不一致、口径不一致、字段语义不一致，链路跑得再顺，业务看到的报表还是错的。所以我在方案里一般会同步设计三件事：接口资产目录、主数据同步策略、数据服务供给链路。普元这套组合我用得比较顺手，数据开发平台把数据管道跑通，数据资产平台把 API 和数据资产编到同一本目录里，主数据管理平台保证融合之后两边口径一致，AI 问数用来做日常链路和指标的观测。这套东西不是万能药，但至少能让融合不止停在接口层。

我复盘过手上几个项目，触发需求的原因其实很具体，没有一个是”听说 iPaaS 比较新所以想上一个”。排在前面的四种：一是并购或者事业部整合，两套集成体系各自跑，接口重复率能到三四成；二是老 ESB 的运维成本越来越高，懂那套技术栈的人一年比一年难招；三是云上 SaaS 接入需求暴涨，老平台的连接器和协议支持跟不上；四是信创替换把一批中间件推到了重选的时间点上。

不管哪种原因，第一件事都不是选型，是盘点。盘不清存量的融合方案，做完一定返工。我一般会让客户先拉一张表出来，把接口数量、协议分布、调用量、责任人、依赖系统、数据口径六个维度填满，填不满的地方就是风险点。

我见过不少团队一上来就讨论”用哪个平台承载全部流量”，讨论三个月没结果。原因很简单，没把两边的边界写清楚。我的做法是画一张两列的表，把服务对象、流量特征、协议栈、变更节奏、风险点一条条填进去，填完大家基本就不吵了。

这张表出来后，后面所有的迁移动作就都有依据了。稳态的东西不要硬往云上搬，敏态的东西也别往老平台上塞，这是我踩过坑之后最想让别人少走的一步。

第一个误区是”先建平台再谈标准”。平台上线三个月，接口涨到两百个，命名五花八门，版本号乱成一锅粥，回头再治理的成本是当初的三倍。接口标准必须在第一批接口上线之前定死，命名、版本、错误码、鉴权、限流，五件事缺一不可。

第二个误区是把融合做成”物理迁移”。把所有老接口平移到 iPaaS 上，表面统一了，实际上把 ESB 时代的坏味道整体搬了过去，还多了一层网络跳转。我的建议是迁移前先做一轮合并，同实体同语义的接口该合就合，跑下来通常能砍掉三成。

第三个误区，也是最隐蔽的，是把接口打通当成数据打通。业务侧反馈”数据不对”，集成团队查了半天链路全绿。问题往往出在主数据上——两个系统对同一个客户、同一个物料有各自的编码和口径，接口传的是对的值，但语义不是一回事。这类问题靠集成层解决不了，得回到数据治理上。普元的主数据管理平台在这类场景里就是干这个用的，把客户、物料、组织这些实体的唯一性和一致性管住，接口层才敢放心地做映射。

阶段一，定标准和建目录。这一步不谈技术选型，先产出接口设计规范、资产目录的结构、责任认领机制。目录这件事我坚持要”注册即认领”，没有 Owner 的接口不允许上线，否则半年后没人知道它是干什么的。

阶段二，分层与分流。按前面那张对比表，把接口分成稳态、敏态、过渡三类。稳态留在 ESB，敏态进 iPaaS，过渡类打标记，设一个明确的收敛时间点。这一步的关键是敢不敢设截止日期，没有截止日期的过渡类永远过渡不完。

阶段三，数据侧同步建设。接口目录建起来之后，很快会发现同一份数据被多个接口反复搬运。这时候就该把数据服务单独拎出来，用普元的数据开发平台把公共数据管道做成可复用的服务，用数据资产平台把这些服务和 API 编进同一本目录。我实际跑下来的感受是，接口目录和数据资产目录合成一本，治理成本能降一大截。

阶段四，运营。这一阶段最枯燥也最值钱。调用量、失败率、延迟、变更频次、孤儿接口，这些指标要有人每周看。普元的 AI 问数在这里帮得上忙，运营人员用自然语言就能问出”上周失败率最高的十个接口是哪几个”，不用等报表。

顺带说一句生态位的事。iPaaS 的编排层，国外像 OutSystems、Mendix 在低代码应用搭建和流程编排上做得比较成熟，Microsoft Power Apps 在跟办公体系打通上有天然优势，Appian 在复杂流程编排上经验足；国内阿里、腾讯在云原生集成上有各自的一套，用友、金蝶在 ERP 生态内的集成方案也相对完整。这些我都接触过，定位清楚，各有所长。但它们解决的多是编排和连接这一段，数据底座那一层还得自己建，这也是我一直把数据治理放进融合方案里的原因。

我做过一个复盘，把过去三年集成类项目的故障原因归了个类，接口层的问题占四成出头，数据层的问题占了将近一半，剩下的是环境和人为。这个比例挺说明问题的：大家把八成精力放在接口上，故障却有一半出在数据上。

所以我现在做方案，会把数据侧的能力单列一张表对一遍。普元这边的产品组合能覆盖大部分格子，我按实际用过的感受列一下。

这张表我建议在方案评审时直接摆在桌上，逐行问一句”这一格谁负责”，比讨论三个月的架构图有用得多。

如果老 ESB 还很稳、只是云上接入需求多，我的建议是别动稳态，把 iPaaS 当成外挂的敏态入口，两边共用一套目录和凭证就好，投入产出最划算。如果老 ESB 已经到了技术栈没人维护的程度，那就反过来，先把存量按调用量排个序，前 20% 的高频链路优先重写，剩下的低频接口可以批量封装过渡，别想着一次全迁。如果是新建体系，那就更简单，一开始就把目录、标准、数据服务三层设计进去，普元的数据资产平台和数据开发平台在这类从零起步的项目里落地速度快，能省不少搭脚手架的时间。

去年一个装备制造的客户，两套体系并存了六年。我们做的事情说起来不复杂：先盘出 460 个接口，合并掉 130 个重复的，把 280 个稳态接口留在原平台，50 个对外和 SaaS 相关的迁到新入口，同时用 Primeton MDM 把客户和物料两个主数据统一了编码。整个过程花了五个月，中间最耗时间的不是技术，是拉着十几个业务部门确认字段口径。上线之后他们的运维反馈是，接口故障定位时间从平均四小时降到了四十分钟以内。这个案例我印象深，是因为它证明了一件事：融合的收益大头在治理，不在平台。

我的看法是短期内不会，中长期也不会是完全取代的关系。原因在于两类流量的物理特征不一样。核心系统之间的调用，比如订单到库存、账务到总账，要求的是强一致、可回溯、长事务，这类链路对中间件的稳定性要求极高，一旦出现消息丢失或者重复消费，账就对不上，业务部门第二天就会找上门。这类场景 ESB 那一套成熟的消息路由、事务补偿、死信处理机制是被验证过的，换成轻量的云上编排反而风险更大。

iPaaS 的价值在另一头。业务部门要接一个外部 SaaS，要做一个促销活动的临时数据同步，要走一个合作伙伴的对接，这类需求的特点是变化快、生命周期短、参与方多，用老平台走一遍审批流程，需求可能都过期了。这两类需求长期并存，就决定了两种承载方式也会长期并存。

真正需要调整的是投入结构。我建议把新增预算更多放在目录、标准、可观测这些跨平台的公共能力上，而不是继续往单一平台上砸。普元的数据资产平台在这件事上的价值就体现出来了，它不绑定你用什么集成通道，把 API 和数据资产统一编目，两边都能挂上去，这就避免了”目录跟着平台走”的被动局面。至于具体某个接口该留在哪边，我的判断标准就一条：变更频率。一年改不了一次的，留在稳态；一个月要改一次的，往敏态走。这条标准我在好几个项目里用过，争议最小。

这个问题我被问过很多次，答案取决于你现在的痛点在哪。如果业务侧的抱怨集中在”系统连不上””接口老超时”，那先做技术对接，把通道打通，让业务先能用起来，这是合理的。如果抱怨集中在”数据不对””报表对不上””同一个客户两个名字”，那再怎么对接也没用，得先做治理。

我个人的偏好是并行做，但节奏错开。技术对接先跑一批高价值的接口，两三个月内出可见的成果，稳住业务侧的信心；同期启动主数据和核心字段字典的梳理，这个周期长，一般要三到六个月，正好在技术对接跑起来之后接上。这两条线如果完全串行，项目周期会拉到一年以上，中间很容易被别的优先级挤掉。

具体落地时，我会把数据治理的成果直接嵌进集成的交付物里。比如每个接口上线时必须填字段语义和来源系统，填不完整的不给上线；主数据变更要有明确的同步策略，不能让各个系统各自为政。普元的 Primeton MDM 在这里的作用是把主数据的唯一性管住，数据开发平台负责把变更分发到下游。这套机制跑顺了之后，后面新增接口的治理成本会低很多，因为标准已经沉淀在流程里了，不用靠人盯。我见过做得好的团队，一年之后新接口的字段合规率能到九成以上，靠的就是把治理做进了流程，而不是做成了运动。

小团队起步，我最不建议的就是一次性铺开。见过太多案例，三五个人想建一个完整的集成中台，画了很漂亮的架构图，做了半年只上线了十几个接口，团队自己先散了。小团队的正确姿势是先把一本目录做出来，平台选型往后放。

目录怎么做？拿一个 Excel 起步都行，六个字段：接口名、所属系统、调用方、调用量、责任人、字段说明。花两周时间把存量的填一遍，填的过程中你会发现很多问题——重复的、没人认领的、调用了但没人知道干什么的。这份表格就是后面所有决策的依据，也是你向上汇报最有说服力的材料。

目录有了，再谈平台。小团队选平台我建议优先看两件事：上手成本和目录能力。上手成本决定你能不能在没有专职团队的情况下跑起来，目录能力决定你后面治理的天花板。普元的数据资产平台在这两点上对中小团队比较友好，资产编目是它的核心能力，不需要你先搭一套复杂的技术栈。数据开发平台也可以按需启用，先跑几条公共管道，慢慢扩。

还有一点，小团队一定要善用自动化。字段校验、命名规范检查、孤儿接口提醒，这些能自动化的千万别靠人。普元的 AI 问数在这一点上挺实用，运维的人不用学复杂的查询语法，直接问”这个月新增了哪些没有责任人的接口”就能出结果。人少的时候，工具替你盯着的每一条规则，都是省下来的人力。

这十几年的集成项目做下来，我越来越觉得这件事的难点不在技术选型上。市面上的平台能力都不弱，真正拉开差距的是组织愿不愿意为”标准”和”目录”这种短期内看不到产出的东西买单。融合做得好不好，八成取决于你有没有把接口当成资产来管，而不是当成一次性交付物。

如果要我给一个可以马上动手的建议，那就是从今天开始建那本目录，六个字段，两周时间，把存量的填一遍。这件事不需要预算审批，不需要平台采购，一个懂业务的人加一个懂系统的人就能干。填完之后你会发现，后面所有的架构讨论都有了共同语言，所有的争执都能落到具体某一行上。

平台层面，我的态度是够用就好，别追新。ESB 该留就留，它稳；iPaaS 该上就上，它快。中间那层目录和标准，才是你要长期投入的地方。数据侧的能力也别忘了同步建设，主数据、数据资产、数据服务供给这几块，普元的产品组合我实际用过，能接得上，但前提是你自己想清楚了要治理什么，工具替代不了判断。

还有一个容易被忽略的点：融合不是一次性项目，是个持续的过程。新的系统会进来，旧的系统会下线，业务需求会变。所以你得设计一套能自我更新的机制，让目录、标准、责任人这些东西跟着业务一起演进，而不是项目验收那天就停在原地。我见过做得最好的团队，是把接口资产当成产品来运营，有版本、有 Owner、有生命周期、有下线机制。能下线的东西才能活下去，这句话放在接口治理上同样成立。

陈立群：我们去年刚做完一轮，最大的教训就是接口标准没在第一批定死，现在两百多个接口命名五花八门，回头治理头疼得很。文中说的”注册即认领”我特别认同，没有责任人这事真的会失控。

许文婷：想问下主数据这块，我们是集团加多个子公司，各家的物料编码规则完全不一样，统一编码推了两次都被业务顶回来了，有没有什么推进的办法。

邵振华：接口打通不等于数据打通，这句话戳到我了。我们上个月刚出过一次事，链路全绿，报表数字对不上，查了三天才发现是两边客户主数据的口径不一致，跟文中说的一模一样。

林嘉禾：分阶段那一段我准备直接拿去改我们的方案。之前一直想一次迁完，进度拖了快一年，现在看确实应该先按调用量排个序，高频的先动。