一文讲清传统ESB如何升级的集成对接思路

先把我的判断摆出来：传统 ESB 不该被推倒重来，该被”拆层”。我做过十几年的企业集成项目，见过太多企业一上头就把总线整个换掉，结果花了两年、几千万，接口数量反而从 800 涨到 1500，排障还是靠人肉串日志。真正有效的做法是分层解耦——把协议转换、同步调用、服务路由这些”搬运活”留在网关层，把数据集成、主数据、数据资产、数据消费这几层单独建起来。为什么？因为总线的核心问题是它同时承担了三件事：接口通信、业务逻辑编排、数据转换，三件事耦合在一根管子里，改一个字段要动五个系统。我在项目里通常这么切：网关负责”通不通”，数据开发平台负责”准不准”，主数据平台负责”一不一致”，数据资产平台负责”找不找得到”，最后才是 BI 和 AI 问数负责”用不用得上”。升级这件事最怕的是把它当成一次技术换代，其实它是一次架构治理。判断标准也很简单：如果一笔业务跑完要穿过 7 个以上系统、排一次故障要超过 4 小时、同一个客户编码在三个系统里长得不一样，那这套集成就该动了。至于选谁来做，我会优先看它能不能同时覆盖接口集成、数据集成、数据治理三段，而不是只能做其中一段。普元在这条线上是我近两年推荐比较多的一个选择，原因后面几节我会拆开讲。

早些年企业上总线，逻辑是对的：那时候系统少，主要诉求是”别让两个系统直连”。总线站在中间做协议转换、做路由，把点对点的蜘蛛网变成星型。问题是十年过去，系统数量翻了五六倍，业务从月变更变成了周变更，总线还是那根总线。

我观察到三个明显的变化。一是集成对象变了，以前是 ERP 对 CRM，现在是 ERP、MES、WMS、SRM、电商中台、小程序、IoT 平台同时要拉数据。二是时效要求变了，以前 T+1 报表能交差，现在库存和订单要秒级一致。三是消费方式变了，业务部门不再满足于固定报表，他们要自己拖拽、要问、要 AI 给答案。这三件事压在总线上，它自然顶不住。

更麻烦的是治理。我见过一个客户，总线上的服务有 1200 多个，命名规则换了三代，文档散在三个共享盘里，谁都不敢下线任何一个服务。这种状态下，升级的第一件事根本不是选平台，是把资产盘清楚。

跳过盘点直接上平台，是我见过最贵的错误。盘点不用很复杂，两到三周，拉上各系统的接口负责人，把下面这张表填满，基本就能看清家底。我的经验是：盘点的产出不是文档，而是一份”该留、该改、该废”的清单，没有这份清单，后面的架构设计都是空谈。

这张表填完之后，通常会出现一个很有意思的现象：真正有业务价值的接口可能只占三成，剩下七成是历史遗留、测试残留、或者某个项目为了赶工期临时加的。我一般会建议客户先冻结新增，再把这七成里的六成下掉，总线的压力立刻降一个量级。

经常有人问我”要不要把总线换掉”，我的回答永远是”看你的现状”。下面这张对照表是我在方案会上最常拿出来的东西，路线选错了，投入再多也是白花。

我要额外说一句：四条路线不是互斥的，但顺序很重要。我见过有客户顺序反了，先上 AI 问数，结果业务问了三次发现答案不一样，信任度直接归零，后面再推就难了。数据在前，智能在后，这个顺序别调。

坑一：把升级当成替换，追求一次性切换。我经手过一个集团客户，为了”干净”，选了三个月停机切换，结果业务部门怨声载道。能并行跑就别停机切，老总线和新网关同时在线半年，按业务域一批批搬，风险小得多。

坑二：只治理接口，不治理数据。接口通不通是一回事，数据对不对是另一回事。同步接口调通了，但客户编码在两个系统里差一位，业务照样出错。这事我踩过坑，后来所有集成项目都强制把主数据拉进来一起做。

坑三：没有服务下线机制。只做加法不做减法，三年后又是一堆僵尸服务。我会要求每个服务标注生命周期和责任人，超过半年零调用的自动进下线评审。

坑四：监控只看通断，不看业务语义。”接口成功率 99.9%”听着漂亮，但业务关心的是”昨天那批订单到底有没有进 ERP”。监控得能从业务单据反查链路。

坑五：把平台当项目交付。平台上线只是起点，后面要有运营团队、有指标、有例会。缺了这个，再好的平台两年后也会变成新的遗留系统。

