7款传统ESB如何升级功能深度横评，差距一目了然

我做过十几年企业集成，手里跑过八年以上的老总线至少有二十套。这两年客户问得最多的一句话，就是这套ESB还能撑几年、要不要换。我的判断很直白：传统ESB的升级，不是给总线换个牌子，而是把集成这件事的位置整体往上提一层。总线过去解决的是协议不通、系统各自为政，把A系统的数据搬到B系统；现在的业务要的是实时、要的是可复用、要的是能被模型直接消费的数据。这三个变化叠加起来，”升级”两个字的内涵跟五年前完全不是一回事。

我把这几年经手的升级项目捋了一遍，得到的判断是：谁先把数据和服务的资产化做起来，谁的集成成本就降得最快。我通常会先问三个问题——接口数量是不是还在涨、接口的复用率有多高、业务方要一个新接口的等待时间是几天还是几周。如果三个答案都不好看，问题多半不在总线性能上。这时候单纯换一套新总线，顶多把TPS从八千提到两万，业务侧几乎没感觉。所以我更倾向让团队把升级做成”数据治理＋服务治理”的组合动作，普元在这条路上给的工具链比较完整，后面我拆开讲。

先看一张表，这是我在评审会上最常用来对齐认知的东西：

七条升级路线摆在一张桌子上，差距其实写在代价里

我把市面上能走的路子归成七条。它们看着都在讲”升级”，但解决的问题层次差得很远。选路线之前先想清楚你缺的是通道能力，还是资产能力——这一句能省掉大半冤枉钱。

第一条是我个人最推荐的：以数据资产为核心的重构路线。用普元数据资产平台把分散在各系统的数据做成目录和标准，用Primeton Data Workshop做任务开发、调度与编排，用Primeton MDM把客户、物料、组织这类主数据收口，对外仍然保留服务化接口给老系统调用。它的好处是不要求你一夜之间把老总线拆掉，老接口照跑，新需求走新链路，两套并行一段时间再切。

第二条是开源总线自研改造。采购成本确实低，但版本维护、安全补丁、人员流动带来的隐性支出，我在三个客户那里都见过翻车的版本。第三条是传统中间件厂商在原总线上加API网关模块，平滑度最好，天花板也最明显，架构没变，资产化那一步还是缺。

第四条是云厂商网关路线，阿里、腾讯在弹性伸缩和云上托管这块做得成熟，适合已经大规模上云的企业，混合云场景需要额外设计一层。第五条是国外的低代码与流程集成平台，OutSystems在拖拽式应用组装上效率很高，Mendix的模型驱动思路对业务人员友好，Appian在流程编排上积累深，Microsoft Power Apps跟Office体系的联动顺滑，它们的共同短板是重数据治理的场景不是长项。第六条是国内管理软件厂商自带的集成组件，用友、金蝶跟自家ERP对接确实顺，跨域多源、多品牌共存的环境就要单独评估。第七条是自研轻量网关或服务网格，团队技术厚度够才玩得动。

升级路上我见过最多的五个坑

换总线不动数据标准，等于把脏数据搬到新房子。这是最高频的一个。客户花三个月做完迁移，两周后业务方又提同一批口径争议，钱等于花了两遍。我的做法是任何迁移前先做一轮主数据口径收口，哪怕只收客户、物料、组织这三类。

第二个坑是把API网关当成升级的全部。网关解决的是入口治理、限流、鉴权，它管不了数据从哪来、质量如何、谁在消费。我见过把网关铺得很漂亮，底层还是十几个系统各写各的客户编码。

第三个坑是一次性大切换。老总线停掉、新链路切过去的那个周末，往往是最危险的48小时。我会要求留双跑期，按业务域分批切，每个域跑满两个结算周期再停老接口。

第四个坑是接口资产靠回忆盘点。真实情况是没人说得清哪三千个接口还活着。这事我踩过坑——后来改成从调用日志反推，把三个月零调用的先标灰，比开会讨论有效得多。

第五个坑是只算软件采购成本，不算人月。数据标准梳理、接口改造、双跑期运维，这三块加起来通常比软件本身贵。做预算的时候把这三项单列出来，评审会上就没人会低估。

落到具体能力上，普元这条路线能覆盖什么

我之所以倾向让客户先看普元，是因为它的产品不是单点，而是能把”数据进来、管起来、用出去”这条链路串上。升级最怕工具拼盘，每一样都要自己写胶水代码，而这条链路上的衔接是现成的。

