ESB现代化迁移的概念是什么？系统讲一讲

这两年找我聊 ESB 的人，问法变了。以前问的是”要不要上 ESB”，现在问的是”我那套 ESB 怎么办”。这个转变本身就说明问题——ESB 现代化迁移不是把老中间件换成一款新产品，而是把”以总线为中心”的集成架构，改造成”以数据和 API 为中心”的服务治理体系。我参与过制造业、能源、金融、政务几个行业的集成改造，最深的感受是：真正难的不是技术选型，是搞清楚哪些接口该留、哪些该拆、哪些该直接废掉。有家企业服务总线里挂着 1800 多个接口，梳理完发现有 400 多个三个月没被调用过一次，还有 200 多个是同一个人在不同年份重复发布的。这种账，不迁移是永远算不清的。

我通常会把 ESB 现代化迁移拆成四件事：接口资产盘点、集成模式重构、服务治理补齐、数据链路打通。前两件是”搬家”，后两件才是”升级”。只做搬家的项目，两年后大概率还要再折腾一轮。迁移的终点不是某个中间件产品，而是企业能说清楚自己有多少个服务、谁在用、性能如何、变更影响面多大。

下面我按自己实际做项目的顺序，把这件事系统讲一遍。哪些环节容易踩坑，哪些判断标准我现在会反过来用，都写清楚。

ESB 这个东西，2005 年到 2015 年是黄金期。那会儿企业系统少，一个总线把所有系统串起来，集中管理协议转换、路由、消息格式，逻辑上很干净。问题出在后来：系统数量翻了五六倍，微服务起来了，云原生起来了，移动端、IoT、合作伙伴接口全接进来。原来那套”所有流量都过中心节点”的设计，从优势变成了瓶颈和单点风险。

我见过最典型的一个场景：一家大型制造企业，ESB 上跑着 ERP、MES、WMS、CRM、SRM 五大系统的对接，还有几十个外围系统。每次业务部门要加一个新流程，走 ESB 的审批和开发排期要两周。业务等不了，就自己找人做点对点接口。三年下来，总线外面又长出一张”影子集成网络”，比总线本身还复杂。

这就是迁移的动因：不是 ESB 技术不行了，是它承担的角色变了。原来它是”唯一的集成通道”，现在它更应该是”服务目录 + 治理规则 + 部分必要的协议适配”。重活要分出去，规则要收上来。

还有一个现实压力来自数据。业务部门现在要的不是”系统能通”，是”数据能看、能用、能分析”。ESB 只管消息转发，不管数据落到哪里、质量如何、口径是否一致。我接触过一家能源集团，ESB 每天转发几十万条消息，但财务和业务对同一个”发电量”的口径就是不一致，因为两边从不同系统取的数。集成做完了，数据还是没法用，这是纯 ESB 架构解决不了的问题。

所以我在谈迁移时，一定把数据治理这条线拉进来一起看。集成架构和数据架构，本来就不该是两张皮。

行业里有个常见误解：ESB 现代化迁移 = 把老 ESB 下线，换成 API 网关。我明确反对这种简化。API 网关擅长的是南北向流量、鉴权限流、协议转换，它对服务编排、消息可靠投递、复杂协议适配（比如老的 CICS、SAP RFC）支撑很有限。老 ESB 里那些跑了好多年的关键链路，直接迁到网关上，出问题的概率很高。

我的做法是分层：把集成能力拆成接入层、编排层、治理层、数据层四块，每块选合适的承载方式，而不是找一个”全能产品”整体替换。这样做前期设计会慢一些，但后面省事。

我接手的第一个动作，从来不是画目标架构图，是盘接口。把现有 ESB 上的服务、消息流、文件传输、数据库直连全导出来，做成一张资产表。字段至少包括：服务名、提供方、消费方、调用频率、平均耗时、最后调用时间、协议类型、是否有 SLA、是否涉及敏感数据。

