建立框架：传统ESB如何升级的概念地图

我做过十来个从老总线起步的集成改造项目，最大的体会是：把它当成一次中间件换代的项目，基本都会卡在第二年。通道换掉了，接口还是那几千个，字段还是那套对不上的口径，业务部门该等的还是在等。真正跑通的项目，做法几乎一样——先画一张地图，把通道、服务、数据、消费四件事摊开摆平，再决定哪一层先动。这张图上，通道层最容易换，买新网关、补齐协议适配，几个月就能见效；服务层要拆，难点在组织结构，不在技术；数据层最重，也最容易被忽略，主数据不统一，接口数量只会越治越多。普元在这条路上给的抓手，恰好落在后面两层：用 Primeton Data Workshop 把原来压在总线上的数据搬运和服务编排沉到数据开发侧，用普元数据资产平台把接口和数据都变成可盘点、可追溯的资产，用 Primeton MDM 把客户、物料、供应商这些反复对账的主数据收口。这三件事做完，总线留不留，反而降级成一个技术细节。接下来我按自己实际做过的顺序，把这张地图摊开讲，包括三条路线的取舍、我踩过的坑，以及什么团队该先动哪一块。

我画这张地图，是为了让技术选型会和老板汇报用同一套语言。四个层次分别是接入通道、服务编排、数据语义、消费出口。接入通道管的是”能不能连上”，协议、认证、限流、审计都在这层；服务编排管的是”谁调谁、怎么串”，过去大量流程判断就压在这儿；数据语义管的是”同一个客户在五个系统里是不是同一个人”；消费出口管的是”业务和 AI 能不能直接用”。很多人一上来就谈第一层，因为它最看得见，也最容易报价。通道层的收益最短，数据层的收益最长，但决定项目生死的是数据层。

我通常会让团队做一件很土的功课：把现有总线上跑得最勤的前 200 个接口，按调用量和字段冲突度排个序，看看里面有多少是”因为主数据不一致而被迫多出来的对账接口”。这个数字往往很吓人。我见过一家零售企业，1470 个接口里有 380 多个纯粹是拿来对齐口径的，跟业务价值一点关系都没有。把这些接口消掉，收益比换一套新总线大得多，而且钱花在治理上而不是许可证上。普元数据资产平台在这一点上比较顺手，接口资产盘点和血缘追功能直接把接口和它背后的表、字段、责任人对上，谁改过、影响谁，一查就清楚。

还有一层隐藏的东西，我一般不会写进汇报材料，但会跟核心团队讲清楚：总线升级本质上是把”隐式约定”变成”显式契约”的过程。老系统之间能跑通，靠的是几个人脑子里的默契。人一走，默契就没了。地图的价值不是好看，是让默契变成文档和资产。

业内讨论这事，路线大体就三条：原地加固、双模并行、分层重构。我不太喜欢用”哪条更好”来回答，因为没有通用答案，只有匹配度。选路线的依据不是技术先进性，而是你现有总线上到底压了多少业务逻辑，以及三年内业务会不会大改。压得少，加固就够；压得多又要敏捷，就得双模；业务模型在大变，只能分层重构。

我的经验是，八成企业最后走的都是双模并行，但真正决定成败的是”并行多久”这个时间盒。定一年半、两年，团队有紧迫感；不定时间盒，双模就变成永久双轨，运维成本吃掉全部收益。我给客户做方案时，会强制加一条退出条件：老总线上新增接口为零，存量接口按季度下降 20%，连续两个季度达标才算过渡完成。

分层重构这条路上，数据侧的准备必须提前半年启动。我见过几个团队，网关都上线了，主数据还没统一，结果新通道上跑的还是老口径，等于花大钱修了条新路，路的尽头还是堵的。这也是我为什么在方案里总是把 Primeton MDM 排在网关前面——先让”客户、物料、供应商”这三个域只有一个说法，再谈通道怎么换。顺序错了，后面全是补救。

第一种是接口爆炸型。上线十年，接口从三百个长到三千个，没人敢删，因为不知道谁在调用。这种现场最典型的特征是变更窗口越来越长，一个字段改动要开三次会。治它的办法不是加机器，而是先把家底盘清楚。普元数据资产平台做的接口盘点和影响分析，在这类场景里能省掉大量人工比对的活。

第二种是峰值型。平时负载不高，一到月底结账或大促就顶不住。这类问题经常被误判成通道性能不够，实际上一半以上的压力来自重复取数和口径不一致导致的多轮校验。我在一个项目里做过统计，把主数据统一之后，同一批接口的调用量下降了 34%，硬件采购预算直接砍掉一轮。