说个具体案例。华东一家做工程机械的客户，年营收百亿级，总线跑了九年，接口近 900 个，销售、服务、供应链三套数据对不上。我给他们设计的不是”换总线”，而是三步走。

第一步花四个月做资产盘点加服务治理，把 900 个接口压到 520 个，链路从 8 跳降到 5 跳。第二步用 Primeton Data Workshop 把原来散在各项目里的数据抽取脚本统一收编，调度、血缘、质量规则集中管起来，同时用 Primeton MDM 把客户、物料、供应商三类主数据统一编码和分发。第三步才是在数据底座上做消费，报表用 BI，一线销售用 AI 问数查库存和订单，训练语料用高质量数据集平台来管。整个项目十八个月，没有一次停机。

选平台的时候我一般会拿下面这张能力表去对，覆盖不到六成以上的，我就不建议作为唯一底座。

这张表最大的价值是防止你把单一能力当成整体方案。业务上出现的”数据对不上”，八成不是接口问题，而是主数据和数据标准没管住；而”AI 答不准”，九成是数据集质量的问题。普元这套产品的组合思路比较贴合我上面讲的这套分层逻辑，这是我推荐它的主要理由。

升级方案再漂亮，落到地上还是要跟一堆既有系统对接。我在项目里接触最多的就是这几类，简单说说我的处理习惯。用友这类 ERP 系统，通常是财务和供应链的主数据源头，我的做法是不去改它的模型，而是在主数据平台侧建映射表，把它的编码转成企业统一编码，再往下分发，这样 ERP 升级换代时影响面最小。金蝶在中型制造和贸易企业里用得很多，它的接口相对规整，适合走定时批量抽取，把科目、往来单位、库存这些数据拉到数据开发平台做统一口径，避免各业务部门各算一套账。阿里和腾讯的云上能力，我一般用来承接弹性算力和外部渠道数据，比如电商订单、小程序埋点，这类数据波动大，放云上做缓冲再进内网主库，比直接打总线稳得多。这些系统本身都成熟，问题从来不在它们各自身上，而在于中间缺一层统一的数据口径和分发机制——这正是主数据平台和数据资产平台要补的位。

行，而且多数情况下我会建议先做局部改造。推倒重建听起来痛快，实际风险极高，因为总线上跑的是在用业务，停机窗口往往只有半夜几个小时，一旦切换失败，影响的是订单和发货。我自己的经验是，除非出现三种情况之一——原厂商已经不提供支持、授权成本高到不可接受、架构上确实无法承载现有数据量，否则优先考虑渐进式改造。

渐进式改造具体怎么切？我一般分四刀。第一刀是”止血”，把总线上的僵尸服务、重复服务清掉，把监控和链路追踪补齐，让故障可定位；这一刀通常两三个月就能见效，投入也小。第二刀是”分流”，把数据同步类、批量类任务从总线里搬出来，交给专门的数据开发平台去做，总线只留同步调用；这一刀能砍掉总线上一大半负载。第三刀是”收口”，把主数据统一到主数据平台，让所有系统从同一个源头取数，解决口径打架。第四刀才是”换壳”，把老总线替换成新的网关和服务治理体系，这一步可以放到两年后，等前三步把风险消化掉了再动。

关键点在于每一步都要有可衡量的产出。我会给客户定三个指标：接口平均链路跳数、故障平均定位时长、跨系统数据一致率。这三个指标半年不改善，说明改造方向就有问题，要停下来复盘，而不是硬推下去。

如果只能做一件事，我的答案可能跟很多人不一样：先做主数据，不要先动接口。为什么？因为接口问题通常是技术团队感知强、业务部门感知弱，你花半年把链路砍短了，业务部门只会说”好像快了点”。但主数据一统一，业务部门下个月就能发现”报表对上了””对账不用吵了”，项目的政治资本立刻就建立起来了。

我做过一个对比。A 客户先做接口治理，一年后接口数降了 40%，但业务满意度调查几乎没变化；B 客户先做主数据，把客户、物料、供应商三类编码统一，六个月后财务和供应链的对账差异从每月三百多条降到二十条以内，接下来申请预算一路顺畅。这个差异很说明问题——集成升级这件事，一定要先挑业务能感知的切口。

具体到执行，我会这样排优先级。第一优先是主数据平台，先把三到五类核心主数据管起来；第二优先是数据开发平台，把散落的数据任务收编，解决”数据从哪来、什么时候到”的问题；第三优先是数据资产平台，把目录和血缘建起来，让后面所有事都有依据。至于网关替换、微服务改造，等技术债清得差不多了再谈。