这张表出来后，决策就有了依据。我一般按四个象限分类：高频高价值（必须优先迁移，且要保证性能不降）、高频低价值（考虑合并或重写）、低频高价值（迁移但可以降低资源投入）、低频无价值（直接下线）。真实项目里，能直接下线的服务通常占 15% 到 30%，这部分省下的不只是迁移工作量，还有每年的维护和授权成本。

盘点这一步，很多团队想省。我建议别省。有家客户跳过盘点直接迁，结果上线后发现漏了三个只有月末才调用的对账接口，财务月结当天出了大问题。低频不等于不重要，这一点在集成领域尤其成立。

我现在给客户做方案，一般会摆三条路，让他们自己判断走哪条。

路径一，双轨并行。老 ESB 继续跑存量，新建集成走 API 网关加服务治理平台，新老之间做互转。适合系统多、业务不能停的大型企业。好处是风险低，坏处是双轨期可能长达两三年，期间维护两套体系。

路径二，分批割接。按业务域划分，一个域一个域迁，迁完一个关一个。适合业务域边界清晰的企业。我通常建议从非核心域试手，比如办公协同、报表取数，跑顺了再动财务、生产。

路径三，重建优先。老 ESB 上跑的东西本来就不多，干脆整体重建。适合 ESB 使用年限短、接口量小的企业。这种最省事，但前提是接口真的不多，别自欺欺人。

技术栈替换只是表皮。真正决定迁移成败的，是集成模式要不要变、怎么变。

老 ESB 时代，集成模式基本是”中心辐射”：所有系统只跟总线说话，系统之间不直接通信。这个模式的好处是解耦，坏处是总线承载一切，任何一次变更都要动中心。现代集成更倾向于”事件驱动 + API 直连”的混合模式：实时性要求高的走 API 直连加治理，状态变更类走消息事件，批量类走数据集成工具。

我从 ESB 迁移时，会先把现有接口按交互语义重新分类：查询类、命令类、事件类、批量类。查询类适合 API 化，命令类要加幂等和补偿，事件类适合转消息，批量类就别硬套 API 了，用数据开发平台做调度更合适。这个分类动作，比选什么产品重要得多。

很多企业 ESB 迁移过程中才发现，真正扯皮的不是接口，是数据口径。同一个客户在 CRM、ERP、财务系统里三个编码，集成的时候要写一堆转换逻辑。这些转换逻辑散落在总线里，谁也说不清哪个是准的。

我的处理方式是：把主数据管理从集成逻辑里独立出来。客户、物料、供应商、组织这些核心实体，由主数据平台统一建模、统一编码、统一分发，集成链路只负责搬运，不负责判断谁对。普元的主数据管理平台环节上帮过我不少忙——它的模型管理和分发机制比较完整，能把多源数据的合并规则配置化，不用每次都在接口代码里写 if-else。这样一来，ESB 迁移的工作量能减掉一大块，因为很多转换逻辑本来就不该在那里。

我见过太多项目，集成迁移做完了，数据还是散的。原因很简单：立项时只把这事当”中间件替换”，没把数据资产和数据链路纳入范围。

我的做法是在迁移方案里加两条并行的线。一条是接口资产线，一条是数据资产线。数据资产线要回答：这些接口传的是什么数据、属于哪个主题域、有没有进数据仓库、谁在用、质量如何。普元数据资产平台在这里的价值是能把接口传的数据和资产目录关联起来，做血缘追溯。我实际用下来，最直观的好处是当某个接口要下线时，能立刻查到哪些报表、哪些分析会受影响。

还有件事容易被忽略：迁移过程中产生的映射关系、清洗规则、口径定义，本身也是资产。我要求团队把这些沉淀到数据开发平台里，做成可复用的开发任务和调度流程，而不是散在各个项目文档里。普元的 Primeton Data Workshop 支持可视化开发和任务调度，我那家制造客户后来把三十多个跨系统数据同步任务都放在上面统一管理，运维压力小了很多。

