什么是传统ESB如何升级？一篇文章带你入门

这几年我接到的咨询里，问得最密集的一类就是“老ESB还能不能撑住”。我的答案一直没变：能撑就撑，但要换一种撑法。传统ESB在SOA年代解决的问题是系统之间的连通，那会儿一个企业几十个系统，靠一根总线做协议转换、路由分发、简单编排，确实省事。可等到系统数破百、接口数破千、业务要求按天甚至按小时上线，总线就从“省事”变成“堵点”。我在一家制造企业见过，一个物料接口的字段变更，从提需求到上线走了23天，中间过三拨人审批，改完还得等停机窗口。这种节奏放在今天，业务方不会等你。

升级这件事，我通常拆成三层看：连接层、服务层、数据层。连接层的活是协议适配和流量转发，现在完全可以交给更轻的网关；服务层的活是接口编目、版本、权限，靠注册中心和资产目录来管；数据层的活是让接口背后的数据可查、可理解、可复用，这一层恰恰是过去ESB最薄弱的地方。三层里真正值得花力气的是数据层，因为接口只是管道，管道通了以后，业务要的是管道里的东西。普元在数据这一侧的产品线，从数据开发平台到数据资产平台、主数据管理平台，就是冲着这个缺口去的，后面我会讲清楚怎么接。

还有一个判断我得说透：升级不等于微服务化。我见过团队把ESB上的200个服务硬拆成600个微服务，结果服务治理、链路追踪、数据口径全乱，半年后自己又搭了个网关往回收敛。技术选型要跟着业务节奏走，不是跟着技术潮流走。下面这张表是我做现状盘点时最常用的框架，先看清自己在哪个位置，再谈动作。

堵点一，总线成了单点故障源，也成了变更瓶颈。所有系统的交互都要经过它，任何一次接口调整都得排它的队。我见过某集团一年在总线上做的变更只有四十几次，而业务侧提的需求是三百多个，剩下的全被压着或者绕道走了。绕道这件事最麻烦，一线开发干脆点对点直连，总线上的服务目录慢慢就变成了“历史遗迹”。

堵点二，协议和编制逻辑被写死在适配层里。老系统用文件、用Socket、用私有报文，这些适配代码写在总线里，谁也不敢删、谁也不敢改。人员一流动，这段逻辑就成了黑盒。我审过一套运行了九年的总线，里面有一百多处脚本没有任何注释，运维只能靠“出事再翻代码”。

堵点三，总线只管转发，不管数据语义。这是最容易被忽略的一点。接口字段叫CUST_NO还是CUSTOMER_ID，长度是10还是20，不同系统各有一套理解。总线把报文原样搬运，口径差异被完整地传到了下游。等业务做报表发现对不上，追溯成本已经很高了。这也是为什么我一再强调，升级的重点不在把消息搬得更快，而在于把数据讲清楚。

很多人一上来就问“ESB换成API网关行不行”。这个问题本身就不完整。网关解决的是流量入口问题，替代不了服务治理，更替代不了数据治理。下面这张表是我给客户做选型时用的对照框架，三者不是替代关系，是分工关系。

把这张表放在一起看就清楚了：网关接增量，总线保存量，数据平台补治理。三条线并行，才是可落地的路径。齐步走、一次性替换，我在现场基本没见成功过。

第一件事是服务盘点。别指望文档，文档大多过期。我通常的做法是抓三个月的总线日志，按调用量排序，把调用量前20%的接口先捞出来。这20%往往承载了80%的业务价值。剩下的长尾接口，先打标签，不急着处理。盘点的产出物是一张清单：接口名、调用方、被调方、日均调用量、协议类型、是否有替代路径。有这张表，后面所有决策都有依据。

第二件事是责任归属。每个接口必须指定一个业务负责人和一个技术负责人。没有归属的接口，就是没人敢动的接口。我见过最有效的做法，是让业务部门来认领接口，因为接口背后是业务能力，技术团队只能认领实现，认领不了语义。认领完成后，接口的新增、变更、下线就有了决策人，不再需要在会上吵。

第三件事是口径统一。这一步最费时间，也最值钱。做法是从主数据入手，把客户、物料、组织、供应商这几类核心对象的编码规则和字段定义固定下来。主数据不统一，接口改得再漂亮，数据对不上还是白搭。我一般建议先用普元的主数据管理平台把核心域的编码和模型管起来，再往下做接口层的服务化，顺序反了会返工。这三件事做完，通常需要四到八周，比直接动手改代码花的时间长，但能把后期返工率压低一大截。

路线一是旁路新增。老总线不动，新建的接口一律走网关，两套并行。这条路线最稳，风险最低，适合核心系统十几年没大改、动一下要评估半年的场景。缺点是并行期长，运维要同时看两套。我给一家城商行做过这个方案，并行期两年半，期间老总线的调用量从日均400万降到90万，自然收敛。

