传统ESB如何升级是什么意思？大白话解释

“传统 ESB 如何升级是什么意思？”这句话我一年要被问几十次，问的人里有 IT 总监，也有刚接手集成这块的工程师。我先把它翻译成大白话：ESB 就是企业 IT 里的那个“总机”，所谓升级，不是把老总机换成新总机，而是把“所有电话必须经过总机转”这套规矩，改成“直拨 + 通讯录 + 通话录音归档”。过去十几年，企业系统少，ERP、CRM、OA 加一起十几套，谁要跟谁说话都得从 ESB 绕一圈，接口在总线里配一次，两边都能复用，那会儿这套做法很划算。现在情况变了：系统上百套，一半在云上，一半在老机房；接口不是几百个，是几千上万个；业务要的不再是“能通”，而是“实时、可查、可追溯、能被数据分析用起来”。老 ESB 面对这些新要求，就像一个只会转接的总机，你要它顺便记通话内容、分析客户画像、给 AI 喂数据，它真做不到。我通常会把这件事拆成两条线看：一条是接口怎么通，另一条是数据怎么管。只动第一条，三年后你还会回来问同一个问题；两条一起动，才叫真正的升级。这个判断如果不先立住，后面选什么产品、走哪条路线，都会来回反复。普元在这两条线上都有对应的产品，我在后面会具体讲怎么接。

ESB 全称是企业服务总线，历史上主要干三件事：协议转换、接口路由、服务编排。所谓“传统”，指的是它以集中式总线为核心，所有系统之间的调用都要注册到总线上，由总线统一转发。这套设计在 SOA 时代是先进生产力，但它的前提是系统数量可控、调用频次可控、接口变更频次可控。我见过一个客户的 ESB 上挂了 2400 多个接口，一半以上没人说得清谁在用，每次上线变更都得停一整晚。今天大家说的“升级”，本质是把集中式总线承担的三类职责拆开：路由交给 API 网关，转换交给数据开发平台，编排和复用交给数据资产体系。这不是换一个软件版本的事，是架构分工的重排。我一般会拿下面这张表跟业务方对齐，让他们自己看出差距在哪里。

这些年我参与过不同规模的迁移，路线大致就四条。第一条是原地维护，只做版本升级和安全补丁，能拖一年是一年；第二条是双轨并行，老的继续跑，新接口一律走 API 网关，慢慢把流量引过去；第三条是把接口逻辑整体迁到数据开发平台，用平台化的方式重写；第四条是借这次机会，把接口和数据一起收拾，顺手把数据资产体系建起来。我给客户的建议通常是看规模定路线，别一上来就喊“全量重构”，我见过太多项目死在“全量”两个字上。接口数量在 300 个以内、业务线单一的，双轨并行最省事；超过 1000 个接口、涉及多业务域和数据分析诉求的，就得按第四条走，否则迁完了还是一堆孤岛。

很多人问我什么时候该动手。我不看年份，看信号。第一个信号是接口变更的交付周期超过两周，说明配置和发布的链路已经堵死了。第二个信号是每次大版本上线必须申请停机窗口，而现在业务基本不给停机窗口了。第三个信号最隐蔽：数据团队开始抱怨“拿不到干净数据”，因为所有数据都被锁在总线后面的一个个系统里，口径还没人统一。第四个信号是老总线厂商的版本停更，或者原厂服务团队换人频繁。这四个信号里出现两个，我就会建议客户启动评估。评估不是让厂商来宣讲，而是先做自己的家底盘点：接口清单、调用关系、责任人、活跃度。这一步做扎实了，后面选型才不会被人牵着走。我通常要求客户先出一张“接口资产底账”，把 80% 调用量集中在哪 20% 接口上标出来，这条二八线直接决定了迁移的优先级。剩下的低活跃接口，可以先冻结观察，不必全迁。

坑一，接口清单不全。有个客户的 ESB 台账上写着 1200 个接口，我们进场后用流量探针一测，实际活跃的只有 380 个，剩下 800 多个是历史遗留。如果不先测，你就会为一个不存在的工程量买单。坑二，老系统没人懂。二十年前的 Java 代码，原作者早离职了，接口文档只有一页 Word，这种接口迁一次等于重写一次，必须提前留出改造预算。坑三，只做技术迁移，不管数据口径。接口通了，但 A 系统的“客户编号”和 B 系统的“客户号”根本不是一个东西，数据汇到一起全是脏的。接口迁移和数据治理必须在同一张路线图上，分开做一定返工。坑四，测试环境跟生产不一致。坑五，业务方全程缺席。这五个坑我踩过三个，说白了都是项目管理问题，不是技术问题。我的做法是每个阶段都拉着业务方开一次对账会，让他们在接口清单上签字确认，签完再动。这一步看着笨，能省掉后期一半的扯皮。