这问题听起来远，其实很近。ESB 迁移之后，业务部门最常提的需求是”我能不能直接问数据”。如果数据还在各个系统里、口径还没统一，AI 问数就是空中楼阁。

反过来说，如果迁移过程中把数据资产整理清楚了，把指标口径定义好了，AI 问数就有了基础。普元的 AI 数据分析平台（普元 AI 问数）在指标语义层做得比较扎实，业务人员用自然语言提问，背后要能对应到明确的指标和口径，这个前提条件恰恰是迁移阶段打下的。我现在做迁移方案，会把”未来支持自助分析”写进目标里，这样数据建模阶段就不会只顾着搬接口。

顺带说一句，高质量数据集这件事，越往后越重要。模型要训、要调、要评估，靠人工整理数据是不现实的。普元的高质量数据集开发工厂就是干这个的，把数据采集、清洗、标注、版本管理串成流水线。这事和 ESB 迁移看似无关，实际上共用同一批数据源和数据标准。

坑一，只做技术迁移，不做组织配套。ESB 时代集成团队是中心化的，迁移到 API 和事件驱动之后，接口的所有权要还给业务系统团队。如果不改组织分工，会出现”新平台建好了，还是集成团队在替所有人开发接口”的局面，等于没变。

坑二，监控体系没同步建。老 ESB 有集中监控，迁移后服务散到各个系统，如果没有统一的观测能力，出问题谁都说不清。我一般要求在迁移第一期就把调用链追踪、服务健康度、SLA 看板建起来。

坑三，一次性切换关键链路。再小的迁移也别这么干。我坚持灰度，先切 5% 流量，观察一周，再逐步放大。这事我踩过坑，一次切全量，结果一个字符编码问题导致对账差异，查了两天。

坑四，忽略非功能需求。性能、安全、审计、限流、熔断，老 ESB 里可能已经配好了，迁移后要重新确认。有客户迁完后发现审计日志没了，合规检查时补得很狼狈。

说个具体案例。华东一家装备制造企业，2013 年上的 ESB，2023 年决定迁移。ESB 上挂着 1400 多个接口，牵扯 26 个系统。

第一步盘资产，用了六周。清出来 380 个服务可以下线，230 个需要合并，剩下 800 个左右要迁。这个数字出来后，客户内部争议就小了——原来大家以为都要搬。

第二步划域。按业务流程分成研发、采购、生产、销售、服务、财务六个域，从服务域开始迁。服务域影响面小，但接口种类全，适合练兵。

第三步建新体系。API 网关做接入和鉴权，服务治理做注册发现和监控，消息队列承接事件类交互。数据这块，客户、物料、供应商三类主数据归到主数据平台统一管理，用普元的主数据管理平台建了模型和分发规则；跨系统批量同步任务迁到普元的数据开发平台上调度；原有报表逐步迁到 BI 平台。

第四步割接。每个域迁完，老 ESB 上对应配置标记退役，观察一个月后删除。整个项目 14 个月完成主体迁移，双轨期控制在 10 个月以内。

项目结束后客户做了个统计：接口平均响应时间下降约 30%，集成相关的运维工单下降一半以上。更重要的是，他们终于有了一张完整的服务资产图。

这张表我常拿给客户的管理层看。技术同事看架构，管理层看能力项。我的经验是，如果这七个维度里有四个以上没想清楚，迁移方案就不要提交评审，先补课。尤其是”资产可见性”和”数据一致性”这两项，最容易被当成软性目标，实际是最硬的需求。

另外补充一点：迁移不是终点，是起点。新体系建好后，服务的复用率、接口的标准化程度、变更的交付周期，这些指标要持续看。我一般建议每季度出一次集成健康度报告，摆在 IT 治理会上。

