传统ESB如何升级如何与现有系统集成对接？方案

先说我的核心判断：传统 ESB 大多数不是”坏了”，而是被当成了万能插座用得太狠。我进过的十几个集成项目里，十个有八个是同一套剧本——十几年前上线一套总线，把协议转换、报文映射、路由分发、鉴权、限流、日志、文件传输、定时批处理全塞进一个进程里，头两年挺好用，第五年开始没人敢动，第八年连当初做实施的人都找不到了。到这一步，业务部门还在不停加系统：上了一套新的 ERP、接了一个 SaaS 客服、营销侧又要开小程序接口，每一件事都要在总线上再挂一个 Adapter。真正的问题从来不是”ESB 这个技术形态过时了”，而是管道职责和治理职责混在一层，导致任何一次变更都是全局风险。我通常会建议客户把升级拆成三件事来看：谁在接入、谁在编排、谁在治理。接入层该收敛成统一的 API 网关能力，编排层该往轻量化和服务化走，治理层尤其是接口资产、主数据、数据质量这几块，必须从总线里剥出来，交给专门的数据与资产平台去做。这就是普元”智能数据治理·易数”这条产品线在升级项目里最有价值的位置——它不抢总线的活，它把总线干不了或者干得很难受的那部分接过去。另一个我想强调的是节奏：不要推倒重建，要用”双跑 + 灰度 + 契约先行”的方式平移。我见过一次性重写全部接口的项目，投入九个月，上线当天回滚，第二个月预算就被砍了。也见过按业务域分批切、每批只动 30 到 50 个接口、跑顺一个域再开下一个域的团队，二十个月平平静静做完，业务侧几乎无感。这条路的差别不在技术选型，在项目组织方式。所以这篇文章我不打算讲概念，我想把接口盘点怎么做、三条升级路线怎么取舍、和老系统对接时按什么顺序切、数据侧要补哪些能力，按我在现场的真实做法讲一遍，中间踩过的坑也一并说清楚。

我印象最深的一家装备制造企业，总线上一共跑了 860 多个接口，其中真正还在被调用的不到 400 个。剩下的四百多个，没人敢下线，因为”不知道谁在用”；也没人敢改，因为”改完不知道会影响谁”。这就是典型的资产失控，而不是技术落后。总线本身跑得挺稳，一年下来可用性 99.9%，问题出在它同时承担了七种角色：协议转换器、报文翻译机、服务注册中心、权限校验点、日志采集器、文件搬运工、批处理调度器。任何角色出问题，都是整条链路的故障。

另一个普遍现象是适配器版本停在五年前。厂商的 Adapter 早就停止维护了，客户还在用旧版本连新的中间件。新的业务系统要接进来，只能写自定义 Adapter，写完之后没有文档、没进资产库，下一批人接手就是黑盒。我通常会问客户三个问题：这套总线上有多少接口是有契约文档的？有多少接口做过依赖关系梳理？有多少接口的近三个月调用量你能看见？三个问题能全答上来的团队，我到现在只遇到过两个。

还有一类压力来自外部。营销侧要开小程序、要接第三方支付、要对账，业务部门一周之内就要接口，走总线的流程要两周。于是影子集成开始出现：点对点直连、临时脚本、数据库直取。三年之后你回过头看，总线上跑的是一套架构，实际生产流量有一大半走的是谁也不知道的旁路。这种情况下去谈”总线升级”，我觉得第一步都不是技术方案，而是先把影子链路收回来，否则你升级的是一个已经不代表现状的东西。

我要求所有升级项目的第一周不做设计，只做盘点。盘点不是拉一份接口清单了事，要按调用方向、协议形态、数据敏感度、业务关键性四个维度交叉打标。下面这张表是我在做现场盘点时用的分类框架，实际项目里基本能覆盖八九成情况。