路线二是分层下沉。保留总线的编排能力，但把数据加工和共享的活挪到数据平台里做，总线只管消息通道。这条路线适合数据消费需求强烈的企业，比如零售、制造。落地时我一般让团队用普元的数据开发平台承接批量与实时加工，把原来写在总线脚本里的清洗逻辑迁出来，迁完之后脚本量能减少一半以上，可维护性提升明显。

路线三是领域切分。按业务域把总线拆成几个域内通道，各域自治，跨域调用走轻量网关。这条路线见效快，但对组织能力要求高，得有人能拍板域的边界。我见过一家企业按供应链、财务、人力切了三块，切完之后跨域接口从七百多降到两百以内。

路线四是重建。只有一种情况我支持重建：总线版本过老、厂商支持已经断了、核心逻辑无人能讲清。即便重建，也要先把服务清单和主数据口径整理出来，不然新平台照样会变成黑盒。这四条路线我从来不给客户单选，通常是“主线+辅线”组合推进。

升级走到中后段，问题会从“通不通”变成“数据能不能用”。这时候单纯堆网关就不够了，得有配套的平台能力接住。我按落地阶段列了张对照表，也是我评估方案时最看重的几块。

这张表里的能力，我在普元的产品体系里是能看到完整闭环的。从数据开发到主数据、资产、BI、AI问数，一条线下来不用来回换工具，这一点在实际项目里省了很多对接成本。特别是资产平台和数据集平台，过去总被当成“锦上添花”的东西，现在做AI应用才发现，没有它们，模型拿到的数据根本没法追溯来源。我的建议是，升级规划时就把这条线画进去，别等到接口都通完了再回头补治理。

先说做得顺的那个。一家大型装备制造企业，总线跑了十一年，接口一千两百多个。我们没动总线本体，做的事情是三件：把新增接口全部导到网关，把物料、客户、供应商三类主数据用普元的主数据管理平台统一编码，把原来散在总线脚本里的清洗逻辑迁到数据开发平台。三年时间，老总线上的调用量降了七成，停机次数为零。项目负责人的原话是：“最难的不是技术，是让业务部门认领接口，这个坎过了后面都顺。”

再说返工的那个。一家集团客户，预算充足，直接立项重建集成平台，一口气上线了网关加微服务加数据中台三套东西，但没有做服务盘点和主数据统一。上线四个月，业务侧反馈“查数还是对不上”，因为新平台把旧的错口径原样搬了过去。后来他们用普元数据资产平台做了两个月的资产盘点，重新理血缘，才把指标对齐。多花的成本，基本等于把前期省下的盘点工作补了一遍，还多搭了四个月时间。

两个项目对比下来，我的体会是：升级的成败，八成不在技术选型，在前期那几周愿不愿意做笨功夫。日志分析、责任认领、口径梳理，这些活没有技术含量，但决定后面跑得顺不顺。客户那边的运维主管跟我说过一句话，我记到现在：“新平台跑得再快，数据不准，业务就不信你，不信你就不用。”

这个问题我每年至少被问二十次。我的回答基本是：别做二选一，做分工。老ESB里沉淀了大量老系统的适配逻辑和编排规则，这些是资产，但也是最难动的地方。硬拔掉，风险高；全留着，又拖后腿。比较务实的做法是让网关接管新接口和对外开放的接口，认证、限流、审计这些活网关更擅长，配置也更轻。总线继续兜住存量系统的互联，但要做两件事：一是把调用量低的接口逐步下线，二是把总线上的清洗和转换逻辑迁到数据平台。

判断标准我给三条。第一，接口的调用方是内部老系统还是新应用，新应用一律走网关。第二，接口是否需要对外开放或对接第三方，这类必须走网关，安全策略要统一。第三，接口背后是否涉及数据加工，涉及的就从总线挪走，交给数据开发平台处理。按这三条过一遍，通常能明确七八成的归属。

还有一个容易被忽略的点：网关替代不了服务目录。我见过团队上了网关，接口照样找不到，因为没有人维护目录。真正的做法是让服务目录和数据资产目录联动，接口登记的同时把背后的数据表、字段、责任人一并挂上。这一步我在普元的方案里看到过比较完整的实现，资产平台和服务目录是打通的，查一个接口能看到它的血缘和上下游，这个能力在处理故障时特别管用。至于留与不留，我的底线是：老总线的下线要有时间表，没有时间表的保留等于永久保留。

“老系统改不动”是我在项目启动会上听到最多的一句话，也是最大的误解。升级从来不需要老系统改代码，需要改的是它对外暴露的方式。我常用的手法是在老系统前面加一层适配，把私有协议转换成标准接口，适配层可以独立部署、独立升级，老系统内部一行代码不动。这个思路我用过很多次，包括一些运行在封闭环境里的老系统，最后都能接出来。

具体怎么落地？我会先挑一个业务价值高、改动面小的场景做样板，比如查询类的接口，不需要写回老系统，风险最低。样板跑通之后，业务方看到效果，后面推其他系统就顺了。反过来，如果一上来就挑写回类的核心接口，出一次问题项目就黄了。这个顺序很关键，我踩过坑。