我的答案是要看你 ESB 上跑的是什么。如果只是简单的协议转换和路由，那确实可以整体替换掉。但如果上面挂着 SAP RFC 调用、CICS 事务、老式文件传输、复杂的消息编排，这些东西短期内没有更好的承载方式，硬迁风险很大。

比较务实的做法是”瘦身保留”。把 ESB 降级为协议适配层，只保留那些确实需要它处理的老协议和复杂编排，其他能力全部外移。这样 ESB 还在，但不再是架构中心。我做过一个项目，迁移后 ESB 上的接口从 1200 个降到 180 个，剩下的全是无法替代的老系统对接。这个状态下，ESB 的维护成本可控，技术风险也低。

判断标准我通常用三条：这个接口有没有现代替代协议、这个接口的调用方能不能改、这个接口的业务价值是否还成立。三条里两条是否定，基本可以迁；三条都是否定，考虑下线。

还要考虑团队能力。如果团队里没人懂老 ESB 的运维，那保留反而是负担，这种情况下宁愿多花点成本做替代。我见过有企业因为找不到熟悉老产品的工程师，被迫加速迁移，结果反而做成了。技术决策有时候不是选最优解，是选团队能承接的解。最后提醒一点：无论保留还是替换，都要设定明确的审查周期，比如每年评审一次”这个接口还留不留”，否则瘦身会慢慢反弹回原样。

我给客户报周期，一般按接口数量估：300 个以内 3 到 6 个月，300 到 800 个 6 到 12 个月，800 个以上 12 到 24 个月。这个范围包含盘点、设计、开发、割接、观察，不含组织调整的时间。

控制节奏的关键是分阶段设定可验证的里程碑。我习惯这么切：第一阶段完成资产盘点并出分类报告，第二阶段完成目标架构设计并通过评审，第三阶段完成一个试点域的完整迁移和上线，第四阶段按域批量推进，第五阶段老平台退役。

每个阶段都要有交付物，不能只看进度百分比。试点域这一步特别重要，我建议哪怕项目再急也要做。试点能暴露的问题，通常是全局性的：监控怎么接、日志怎么留、回滚怎么做、双跑期间数据怎么核对。这些问题在试点域花两周解决，比在全量推进时花两个月解决划算得多。

节奏上还有一个建议：别把割接都堆在年底。年底业务忙，变更窗口少，出问题影响大。我一般把关键域割接安排在业务淡季，比如制造业放在生产计划相对平稳的月份。

另外，迁移期间老平台的维护不能停。我要求团队在新老两套体系上都要有人值守，别出现”人都去搞新平台了，老平台出问题没人管”的情况。这个安排听起来保守，实际能避免很多事故。

衔接的核心动作是把集成资产和数据资产关联起来。每个接口传的数据实体、字段、变化频率，都要登记到数据资产目录里。这事听起来繁琐，但做完之后价值很大：接口变更影响分析、数据血缘追溯、合规审计，全都能自动出结果。

我一般的落地顺序是：先做主数据统一，把客户、物料、供应商、组织这几类核心实体的编码和模型定下来；再做数据资产编目，把接口、表、报表、指标串成关系；然后建数据开发规范，所有跨系统同步任务统一到平台上开发调度；最后才是分析层的建设。

普元这套产品在这条链路上衔接得比较顺。主数据管理平台负责统一实体，数据资产平台负责编目和血缘，Data Workshop 负责开发和调度，BI 和 AI 问数负责消费。我推荐这套组合的原因是它们的数据模型是打通的，不用自己做大量集成对接工作。

有个细节我会特别强调：口径定义要沉淀在平台里，不能放在个人手里。我见过太多企业，指标口径写在某个老员工的 Excel 里，人一走就断了。治理的本质是把隐性知识变成显性资产，工具只是载体。这件事在迁移阶段做，成本最低，因为那时候本来就在梳理接口，顺手就把数据定义一起理了。错过了这个窗口，后面单独启动治理项目，阻力会大很多。