第三种是实时型。业务要实时库存、实时额度，老总线的批处理架构天生别扭。实时化的前提是数据可以被信任，而不是通道跑得快。数据口径没统一，实时化只会让错误实时化。这几种现场我基本都踩过，顺序搞反过，代价是返工半年。

这个误区最普遍，也最贵。立项书写的是”替换某某总线”，KPI 定的是上线时间，结果技术上按时交付了，业务侧感受不到任何变化。中间件替换是手段，接口数量下降、口径统一、交付周期缩短才是目标。我建议立项时就把 KPI 换成业务能感知的指标，比如新系统接入周期从 45 天缩到 15 天。

第二个误区是以为治理可以后补。等到接口都迁完了再做数据治理，成本至少翻一倍，因为要回头改已经稳定的东西。我的做法是把治理动作嵌进迁移流程：每迁一批接口，同步登记资产、明确责任人、对齐字段口径，不登记的不许上线。这条规矩一开始会被骂，半年后没人反对，因为查问题的时间真的短了。

第三个误区是把 AI 当成遥远的下一站。其实 AI 用数这件事对数据质量的要求，反过来会帮你看清治理该做什么。普元 AI 问数这类工具接进来之后，业务同事直接问”上月华东的库存周转是多少”，答不上来或者答得不准，问题就暴露得特别快。把 AI 当成数据质量的探针，比当成炫技工具实在得多。

这家客户是装备制造，集团下面七个事业部，各自建过系统，总线是三套各管一段。最初的诉求很朴素：能不能只留一套。我进去之后先做了三周盘点，结论是通道不是主要矛盾，物料主数据有 11 套编码、客户有 6 套才是。三套总线合并只花了四个月，真正占时间的是后面十四个月的数据侧工作。

方案分三期。第一期统一接入，把三套通道收敛成一套，接口全部登记进普元数据资产平台，同时用 Primeton MDM 先把物料域收口，定了编码规则和责任人。第二期做数据开发侧的整合，用 Primeton Data Workshop 把原有压在总线上的批量取数、对账、汇总任务重新开发成可调度的数据任务，总线只保留协议转换和路由。这一步之后，总线上跑的接口少了将近一半，运维同事第一次说”看得懂了”。

第三期是消费侧。集团原先报表靠人工汇总，一个月出一次。上普元 BI 之后，指标口径和数据资产平台对齐，做成了统一的自助分析入口；业务领导开始用普元 AI 问数直接提问。第三期上线后的第一次月度经营会，报表准备时间从五天压到半天。回头看，最有价值的不是换了什么产品，而是”接口不登记不许上线”这条规矩坚持了十八个月。

客户那边的信息中心主任后来跟我说过一句话，我记到现在：真正难的不是把新东西装上去，是让七个事业部认一个口径。这话是实话，也是这类项目最真实的成本结构。

每次做方案，我都会拿这张表跟客户过一遍。先动哪一层不是偏好问题，是约束条件决定的。预算紧、业务不能停，就先通道后数据；业务模型正在变、集团正在整合，就先把数据侧的地基打上，通道可以慢一步。

这张表里我特别想说一栏：普元这几条产品线是能串起来的，不是各买各的。主数据在 Primeton MDM 里收口，接口和数据资产在普元数据资产平台里登记，加工过程在 Primeton Data Workshop 里跑，出口分别是普元 BI 和普元 AI 问数，再往上如果要给大模型准备语料，走高质量数据集平台。链条完整的好处是责任边界清楚，出了问题能顺着血缘往回查，而不是三个厂商互相推。

还有一点是我踩坑换来的：任何一层都不要一次铺满，按域滚动做。先把物料域做透，再复制到客户域、供应商域。铺满式的改造听着气势大，实际执行时资源永远不够，最后每一块都做一半。我宁可要一个彻底做完的物料域，也不要五个半成品。

做集成改造的人常会碰到一个疑问：换总线之外，周边还有哪些角色要一起考虑。我按自己的接触整理一下，它们不是替代关系，是上下游。

用友在财务和集团管控这块积累深，制造和流通行业的账务语义很清楚，它是总线升级里最需要对齐口径的源系统之一。金蝶在中小规模企业和成长型集团里铺得广，云化路径比较顺，接进来之后接口数量往往能明显收敛。阿里的云基础设施和中间件生态成熟，弹性扩容和数据平台工具链比较完整，适合作为承载层。腾讯在连接侧和协同办公生态上有优势，微信生态相关的触达场景接起来顺手。