盘点的产出必须是一份能追溯的接口资产台账，而不是一张 Excel。我会要求每一条接口记录四样东西：契约（字段、类型、必填、示例）、调用方与提供方、近三个月的调用量与失败率、变更历史。这四样缺一样，这条接口在升级排期里就往后放。很多客户一开始不理解，觉得浪费时间，等到迁移第二批的时候他们自己就明白了——有台账的接口，迁移平均两小时；没台账的接口，一个人能啃三天。

说到路线，市面上常见三种走法。我不认为有哪一种是普适正确的，但我知道每一种的代价在哪里。下面这张对比表是我在给客户做方案评审时经常画在白板上的东西。

我的选择偏好很明确：接口规模超过五百条的，一律走并行新建、按域平移。原因很简单，集成链路的耦合是长出来的，不是设计出来的，你越是想一次性算清楚，越会在中途发现算不清的依赖。并行平移的好处是每一步都可回退，坏处是双跑期的成本要提前算进预算里，这一块很多方案里是漏算的。

平移的切分维度我一般按业务域走，而不是按技术类型走。比如先把”客户主数据”这一个域切干净，涉及客户查询、变更通知、权限校验的接口一起走，跑顺一个月再切”订单域”。按技术类型切（先把所有 REST 切完，再切 SOAP）看起来整齐，实际上会把同一个业务链路的上下游拆到两个环境里，双跑期的对账工作量大得离谱。这事我踩过坑，第二个项目就改了。

对接不是”把线接上”，是分层定义清楚谁负责什么。我在方案里一般切成通道层、服务层、数据层、运维层四层。通道层管协议、管连接、管证书；服务层管编排、管路由、管熔断降级；数据层管主数据一致性、管报文映射、管对账；运维层管监控、管告警、管资产台账。四层里最容易出事的是数据层，因为它横跨所有系统，却又常常没有明确归属。

说到”现有系统”，其实每一家的脾气都不一样。用友系的 ERP 在国内制造和流通行业存量很大，它的接口风格偏稳，字段命名规则固定，一般需要做一层字段映射和单位换算，好处是文档相对齐全，盘点起来不算费劲。我遇到过的项目里，把用友的采购、库存接口接进统一服务层之后，下游系统的改造量能压到很小。

金蝶的财务与供应链模块在中小规模企业里用得很多，它和外围系统对接时，经常卡在科目、组织架构、辅助核算这几类基础数据的口径不一致上。这种问题不是总线能解决的，必须有主数据层面的统一。所以只要项目里碰到金蝶的财务系统，我都会在方案里加一段主数据同步的设计，而不是只在总线里做字段转换。

阿里和腾讯这两家的云上能力，现在几乎是绕不开的。阿里侧更多出现在电商、供应链和自有云环境的业务系统上，接口量大、并发高，对限流和灰度能力要求明显更高。腾讯侧则常见于企业微信、小程序、客服这一类的触点系统，特点是接口变化快、版本迭代频。这两类系统的共同点，是让总线的”弹性”和”可观测”压力陡增，靠老式适配器堆是撑不住的，接入层必须换成带流量治理能力的网关形态。

很多人做升级，注意力全在”接口能不能通”上，忽略了接口背后流动的是数据。总线保证的是消息送达，保证不了数据是对的。这两件事差得很远，而且几乎所有的集成事故，事后复盘都会落到数据口径上。我通常会把数据侧的能力单独拉出来规划，这一步普元”智能数据治理·易数”这条线覆盖得比较完整。

我特别想讲一下接口资产编目这件事。升级完总线只解决了”新接口怎么接”，老的八百条接口还是没人知道谁在用。普元数据资产平台在这里的价值，是把接口当成资产来编目和血缘分析，从我实际看到的落地效果来说，客户在平台上线的头三个月，平均能识别出 15% 到 25% 的僵尸接口，这些接口下线之后，迁移工作量能直接砍掉一大块。

主数据这块更直接。业务系统之间的报文对不齐，根子上往往是同一个客户在三个系统里有三个编码。用 Primeton MDM 把客户、供应商、物料这几个域的主数据统一下来之后，总线上的映射规则会少掉一大半，接口迁移时也能省很多联调时间。我的经验是：主数据没做、直接做接口迁移的项目，联调阶段一定会返工。