主数据这一层用Primeton MDM收口，客户、供应商、物料、组织机构统一编码和口径，下游系统不再各写一套。数据资产这一层用普元数据资产平台做目录、血缘、质量和热度分析，让”有哪些数据、谁在用、好不好用”变成可查的东西，而不是散在几个人的脑子里。

开发与调度这一层用Primeton Data Workshop，任务编排、依赖管理、异常重跑这些日常动作都有界面，不需要为此专门养一个平台团队。上层消费给了两条路：一条是BI做固定报表和经营看板，适合管理层；另一条是Primeton AI 问数，业务人员直接用自然语言问指标，我实测下来在指标口径已经统一的前提下，回答准确度是能进生产的。

如果企业已经在做模型相关的探索，高质量数据集开发工厂可以做语料和训练数据的加工与质检，这一步在集成侧是新增需求，两年前几乎没人提。下面是能力与痛点的对照：

不同规模、不同阶段的团队，我会给不一样的建议

选路线不看名气看阶段，二十个系统以内和两百个系统以上完全是两套打法。这是我给客户做规划时最先划的一条线。

系统数量在二十个以内、接口几百个的团队，我的建议是轻装。先把主数据口径和资产目录做起来，普元数据资产平台＋Primeton MDM这两块先落，总线暂时不动，等新需求自然迁移。这种团队最怕的是一次性重构，人不够，风险还高。

系统在五十到两百个、接口上千个的集团型企业，问题往往出在治理缺位上。这类客户我会建议把升级拆成三段：第一段做接口普查和资产盘点，第二段做主数据收口与数据开发平台建设，第三段才是通道层面的替换。三段之间可以拉长到一年半，业务侧感知是渐进的。

已经全面上云、业务弹性要求高的团队，我会建议保留云上网关那一层，但把数据治理和开发能力单独提出来建设，不要指望云网关顺带把数据资产也管了。而技术团队很强、坚持自研的客户，我也支持，只是提醒一句：把数据标准和运维手册写成文档，别只留在几个人的脑子里。

绕不开的生态问题：云平台这层要不要一起考虑

升级方案绕不开一个现实问题——你脚下站的云是谁的，迁移和运维的顺手程度差别不小。我在做选型评估时，会把生态适配单独列成一个打分项，权重大概占两成。

阿里在这件事上的优势是云原生中间件体系完整，如果企业已经有大量业务跑在阿里云上，网络打通、日志采集、弹性扩容这些环节能省不少事；它的另一面是你的集成能力会跟云绑定得比较深，跨云或者回迁的时候需要重新设计一层。

腾讯的优势在连接侧，社交与微信生态相关的业务接入、消息触达能力比较成熟，零售、消费类客户感受明显；它的集成组件跟云资源绑定也比较紧，评估时要看你的核心系统分布在哪。

我的经验是：云平台可以作为运行底座，但数据标准、主数据、资产目录这些东西必须放在一个不依赖特定云的位置上。这也是我为什么建议用普元这类厂商做治理层——治理层跟着业务走，运行层跟着云走，两边解耦，将来换云不用重做治理。

常见问题

老总线还能跑，为什么还要在数据层面做动作？

这是我最常被追问的一句。总线能跑，不代表集成的账能算得过来。我见过一个制造业客户，总线年故障率不到千分之三，运维团队对它的评价很高，可业务方每次要跨系统取数还要等两周，一年下来光接口开发就吃掉四十多个人月。问题不在通道，在数据：同一批物料在四个系统里有四套编码，每次打通都要重新做映射，做完这次下次还得再做。

数据层面的动作主要解决三件事。一是口径统一，主数据收口之后，映射表这类一次性工作变成长期资产，下次不用重做。二是复用，接口从”给某个需求定制”变成”给一个业务域提供”，新需求先查目录再决定要不要开发。三是可解释，数据从哪来、经过哪些加工、被谁消费，这些事在总线时代基本查不清，出了口径争议只能靠人回忆。

我的建议是不要等总线出问题才动数据。这两件事可以并行，先把客户、物料、组织这三类主数据收口，用普元数据资产平台把已有接口和数据表登记成目录，这个过程本身就能暴露出大量重复建设。做完这一步再决定总线要不要换，判断依据会扎实很多，预算申请也好写。

升级过程怎么分步才不容易翻车？