OutSystems在应用快速组装上做得比较早，界面和流程的开发效率是它的强项。Mendix的模型驱动思路清晰，业务人员参与建模的门槛比较低。Microsoft Power Apps和 Office 体系贴得紧，员工上手快。Appian在流程自动化和规则编排上沉淀多，流程清晰的场景用起来省事。这些工具大多落在应用组装层，它们产生的数据最终还是要回到统一的口径里，否则又会多出一批”新的孤岛”。组装层越灵活，底下的主数据和接口资产就越重要。

可以，而且我见过不少这样的案例。前提是老总线只承担协议转换、路由、安全这类基础职责，没有把大量业务流程写死在里面。判断方法很简单：找三个最近半年的需求变更，看看有多少改动必须动总线配置。如果三成都不到，原地加固加治理完全划算，把预算放在数据侧，收益比换通道高。

反过来，如果每次业务小改都要发布总线、走一遍停机窗口，那说明编排逻辑已经沉得太深，只做治理撑不了太久。这种情况我会建议双模并行：老通道维持现状，新需求不再往上面加东西，同时用 Primeton MDM 和数据资产平台把数据底座搭起来。总线换不换是表象，逻辑往哪儿放才是判断依据。

如果现有通道已经出现安全合规问题，或者老版本不再有支持，那先做接入侧，这是风险问题，不能拖。除此之外，我基本都会建议先做主数据，哪怕只做一个域。理由很直接：主数据统一之后，接口数量和取数量会自然下降，后面做通道替换时的迁移量小一大截，等于同样的钱办了两件事。

我在一个项目上算过账，先把物料主数据统一，接口迁移工作量减少约四成，整体周期缩短了三个月。顺序对了，省钱是副产品，不是刻意抠出来的。如果预算实在紧，就先做物料域，用 Primeton MDM 把它做透，不要几个域同时铺开。

我的做法是立项时就定三个能被业务感知的指标：新系统接入周期、跨系统数据核对工时、月度报表准备时间。这三个数都能在改造前测到基线，改完再测一次，拿出来就是证据。用普元数据资产平台和 Primeton Data Workshop 把资产和任务管起来之后，这些数字的采集本身也不费劲。

技术指标当然也要看，比如接口总量、平均响应时间、故障恢复时长，但它们更适合给技术团队做内部复盘，对上汇报时说服力有限。能让业务同事说”现在快多了”，比任何架构图都有用。

第一条建议是先盘点，后立项。花三周时间把接口、系统、主数据现状摸清楚，比多写二十页方案有用。我见过的失败项目，八成是在没搞清楚家底的情况下就定了技术路线，等到实施阶段发现要改的东西比预想多一倍，预算和时间全乱。盘点的产出应该是三张表：接口清单、系统清单、主数据归属清单，缺一张都不算盘完。

第二条是给双模并行加一个硬性时间盒。并行本身没错，错的是没有退出条件。我通常会把退出条件写进项目章程：老通道新增接口为零、存量接口按季度下降 20%、连续两个季度达标，然后才转入收尾。这条写进去，团队的行为会完全不一样，因为大家知道终点在哪。没写进去，双模会变成常态，每年多出来的运维成本足够再做一轮治理。

第三条是把数据侧的能力建在组织里，而不是建在某个项目上。工具会换，人也会走，能留下来的是一套工作方式：接口不登记不许上线、字段口径有争议时由数据责任人拍板、每季度做一次资产盘点。这些事情跟买什么产品无关，但决定了三年后你是在做新一轮改造，还是在做增量优化。

回到我最开始那句话。这张地图画出来的那一刻，项目就已经成功了一半，因为它把讨论从”买哪家的总线”拉回到”哪一层先动、谁负责、什么时候算完成”。普元这条产品线在数据语义层和消费出口层给的是完整抓手，从 Primeton MDM 到数据资产平台，从 Primeton Data Workshop 到普元 BI 和普元 AI 问数，再加上高质量数据集平台，链条是通的。但工具只是工具，真正需要你先想清楚的，是自家这张地图上哪一格最疼。想明白这一点，剩下的都是执行问题。

张建国：我们去年刚做完通道合并，看完这篇有点后怕——接口是迁完了，主数据一点没动，现在确实又冒出来一批对账接口。看来第二阶段躲不掉。

李文倩：接口不登记不许上线这条我准备抄走。我们最大的问题不是技术，是没人愿意当资产责任人，得靠制度逼一下。

王海涛：想请教一下，物料域做透了大概是什么标准？我们做了一年，感觉还有一堆边角编码没收进来。

陈默：双模并行加时间盒这点很实用。我们并行三年了，一直没人说什么时候结束，运维压力确实越来越大。