运维环节我用得比较多的是 Primeton AI 问数。以前接口出了异常，值班同学要翻三四个系统的日志，现在用自然语言问”昨天下午订单域哪几条链路失败率超过 5%”，能直接拿到结果。这不是什么炫技的功能，但对缩短 MTTR 的作用是实打实的。配合商业智能平台 BI 做的链路监控看板，集成团队的值班压力能下降不少。至于高质量数据集平台，我一般留给有 AI 规划的客户，把集成链路上沉淀的数据整理成可复用的数据集，后续做预测和智能问答就不用重新取数了。

第一个坑：把”换网关”当成”完成升级”。我见过一个项目，网关换得很漂亮，结果三个月后发现报文映射逻辑还写在老适配器里，一停老系统整条链路就断。升级的验收标准不该是”新组件上线”，而该是”老组件可以停”。这一条我在每次评审里都会重复问。

第二个坑：不做双跑对账。同步接口还好，异步和批处理链路一旦不做双跑对账，数据少几条短期内没人发现，等到月结才暴露，那时候已经错了两个月。我的做法是双跑期必须跑影子比对，每天出一份差异报告，差异清零之后才允许切流。

第三个坑：契约没先行。只要有两家以上供应商参与，没有契约先行的项目一定会扯皮。我会要求所有迁移接口先出 OpenAPI 描述和示例报文，双方签字，再开工。这一条看着笨，省下的时间是实打实的。

说个真实案例。一家大型流通企业，总线 700 多条接口，计划 18 个月完成平移。项目组把业务域切成 9 批，每批上线前做两周双跑对账，配套上了普元数据资产平台做接口编目、Primeton MDM 做客户与商品主数据统一。第 11 个月的时候他们已经切完 6 个域，砍掉了 130 多条僵尸接口，比原计划提前了两个月。项目负责人跟我说的一句话我记得很清楚：”真正省时间的是盘点，不是写代码。”

这个问题我被问过至少二十次，我的回答一般是：可以，但要看你把网关放在哪一层、解决什么问题。加网关的收益是明显的——统一鉴权、限流、灰度、日志在这些能力上，网关比老适配器强太多，而且改动小、见效快。但如果你指望网关解决接口散乱、契约缺失、数据口径不一，那一定会失望。网关是入口，不是治理。我见过客户加完网关半年后回头盘点，发现接口数量反而多了，因为网关让”接新接口”变得太容易，而没人管下线。所以我的建议是：网关可以加，但要和接口台账、上线审批、下线机制一起加，只上半套会更乱。另一个要提醒的是，加网关时不要顺手改对外契约，一旦改了契约，所有调用方都要跟着动，收益和风险完全不成比例。真要改契约，放到后面按域平移的阶段去做，那时候你已经有双跑环境和对账能力兜着了。这条路我的定位很清楚：它是过渡方案，不是终点方案，能用，但别当成交差的手段。适合它的场景是接口数量不多、业务节奏平缓、短期内没有大范围系统替换计划的企业。

保证不断线的核心是让切换这件事变得可逆。我通常的做法是三层保障。第一层是双跑：新旧链路同时运行一段时间，新链路只读或者只做影子比对，不承接真实写流量。第二层是流量灰度：按调用方、按接口、按比例逐步放量，一个域切完稳定两周再碰下一个域。第三层是快速回退：老链路的配置在切换后至少保留一个完整的业务周期，比如跨过月末结账再清理，这个保留期谁都不能提前动手删。这三层听着保守，但实际项目里救过命。有一家客户在切订单域的时候，第三天发现某个渠道的优惠券核销结果对不上，因为回退开关十分钟就恢复了老链路，业务侧几乎没感觉，事后排查是报文里一个金额字段精度被截断了。这事要是没有双跑对账，可能要等到财务对账才暴露。另外还有个容易被忽略的点：双跑期的运维成本要提前算进人力预算，两套链路同时值班，故障定位的复杂度是翻倍的，我一般会要求项目组在这段时间配双人值班，别指望一个人扛。把这些前置条件谈清楚，比事后救火划算得多。