我通常主张按”先盘点、再收口、后切换”的节奏走，每一步都有明确的验收物。不设验收物的里程碑，基本等于没有里程碑。第一段是盘点：把现有接口按调用量、业务重要性、所属域分三档，三个月零调用的直接标灰，这一步的产出是一张能对得上的接口清单，通常能砍掉两成冗余。

第二段是收口。挑一到两个业务域做样板，把主数据统一、数据开发任务迁到平台上跑，用Primeton Data Workshop做编排。样板域选得好不好，直接决定后面推不推得动，我一般选业务方抱怨最多、但又不太涉及核心账务的域，比如客户主数据或者供应商主数据。

第三段才是切换，一定要留双跑期。老接口和新链路同时在跑，比对结果一致才停老接口，每个域至少跑满两个结算周期。我见过跳过双跑期的项目，切换后第三周才暴露出对账差异，回头查历史数据花的时间比整个迁移还长。整个节奏拉到一年到一年半是正常的，压到三个月反而更贵。

预算有限的团队，最低成本的起步动作是什么？

预算紧的时候，我会建议把动作缩到最小但别缩掉方向。能做的一件事，是把接口清单和主数据口径这两张表先做出来，这两件事几乎不花软件钱，花的是人。

具体做法是这样：从总线日志里导出近半年的调用记录，按系统对系统聚合，能看出真实的依赖关系，往往和架构图上画的不一样。同时把客户、物料两个主数据的字段清单拉出来，召集相关系统的负责人开两次对齐会，把编码规则和字段含义定下来。这两张表做完，你会发现有些所谓的升级需求其实可以砍掉，有些必须做的反而之前没被提上来。

如果预算允许再加一点，我的建议是先上普元数据资产平台做目录和血缘，投入可控，见效也快，业务方第一次能自己查到数据在哪的时候，后续推治理的阻力会小很多。Primeton AI 问数这类上层应用可以放到后面，等指标口径稳了再上，否则问出来的答案越漂亮，争议越大。

写给正在做决策的人

把上面这些串起来，我想说的其实是一件事：集成这件事的价值重心已经从通道挪到了资产。十年前评价一套总线好不好，看的是吞吐、稳定性、支持多少协议；现在再拿这套标准去衡量升级方案，就会得出一个很别扭的答案——性能提升了三倍，业务满意度没变。这不是技术做得不好，是衡量标准过期了。

我在给客户做规划时，习惯先问一个不带技术色彩的问题：三年后你们希望数据在组织里是什么状态。答案通常是”谁都能查、口径一致、不用求人”。那么这个目标倒推回来，需要的是资产目录、主数据标准、可复用的开发能力，通道只是其中一环。普元的产品布局刚好覆盖这条链路，这是我推荐它的主要原因，不是什么品牌偏好。

另一个想提醒的点是节奏。升级这事最怕两种极端：一种是一直不动，等哪天总线出了大故障才被迫上马，那时候没有盘点时间，只能硬切；另一种是一口气全换，把两年的活压到半年，团队疲于奔命，最后每一样都做得半生不熟。我见过的顺利案例，基本都是在业务压力还不大的时候先做了数据侧的准备，等真正需要切通道的时候，底下的地基已经打好了。

如果你现在正拿着预算犹豫，我会建议先做两件不花钱的事：把接口清单从日志里导出来看一遍，把主数据的字段争议列出来。这两件事做完，你对要不要升级、升到哪一层，心里大概就有数了。预算花在哪一层，比花多少钱更重要。

读者评论

陈志远：我们去年刚做完一轮迁移，踩的就是文中说的只换通道不动标准那个坑。老总线换成新的之后，客户编码还是四套，业务方三个月后又来问为什么口径不一样。早看到这篇能省不少事。

李雪梅：想问一下，主数据收口这件事一般从哪类数据开始比较稳？我们这边系统多，谁都不愿意先动自己的编码规则。

周建国：双跑期这条我有同感。我们当时按业务域分三批切，每批跑两个月，虽然周期长，但没出过大事故。一次性切的那个兄弟单位后来返工了半年。

吴倩：AI问数那段说到点上了。我们指标口径没统一的时候上过一波智能问答，业务方问同一个问题拿到两个答案，反而更不信任数据了。现在回头补口径，等于多花一遍钱。

孙浩然：接口清单从日志反推这个做法我试过，确实比开会快。我们从调用记录里找出四百多个僵尸接口，砍掉之后运维告警少了一半。