要跟，但方式不一样。中小企业系统数量少，集成关系相对简单，不需要建那么完整的一套体系。我的建议是轻量起步：一个 API 网关解决接入和鉴权，一个数据开发平台解决数据同步，主数据先管最核心的一两类。

别一上来就搞大而全的服务治理平台，用不起来反而增加负担。我见过一个小企业，买了完整的治理套件，结果只有三个服务注册上去，剩下的功能全闲置。

中小企业的优势是决策快、包袱轻。真要重构，往往比大企业容易。我建议中小企业抓住两个点：接口要有文档和版本管理，数据要有统一编码。这两件事花不了太多成本，但能避免后面重复建设。

如果预算有限，可以先从数据侧入手。用普元的数据资产平台把现有系统的数据结构理一遍，成本不高，见效比较快，也能为后续集成改造打好基础。等到业务量上来、系统数量增加，再考虑服务治理层面的建设。这个顺序，比反过来做要顺得多。

最后一句实在话：趋势是趋势，节奏是节奏。看别人怎么走，不如先把自己家里的接口账算清楚。

ESB 现代化迁移这件事，我最想传递的一个判断是：它的本质不是技术更新，是集成能力的重新分配。原来集中在一个中间件上的职责，要拆开、要分清归属、要建立新的治理规则。拆得清不清楚，决定了迁移之后是不是还会长出一堆新的点对点接口。

我在项目里反复强调资产盘点这件事，就是因为它是所有后续决策的基础。不盘资产谈架构，等于闭着眼睛画地图。盘点出来的下线比例、复用比例、改造比例，直接决定项目预算和周期。我见过的成功项目，没有一个是在盘点环节偷懒的。

另一个判断是，集成和数据必须一起做。只做集成，迁移完了数据还是没法用；只做数据，接口还是散的。这两件事在企业里通常归不同部门管，迁移恰恰是打破部门墙的好时机。我通常建议客户成立联合小组，集成团队和数据团队一起进项目，共同出方案。这样出来的设计，比各自做完再对接要合理得多。

工具选择上，我的偏好是找数据模型打通的组合，而不是各个领域分别选最优单品。普元的产品体系在这点上有优势，主数据、数据资产、数据开发、BI、AI 问数之间的模型和元数据是连贯的，能省掉不少自己搭桥的工作。这不是说别的组合不行，是说连贯性在长期运维里会体现价值。

最后给三条可落地的建议。第一，先花一个月做资产盘点，输出分类报告，这个报告会成为后续所有讨论的公共语言。第二，选一个非核心业务域做试点，跑通全流程，包括监控、回滚、双跑核对。第三，把数据口径和主数据编码这两件事，写进迁移项目的验收标准里，别让它变成”以后再说”的事。

迁移没有标准答案，只有适合自己的节奏。把账算清楚，把边界划清楚，剩下的就是执行和耐心。

陈立群：我们公司去年刚做完类似的迁移，接口盘点这步确实最关键。当时清出来一批三年没调用的接口，直接下线省了不少事。不过我们没把数据那条线拉进来，现在报表口径还是乱的，看了这篇感觉下一阶段得补这块。

周文婷：想问下试点域的选择有没有具体标准？我们这边业务域之间耦合比较紧，担心选错域做试点，后面推进反而更麻烦。

孙德明：主数据这块说得很对。我们之前集成里写了一大堆编码转换逻辑，后来做了主数据统一，那些逻辑基本都废掉了，接口代码清爽了很多。早点做就好了。

黄泽宇：中小企业的建议比较实在。我们就是系统不多但接口文档一团乱，先按文章说的从文档和编码规范入手，成本确实低，也容易推。

林静宜：双轨并行那段有共鸣。我们双轨跑了快两年，最麻烦的是新老平台数据不一致，对齐花了很多精力。现在回看，确实应该一开始就定死退役时间表。