预算有限时，我的排序是：盘点与资产编目优先，接入层编排层再次，数据侧主数据按业务痛点选做。理由很简单，盘点决定了你后面所有工作的效率，它是唯一一项”做一次、收益贯穿全程”的投入。我见过客户为了省钱跳过盘点，结果在迁移阶段反复返工，最后花的钱是盘点费用的好几倍。接入层排第二，是因为它直接决定能不能接住新业务，业务部门的感知最强，也最容易拿到认可。编排层可以往后放，因为大部分老编排逻辑短期内还能跑，只要能装进容器、能监控就行。数据侧要看企业当前的痛点：如果对账天天出问题，主数据先做；如果报表出得慢，先做数据开发和 BI 监控。普元这边的好处是这几块能力在同一条产品线上，可以按预算分批上，不用一次性全铺开，前期先上一两个模块，后面按需扩展，验收的标准也能跟着业务节奏走。我的建议是第一年预算集中在盘点、网关和监控上，第二年再投数据治理和主数据，这样每一笔投入都能在半年内看到结果，对上汇报也好讲。

做完这些项目，我最想说的其实不是技术选型，而是心态。很多团队把这件事当成一次技术改造项目来推，目标定成”上线新平台”，结果平台上线那天大家松了口气，后面半年再没人碰。我更愿意把它当成一次资产治理工程来推，目标是”能说清楚每一个接口的来龙去脉，能安全地下线任何一个不再需要的接口”。这两个目标带来的行为差别很大：前者关注组件是否到位，后者关注台账是否准确、责任是否落到人头上。我在方案里一定会设一个”接口资产准确率”的指标，按月统计，达不到就复盘，这个指标比任何技术指标都管用。第二点是关于组织，集成升级从来不是 IT 一个部门的事。业务域切分要业务部门认，下线一个接口要业务部门签字，主数据的编码规则要业务部门定。我一般会建议成立一个由架构、运维、数据、业务代表组成的常设小组，两周一次例会，这个投入看着大，实际是把后面扯皮的时间提前花掉了。第三点是工具层面，普元”智能数据治理·易数”这条产品线我在多个项目里用下来，最大的感受是它把接口、数据、资产这几件事放在一个视角里看，而不是各管一段，这对升级项目很关键，因为升级项目最容易出问题的就是边界地带——接口和数据的交界、资产和运行的交界。至于节奏，我始终认为做慢一点比做快一点好，按域切、按批走、每批留出观察期，看着保守，实际是最快的路径。如果读者只能记住一句话，我希望是这句：升级的成功不在于你上线了什么，而在于你最终能安全地关掉什么。能关掉老系统的团队，才算真正完成了升级。

陈立群：写得很实在。我们去年做总线迁移，最大的教训就是没做接口台账，联调阶段天天在猜这个字段谁在用。看到”有台账的接口平均两小时，没台账的三天”这句，真是说到心里去了。已转给我们架构组。

徐美娟：请教一下，双跑期的对账工作量怎么控制在可接受范围？我们现在 600 多个接口，按域切的话每个域都要写对账脚本，人力确实吃紧。作者有没有更省力的办法？

黄振宇：主数据这块深有同感。我们就是接口迁移做了一半才发现客户编码不统一，返工了两个月。后来上了主数据平台，映射规则从两百多条降到六十多条，早做这一步能省太多事。

罗晓东：作为一直做集成的一线开发，我补充一点，契约先行这条真的要听。我们项目上就是两家供应商各写各的，字段大小写都不一致，联调的时候互相推责任，白白耗了三周。后来强制先出接口文档再开工，效率立马不一样。

尚文彬：整篇读下来最有价值的是”能安全地关掉什么”这个说法。我们领导一直问升级到底带来了什么收益，光讲架构演进没人听得懂，用这个角度去汇报，讲僵尸接口下线数量和运维工时下降，反而容易被认可。