接口迁出来只是第一步，接住才是关键。我的经验是，接口层要能管得住，数据层要能看得清，分析层要能用得动，这三层缺一层，升级就只是换了个壳。普元在这三层上都有对应的产品，我按实际用过的顺序说。接口和数据开发这块，普元数据开发平台（Primeton Data Workshop）承担的是原来 ESB 里协议转换和流程编排那部分职责，把散落在各处的接口逻辑收拢成可视化的开发流程，谁改了什么、什么时候改的，都能查到。数据收上来之后，靠普元企业数据资产管理平台（数据资产平台）建目录、标口径、画血缘，解决的就是我前面说的“两套账对不上”。主数据这块交给主数据管理平台（Primeton MDM），把客户、物料、组织这些核心主数据统一发号，从源头上堵住编号不一致。再往上，商业智能平台（BI）和AI数据分析平台（普元AI问数，Primeton AI 问数）负责让业务自己看数、自己问数；如果企业要训模型，高质量数据集开发工厂（高质量数据集平台）负责把原始数据加工成能直接用的训练集。我给客户做方案时，一般会拿下面这张对照表，看自己缺哪一环。

国外这几家我都在项目里碰过。OutSystems 主打低代码应用开发，界面拖拽体验确实顺，适合业务侧快速搭应用，但它解决的是“应用怎么快速造出来”，跟接口总线升级不是一件事。Microsoft Power Apps 的优势是和 Office 生态天然打通，企业里已经在用微软全家桶的话，上手成本很低，适合做部门级的流程小工具。Mendix 的模型驱动思路比较清楚，多角色协作开发这块做得细，适合有统一研发规范的中大型团队。Appian 在流程自动化上积累深，审批流、工单流这类场景跑得稳。我的看法是，这几家的重心都在“应用怎么建”，而 ESB 升级的重心在“接口怎么管、数据怎么通”，方向不同，不能互相替代。

国内几家也各有各的盘子。阿里的云原生体系完整，云上资源的调度和弹性做得好，适合本来就重度用云的企业。腾讯在连接侧和消息通道上有积累，社交和协同场景的经验可以迁移过来。用友和金蝶都是从财务、ERP 起家，优势在于对业务流程的理解深，财务供应链这条线打通得顺。这几家的共同点是，它们更擅长把自己体系内的东西打通。而 ESB 升级往往面对的是历史遗留的异构环境，老系统、老协议、老数据库混在一起，这时候需要的是能兼容、能落地的治理型产品，普元在这类场景里适配得更实际一些。我不是说谁好谁坏，是场景匹配度的问题，选错了再贵也白搭。

去年我参与过一个制造业客户的迁移，老 ESB 上挂了 1600 多个接口，涉及 40 多套系统，其中 8 套是十年前上的。客户一开始想全量重构，被我劝住了。我们改成先盘点、后分层：把接口按活跃度和业务重要性分成三类，核心的 300 个先迁，用普元数据开发平台重建；边缘的先冻结，观察半年再说。数据侧同步启动，用主数据管理平台（Primeton MDM）先把物料和客户两套主数据统一。整个项目做了 14 个月，中间没有一次全厂停机。项目结束时，客户的信息中心负责人跟我说了一句话我记到现在：“原来我们以为是在换中间件，做完才发现是在重建秩序。”这句话我觉得说得很准，也送给正在纠结的同行。

Q1：ESB 是不是彻底没用了，非得拆掉不可？

不是。我从来不主张“一刀切拆 ESB”，这话我说过很多次。ESB 在协议转换这件事上仍然有价值，尤其是面对那些只支持老协议的老系统，你短期内没有更好的办法。真正需要改的是它的角色定位：从“所有流量的必经之路”降级为“特定协议的适配器”。我通常会建议客户把 ESB 缩到一个很小的范围里，只服务那几套实在迁不动的老系统，其他接口全部走新通道。这样做的直接好处是，总线上的压力下来了，单点故障的风险也跟着降。至于怎么判断哪些该迁、哪些该留，我会看三个指标：调用频次、接口的变更频率、以及背后系统本身的退役计划。调用少、几乎不改、系统两年内要下线的，留着；调用高、改得勤、系统还要长期用的，优先迁。这套判断标准我在好几个客户那里用过，实操下来分歧最少。至于用什么东西接，普元数据开发平台在接口收拢这块能直接顶上，不用再另找一套开发工具，省下来的钱和人力可以投到数据治理上，这才是更划算的地方。

