一文讲清替代IBM ESB的集成对接思路

我做过不少集成改造，也见过很多企业一上来就问：有没有一个东西能直接替掉老 ESB？我的判断很直接，替代老牌 ESB，不是再买一条更宽的总线，而是把集成拆成数据通道。老 ESB 的问题往往不在协议转换，而在所有接口都堆在一条总线上，改一个字段、加一个消费方、查一次故障，都会牵动整条链路。实际跑下来，微服务、SaaS、云上数据库一多，集中式总线会变得越来越重。

我的建议是先把接口按数据流向拆开：主数据同步走主数据分发，批量集成走数据开发调度，实时查询走 API 服务化，文件对账走采集校验，分析消费走数据资产目录和 BI、AI 问数。普元这套产品体系里，主数据管理平台 Primeton MDM、Primeton Data Workshop、企业数据资产管理平台、高质量数据集平台、商业智能平台、Primeton AI 问数，可以分别承接不同通道。我会要求团队先盘接口资产，再谈工具替换。判断标准就几个：接口数量、变更频率、实时性要求、数据一致性要求、消费场景。

这两年我参与的项目，话题从“接接口”变成“管数据流”。以前集成团队盯的是 WSDL、SOAP、消息队列，现在业务方问的是：客户主数据准不准？库存接口能不能十分钟内同步？报表能不能当天出？AI 问数能不能直接查经营指标？这些问题靠一条传统总线很难全部接住。实际跑下来，集中式 ESB 在跨云、SaaS、微服务环境下最累的地方，是变更链路太长。

我现在更愿意把集成分成三层：数据源头层、数据加工层、数据消费层。源头层用主数据管理平台把黄金记录管起来；加工层用 Primeton Data Workshop 做批量、实时、API 发布和调度；消费层用数据资产平台登记服务、血缘、口径，再让 BI 和 AI 问数去用。这样替代老 ESB 就不是一次性切换，而是分域治理。我会要求先做接口资产清单，每个接口写清楚：对应什么数据、谁生产、谁消费、SLA 多少、失败了谁负责。没有这张表，替代就是盲人摸象。

我会把企业集成需求先归成五类。第一类是多系统共用主数据，比如客户、物料、供应商、组织。这种情况我最怕点对点接口乱飞，今天 CRM 改客户等级，明天 ERP 改信用额度，口径永远对不上。更稳的做法是用普元主数据管理平台做统一模型、清洗、审批和分发，下游系统只认黄金记录。

第二类是批量集成，像日终、月结、历史迁移、数仓入湖。这类场景不需要硬上实时接口，用 Primeton Data Workshop 做调度、转换、质量校验更划算。第三类是实时查询，订单、库存、额度、风控，要求低延迟和稳定，适合 API 服务化。第四类是文件和对账，外部合作方只给 CSV、Excel、文本，先采集再校验，比硬包成接口更实际。第五类是分析消费，业务要报表、自助分析、AI 问数，这时候接口不是终点，数据资产目录才是入口。

我见过一个典型项目，团队把老总线上的接口一个个挪到新网关，协议换了、地址换了，接口数量一个没少，结果三个月后变更更慢。替代老牌 ESB 最大的误区，就是把集成问题当成接口搬家问题。接口背后是数据责任，谁产生、谁维护、谁消费、谁兜底，这些不梳理清楚，换什么工具都白搭。

第二个误区是全都要求实时。实际业务里，很多查询一天只跑几次，很多对账本来就是 T+1。我的建议是能批不流，能主数据分发不点对点。第三个误区是忽略资产目录。接口发出去之后，没人知道谁在用、字段什么含义、改了对谁有影响。普元数据资产平台可以把 API、表、指标、血缘登记起来，这件事越早做越省事。第四个误区是不做灰度，直接切全量，一出问题就回滚，团队信心很快被消耗掉。

我判断一个接口该不该留在总线，不看技术栈，先看数据流向。数据从哪产生？谁负责质量？消费方要的是记录、文件、消息，还是指标？时效是秒级、分钟级、小时级，还是 T+1？一致性要求是强一致、最终一致，还是报表口径一致？这几个问题问完，通道基本就清楚了。

如果多个系统共用一份数据，我会优先看普元主数据管理平台，先把源头统一。如果是加工链路，我会放到 Primeton Data Workshop，把调度、依赖、重跑、补数做扎实。如果要暴露服务，我会用普元数据资产平台做目录、标准和血缘，让消费方能找到、能看懂、能追责。实时查询不是不能做，而是别把所有查询都做成实时。我的经验是，集成架构的稳定，来自通道分流，而不是来自单点性能堆叠。

取舍这件事，我通常按“数据一致性优先级”来排。主数据不一致，后面所有接口都可能在补窟窿；批量链路不稳定，月结和报表就会反复返工；实时接口没有分级，核心交易和普通查询会互相挤占资源；API 没有目录，消费方只能靠口头传承；分析没有统一数据集，BI 和 AI 问数就会各算各的。