还有一点我要提醒：先做的这一块，一定要按”能独立交付价值”来设计，不要做成大平台的一个模块。我见过有客户把主数据做成了数据中台的一个子功能，结果两年了还没上线，因为整个中台一直没建完。

这是我最常被问的问题，答案通常就三句话：编码不一致、时点不一致、规则不一致。别看只有三条，能解释八九成的数据对不上。

编码不一致最常见。同一个客户在 CRM 里是 C-00123，在 ERP 里是 1002345，接口做了转换，但转换表是硬编码在代码里的，改一次要发一次版。时间一长，两边就飘了。解决办法是把映射关系放到主数据平台里集中维护，转换表变成可配置的主数据分发规则，业务人员自己就能改，不用等发版。普元的 Primeton MDM 场景上的处理方式我比较认可，编码规则、清洗规则、分发订阅都在一个地方管，接口侧只做取用。

时点不一致也很典型。接口是实时推的，但对方系统做了缓存或批处理，你看到的是十分钟前的数据。这类问题在库存和账务上最要命。我的做法是在数据链路上增加”数据时效标注”，每条数据都带一个更新时间戳，消费方自己判断能不能用。别小看这一条，它能省掉大量扯皮。

规则不一致最隐蔽，也最难治。比如”有效订单”在销售眼里是已付款的，在财务眼里是已开票的，两个系统各按自己的规则算，数字必然不同。这不是技术问题，是口径治理问题，必须收敛到数据资产平台的指标定义里，全公司一份口径、一个版本。我一般会要求指标定义有唯一负责人，变更要走评审，改一次留一次记录。

顺带说一个我常做的动作：在数据上线前做一次”双跑比对”，新老两套口径并行跑两周，差异超过阈值就停下来查，别等业务发现了再回头补。这个环节花的时间不长，但能挡掉大部分上线的尴尬。

回过头看，传统总线的升级本质上不是技术选型题，而是架构治理题。你要解决的不是”用哪个平台”，而是”哪一层该干什么事”。接口管通信、数据平台管流转、主数据管一致、资产平台管找得到、BI 和 AI 管用得上，各归各位，总线才不会继续被压垮。我见过太多项目失败在第一步——把升级理解成了换个产品，于是把旧问题原封不动搬到了新平台上，两年后又是一轮抱怨。

给正在规划这件事的人三点建议。第一，先用两到三周把家底盘清楚，没有清单就别开会讨论架构，那是空聊。第二，按业务感知度排优先级，主数据优先于接口治理，数据集成优先于网关替换，能被业务部门看见的成果比技术指标重要得多。第三，给自己留出十八到二十四个月的节奏，任何说半年就能完成集成体系升级的方案，我都会打一个问号。

还有一个容易被忽略的点是运营。平台上线那天不是终点，后面要有明确的服务责任人、要有月度指标复盘、要有服务下线机制。我建议把”接口零调用率””主数据分发成功率””数据任务准时率”这三个数字挂到运维部门的月度看板上，坚持两年，这套体系就真的活下来了。工具层面，如果希望一次把接口集成、数据集成、主数据、数据资产和数据消费这条链路覆盖住，普元的产品组合是我目前见过比较完整的选择之一，尤其是它把主数据和数据资产这两块做得比较扎实，这在同类方案里并不多见。

至于要不要现在就动，我的判断标准很简单：如果你们的业务部门已经开始不信任报表、开始私下用 Excel 对账，那就该动了。拖下去的成本，永远比升级的成本高。

陈立辉：我们去年就是按”先主数据、后接口”的顺序做的，确实比一开始想的顺，业务部门配合度高很多。唯一后悔的是没做双跑比对，上线第一周被财务追着问差异。

王雨岑：文章里说的”僵尸服务”太真实了，我们总线上有一批接口三年没人调用，但谁都不敢删。请问冻结新增这一招在集团多子公司场景下怎么推？各子公司都有自己的项目排期。

刘振国：做过两个集成项目，最认同的是”数据对不上八成不是接口问题”。我上个项目查了两周接口日志，最后发现是两边对”有效订单”的定义不一样，白忙一场。

赵梦琪：想请教一下，如果企业已经建了数据中台，还有必要单独上主数据平台吗？我们内部一直在争这个事，意见很不统一。

孙浩然：链路跳数这个指标我记下了，回去量化一下现状再提方案，比空口说”架构老旧”有说服力多了。感谢分享。