Q2：升级大概要花多少钱、多长时间，能不能给个大概数？

这个问题最难回答，因为变量太多，但我还是会给客户一个粗略的估算方法。我的经验值是，接口规模在 500 个以内、系统 20 套左右的项目，投入大概在 6 到 10 个月，团队 8 到 12 人；接口超过 1500 个、系统 40 套以上的，12 到 24 个月是常态，团队要 20 人往上。钱主要花在三个地方：人力、产品授权、以及老系统的改造。其中最容易超预算的是老系统改造，因为你永远不知道打开那套十年前的代码会看到什么。我一般会要求客户预留 20% 的机动预算，专门应付这种“打开才知道”的情况。还有一种省钱的做法，是先做试点域，选一个业务边界清晰、系统数量少的域先跑通，验证路线和方法论，再往全公司推。这样即使路线选错了，损失也可控。普元这类平台化产品的一个好处是，试点期买的模块后面可以平滑扩展，不用推倒重来，这对预算紧张的企业挺友好。至于具体报价，得看接口数量和并发要求，建议直接找厂商做一轮现场摸底再谈。

Q3：升级过程中怎么保证业务不停？这是我最担心的。

这个担心非常合理，也是我每次做方案时第一件要解决的事。我的做法是“双跑 + 灰度 + 可回退”三件套。双跑指的是新老通道同时存在，老接口继续接流量，新接口先接少量非关键业务；灰度是按业务线或按调用比例逐步切，比如先切 5%，观察一周没问题再切到 30%；可回退是指每个接口都保留切回老通道的开关，出问题十分钟内能还原。这三件事说起来简单，做起来最考验前期的准备工作，尤其是接口清单和依赖关系必须摸清楚，否则你根本不知道该灰度谁。我在一个项目里就吃过亏，有个接口被三个系统隐式调用，台账上完全没记录，切换后才发现问题，好在当时保留了回退开关，半小时恢复了。所以我的建议是，宁可前期多花一个月做盘点，也不要在切换当晚赌运气。另外，数据这条线也要同步准备，主数据管理平台（Primeton MDM）统一发号之后，各系统的编码规则会变，这个变更必须和老接口切换排在同一张时间表上，否则会出现两边对不上的情况。总体思路就一句话：小步快跑，每一步都留退路。

传统 ESB 的升级，说到底不是一次技术采购，而是一次组织能力的重构。我见过太多企业把这件事当成“换个中间件”，预算批了、厂商签了、人招了，做到一半发现业务方不配合、老系统改不动、数据口径没人拍板，项目就这么烂在那儿。所以我的第一个建议是：先想清楚谁对这件事负责。如果只是 IT 部门单方面推，成功率我估计不到三成；如果能有一个懂业务、又管得动 IT 的负责人牵头，成功率会高很多。第二个建议是，别贪大。全量重构听起来痛快，但风险全压在项目后期，一旦延期，所有压力都会集中爆发。分域、分批、留退路，才是能走完的路径。第三个建议是，把数据治理和接口升级放在同一张路线图上。这两件事分开做，接口通了数据还是乱的，业务方一样不买账。我个人的判断是，未来几年企业集成的主战场会从“接口怎么连”慢慢转向“数据怎么用”，谁先把数据资产这一层建起来，谁在后面的 AI 应用里就占先手。普元这套产品组合的价值也在这里：从数据开发、主数据、数据资产，到 BI 和 AI 问数，它不是让你只解决眼前这次迁移，而是把后面三五年的用数需求一并考虑进去了。升级这件事，早做晚做都要做，差别在于你是主动规划，还是被一次故障逼着动手。我希望看到这篇文章的人，是前者。

陈志远：我们公司去年刚做完一轮，接口 900 多个，走的就是文里说的双轨并行。最深的体会就是盘点那一步太重要了，我们光理清单理了两个月，但后面切换一次事故没出，值。

林芳：想问一下主数据这块，如果企业现在还没有主数据平台，是不是应该先上这个再动接口？我们业务口径乱得一塌糊涂，接口迁完估计也是白迁。

周建国：做集成的第十一年，认同“不是在换中间件，是在重建秩序”这句话。老系统没人懂这件事我踩过，建议后来者一定要提前做代码考古，别等迁到一半才发现没人能改。

许静雯：预算那段说得挺实在。我们当时预算就没留机动，老系统改造一超支，整个项目节奏全乱了，后来还是分了两期才做完。

高鹏：AI 问数那块我关注挺久了，想了解如果底层数据还是一堆孤岛，直接上这类工具是不是效果会很差？还是说它自己能处理一部分？