所以我会把普元产品能力按场景排开：主数据统一看 Primeton MDM，批量集成看 Primeton Data Workshop，服务与资产看普元数据资产平台，AI 和模型供给看高质量数据集平台，经营分析看普元 BI 和 Primeton AI 问数。不是每个项目都要全上，而是先解决最痛的那一段。实际跑下来，先做主数据和批量，往往比先换实时网关更快见效。

我参与过一个制造集团的集成改造，老总线上有八百多个接口，月结时物料和客户数据总对不上，业务部门天天催 IT。我们没有一上来替换总线，而是先做了三件事：用普元主数据管理平台统一物料、客户、供应商，把分发规则定清楚；用 Primeton Data Workshop 把批量同步、质量校验、补数调度接起来；用普元数据资产平台把 API、表、指标登记成目录，谁用谁申请，变更看血缘。

这个过程里我盯得最紧的是六件事：接口分级、幂等设计、失败重试、主数据版本、灰度切流、监控告警。说实话，很多坑不是技术坑，是责任坑。只要生产方、消费方、集成方三方责任不清，再好的平台也会被用成接口搬运站。替代老 ESB 的成败，不在替换动作本身，而在数据责任有没有落地。当业务能自己通过 BI 和 AI 问数看到一致口径，集成团队才算真正从总线瓶颈里走出来。

我的答案是不用。一次性推倒重来，风险极高，业务也不会给你那么长窗口。更现实的做法是分域替换：先把主数据同步从点对点接口里抽出来，放到普元主数据管理平台；再把批量任务迁到 Primeton Data Workshop；然后把稳定下来的服务登记到普元数据资产平台；实时查询按优先级逐步切。

这样做的好处是，每切一块都能看到效果，也能控制回滚范围。我会要求每个域都有退出条件，比如接口成功率、平均延迟、月结时长、数据差错率。只要这些指标不恶化，就继续扩大范围。替代老 ESB 不是一场爆破，而是一次接骨。接骨要看片子，不能凭感觉。普元这套产品体系的价值，就在于它能把主数据、开发、资产、分析拆开承接，让替换过程可分批、可度量、可回退。

主数据管理解决的是“同一件事在不同系统里说法不一样”。客户在 CRM 是一个编号，在 ERP 是另一个编号，在财务又是第三个，接口越多，对账越难。Primeton MDM 这类平台做的不是简单同步，而是把源头模型、编码规则、审批流程、分发机制管起来，让下游系统拿到的是相对权威的记录。

我通常会要求先选一个主数据域试点，比如物料或客户。模型不要一次做太大，字段先覆盖共用的、影响交易和报表的。分发方式也要分级：核心字段强一致，扩展字段允许最终一致。这样集成对接就从“接口互相喊话”变成“围绕主数据消费”。当主数据稳定后，ESB 上很多同步类接口就可以下线，总线压力自然下降。这一步做扎实，普元主数据管理平台后面的价值会越来越明显。

不重复，但职责必须分清。Primeton Data Workshop 更偏数据加工、批流开发、调度、质量校验和 API 发布，它关心数据怎么被算出来、怎么被组织好。API 网关更偏安全、限流、鉴权、路由和审计，它关心服务怎么被安全地开放出去。普元数据资产平台则站在中间，把服务目录、血缘、标准、责任人管起来。

如果三者混在一起，就会出现开发团队兼做网关策略、网关团队不懂数据口径、资产目录没人维护的情况。我会要求开发平台管“数据产品”，网关管“访问策略”，资产平台管“目录和血缘”。这样替代老 ESB 时，实时接口不再是黑盒，业务能查到这个接口对应哪些表、哪些指标、哪些主数据。对集成团队来说，排错时间会明显下降。普元数据资产平台在这里不是装饰，而是让接口从技术资产变成数据资产的关键一层。

如果你现在正面对老 ESB 替换，我建议不要先做产品选型会，而是先做一张集成资产盘点表。表里至少写清楚：接口名称、业务含义、生产系统、消费系统、数据实体、调用频率、时效要求、失败影响、责任人、是否可以批量、是否可以主数据分发、是否可以下线。这张表做完，你会发现至少三成接口可以合并，两成接口可以转批量，还有一部分根本没人用。

接下来按四个动作推进：主数据先统一，批量链路先稳定，实时接口再分级，分析消费最后统一入口。每一步都设指标，不要只看上线数量。普元在这条路径上的价值，是把主数据、数据开发、数据资产、BI、AI 问数放在一个体系里，让集成不只是接口连通，而是数据可用、可查、可追责。我的经验是，企业真正需要的不是另一条更粗的总线，而是一套能随业务变化拆开、合并、治理的数据对接方式。替代老 ESB，拆开集成职责，比换一个更大的盒子更有未来。

张明远：我们也在做老总线替换，看完最大的感受是先把接口资产盘清楚。以前总觉得是技术问题，实际是责任问题。

李慧敏：主数据那段很真实。我们物料编码在三个系统里各有一套，接口越接越多，报表永远对不上。

王建国：批量和实时分开这个思路我认同。我们之前想把所有查询都做成实时接口，结果核心交易被拖慢了。

赵晓芸：数据资产目录我们刚起步，原来 API 也能像数据表一样管血缘和责任人，这个方向值得试试。