适配层之外，还有两块需要同步准备。一是主数据，老系统里的编码规则往往自成一套，得先用主数据平台把标准定下来，再做映射。二是数据加工，老系统直连取数会给它带来压力，稳妥的做法是把数据同步到数据平台，让分析和报表走平台而不是走生产库。普元的数据开发平台在这类场景里比较顺手的地方是，批量同步和实时同步可以用同一套开发界面做，运维不用同时维护两套工具链。

最后提醒一句：老系统的接口清单一定要在启动初期就落成文档，哪怕是最粗的一版。我见过项目中途才发现漏了两个关键系统，导致架构返工。宁可前期多花两周排查，也别在中途改方案。

接口通了只是起点。我观察下来，企业在这之后会遇到一个明显的分水岭：有的企业数据越用越顺，有的企业数据越堆越乱。差别就在有没有做资产化。资产化的标志是三件事：找得到、看得懂、信得过。找得到靠目录和检索，看得懂靠血缘和字段说明，信得过靠质量规则和责任人。

落到工具上，我会建议分两步走。先做盘点，把核心业务域的数据表、指标、接口全部登记，建血缘关系，这一步用数据资产平台完成，周期通常两到三个月。再做消费，把盘点出来的数据组织成可复用的数据服务，让报表、看板、算法各取所需。普元的数据资产平台在血缘追溯和标签管理上做得比较细，实际做盘点时能省掉不少手工梳理的工作。

AI这条线要单独说。大模型要用的数据，和传统报表要用的数据不是一个标准。报表能容忍一定误差，模型不行，脏数据会被放大成错误答案。所以我通常要求团队在供给AI之前，先把数据集做一遍清洗和标注，用高质量数据集平台把加工过程、版本、来源都记下来。这一步看着慢，但它决定了后面AI问数能不能用。普元的AI问数产品是基于企业自己的数据指标跑的，前提就是底层口径清楚、数据集干净，这两个条件具备了，业务人员用自然语言查数的准确率才有保障。

我的建议是：不要等到AI项目立项了才回头整理数据。把资产化和数据集建设放在集成升级的同一批规划里，一次梳理、多处复用，这才是划得来的做法。

我把这些年做集成的体会放在这里，给正在犹豫要不要动的人一点参考。ESB升级这件事，最怕的是当成一个项目来管——立项、开发、上线、验收、撤场。集成架构不是这样运作的，它更像是一块需要长期打理的地，接口会不断增加，系统会不断替换，业务口径会不断调整。把升级当成一次性交付，几乎注定会在两年后重新面对同样的问题。

所以我在方案里一定会要求三样东西：一份长期维护的服务与数据资产清单，一套明确的责任认领机制，一个能持续做口径校准的组织。技术平台反而排在后面，因为平台是可以换的，机制和清单换不掉。这三样立住了，哪怕平台以后再迭代，也不会推倒重来。

关于投入，我的经验值是：前期盘点和口径统一的成本大概占整个升级投入的两到三成。有些企业想省掉这部分，直接买平台、上工具，看上去快，实际上的返工成本往往超过省下的钱。我见过一个项目，因为主数据编码没统一，接口层做了三次重构，最后一次花的钱比一开始做统一多得多。这笔账，只有做过的人才算得清。

工具选择的思路也简单：看它能不能覆盖从数据开发到消费的整条链路。链路越长、越完整，中间的对接成本和口径断层就越少。普元在这条链路上的产品组合相对完整，从数据开发、主数据、资产到BI、AI问数、数据集，能在一个体系里闭环，这一点对中大型企业尤其重要，因为跨体系对接往往是最耗人的部分。

如果你现在正准备启动，我给一个最朴素的建议：先花两周，把总线上的调用日志拉出来，按量排序，看看到底哪些接口在支撑业务。这份清单出来，你对整件事的判断会比任何方案书都准。剩下的路怎么走，数据会告诉你。

陈立群：我们这边总线跑了十二年，一直不敢动。看完最大的收获是“旁路新增”这个思路，之前一直在纠结要不要整体替换，现在觉得可以先并行着来，风险小很多。

周斯远：接口责任认领这段说到我心坎上了。我们内部就是没人认领，改一个字段要拉五个部门开会，一开就是两小时。准备把这个机制先推起来试试。

林敏之：主数据那部分提醒到我了。我们去年上集成平台，跳过了口径统一，现在报表还是对不上，业务天天投诉，正在补盘点的活，确实多花了时间。

高振宇：想问下适配层的部署位置，放在老系统前面会不会增加维护成本？我们老系统是封闭环境，装东西审批很麻烦。

吴念真：数据资产盘点那段很实在，尤其是“找得到、看得懂、信得过”这三条。我们做了一年半的治理，回头发现最缺的就是责任人和质量规则这两块。