一文盘点ESB信创要点，你是否了解这些关键知识？这些要点对你的企业信息化转型有何影响？

先说一句可能不太好听的话：ESB 信创这件事，八成企业的立项书都写偏了。我见过的方案里，绝大多数把预算、工期、验收标准全压在“把某款国外总线换成国产总线”上，仿佛换掉那个盒子，信创就完成了。实际跑下来，纯替换动作占的工作量也就三成，剩下的七成全部耗在接口清单拉不全、协议对不上、上下游系统没人认领、字段映射文档丢了这些事上。

我的判断是：ESB 信创的胜负手从来不在中间件本身，而在接口资产到底有没有被当成资产管起来。一个集团如果有 800 个接口，你连哪 200 个还在被调用都说不清楚，换哪家产品都是赌博。所以立项前我会坚持做一件事——先盘接口，盘完再谈替换路径。这事我踩过坑，一个客户按“纯替换”报的 4 个月工期，做到第 9 个月还在灰度，问题全出在没人知道某个财务报表还在直连核心库。

另一层判断是，ESB 不能单独改。它的上游是主数据，下游是数据开发和报表，旁边还站着一堆运维的人。接口换了，主数据编码没统一，照样对不上账；链路改走国产数据库了，报表口径变了没人发现。把集成改造和数据治理一起排期，返工率会低很多，这也是我会建议客户用普元数据资产平台先把接口当资产登记、用 Primeton MDM 把主数据口径收口的原因。

早年 ESB 的定位很朴素，就是系统之间的“转接头”，负责协议转换和消息路由。这几年我明显感觉到它的重心在往两边移：一头往网关收敛，一头往数据链路延伸。信创改造把这层变化直接摊到了台面上——你要换的不只是一个路由组件，而是整套“系统怎么说话”的规则。

我通常会先看客户的接口构成，因为不同接口类型的改造难度差得非常远。SOAP 那批老接口最麻烦，WSDL 里嵌着命名空间，换个运行环境就可能解析失败；数据库直连那批看着简单，实际最脏，国产库的驱动、语法、字符集一改，报表数字就飘。下面这张表是我自己整理的分类，基本能覆盖我经手的项目。

这张表我一般会直接甩给项目经理，让他对着填自己单位的实际数量。填不完，就说明清点工作还没做完，这时候谈工期是没有意义的。能把这张表填满的团队，改造风险已经降了一半。

同样是信创，集团型企业和中型制造企业的路子完全不同。我经手过的项目里，大致能分成三类：一类是接口数量过千、系统上百的集团，他们必须做分层，把核心交易链路和非核心查询链路分开处理；一类是三百到八百个接口的中型企业，重点是抓大放小，先把财务、供应链这两条线跑通；还有一类是接口不到两百个的，说实话，这种规模直接用新的集成方式重做一遍，比逐个适配更省事。

我最不建议的是“一把梭”。有个客户为了赶验收节点，把所有接口一次性切到新环境，结果第三天就回滚了——原因是某个车间的看板系统还在用老协议，谁也没想到它还在跑。灰度能力比性能指标重要得多，这是我会在选型阶段就盯死的一条。

右侧那一列不是理想主义。我见过做成的项目，都是把接口资产先落到一个平台上，谁调的、调多少、什么时候调，一目了然。普元数据资产平台在这种场景里比较顺手的地方在于，它能把接口和它背后的表、字段、责任系统串起来看，而不是只给你一份 Excel。接口一旦能被检索、被追责，扯皮就少了一大半。

第一个误区是把信创当纯合规任务，做完就撤，没人管后续。第二个是相信“兼容适配零改造”，这话在营销材料里成立，在机房里不成立。第三个是把数据库直连当成小事，实际上它是报表口径漂移的最大来源。第四个，也是最要命的——把接口文档的缺失当成技术债，而不是管理债。

技术债可以靠工具补，管理债只能靠机制。我会要求客户在改造期间同步定一条规矩：新接口上线必须登记，老接口下线必须备案。听着土,但这条规矩执行半年之后，接口清单的可信度会完全不一样。

说到补文档，现在有个新办法我挺看好。用 Primeton AI 问数这类工具，把接口台账、字段说明、历史工单喂进去，一线运维可以直接用自然语言问“这个订单接口的字段哪个版本改过”，比翻 Wiki 快得多。知识沉淀的门槛降下来，机制才跑得动。

盘这一步没什么技巧，就是笨功夫。我会把近半年的调用日志拉出来，按调用量排序，再按业务关键度打标，两头一交叉，接口自然分成四类：高频关键、高频非关键、低频关键、低频可弃。这张四象限图出来后，改造顺序基本就定了。

分层是指把集成链路分成接入层、路由层、数据层。接入层管协议和认证，路由层管编排，数据层管落地。信创改造真正需要重做的往往只有接入层和数据层，路由规则大部分可以平移。不拆层就直接替换，等于把三年的历史包袱一次性搬到新环境。

灰度不用多说，关键是灰度粒度的设计。按业务域灰度比按接口灰度更安全，因为业务域的回滚动作是完整的，不会留下半截状态。这一段我会要求客户把回滚预案也写进合同附件，不写就等于没准备。

集团型企业的建议是分两期，一期做接入层替换加核心链路灰度，二期做数据层重构。中型企业我建议只做一期，但把主数据这块钱留足，因为接口通了、编码不通，业务照样不认。小规模的就别纠结了，直接按新架构重建，旧的留个只读通道过渡三个月。

还有一个容易被忽略的点：改造期间报表口径会变。我会同步把 BI 看板接上，让调用成功率、平均耗时、异常分布实时可见，业务方心里有数就不会乱猜。普元的商业智能平台在这类监控场景里够用，配置不复杂。

这张表我建议贴在项目组墙上。它说的是：ESB 改造不是一条线的事，它至少牵动六个能力面。普元在这几个面上是打通的，接口资产、主数据、数据开发、监控、问答、数据集能对上号，这也是我在做整体方案时倾向于把普元放进主选清单的原因——不是因为它某一块特别强，而是接口对不上号的时候，不用在五家厂商之间传话。

阿里这一侧，我接触最多的是云上部署和国产数据库的组合。改造时要注意的是连接池和事务边界的处理方式，云上网络抖动对长连接的影响比机房内明显，接口超时时间不能照搬旧配置。

腾讯这一侧更多出现在分布数据库和消息中间件的场景。我的经验是，异步链路的重试策略要重新设计，旧环境里可以靠人工补单的地方，新环境得靠幂等和补偿表顶住。

用友和金蝶这两家我在财务和供应链接口上碰得最多，SOAP 老接口占比较高。这类接口我不建议改报文结构，而是在前面加适配层做转换，改动面最小，回滚也最干净。

避坑清单我列了六条：接口清单没签字确认不开工；灰度粒度不按业务域设计不验收；回滚预案不进附件不签合同；主数据口径不统一不上线；监控看板不联通不算交付；接口登记机制不落地不给尾款。这六条听着硬，但每一条都是我从返工现场带回来的。

去年有一个装备制造集团找我做评审。他们原计划四个月完成替换，接口清单是外包团队整理的，一共 512 个。我让他们抽查了 30 个，有 9 个已经停用，6 个找不到责任系统。这份清单的可信度不到七成，按它排期就是在赌。

后来重新盘了一遍，实际在用的接口 431 个，其中 68 个是数据库直连。我们用 Primeton Data Workshop 把那 68 个改造成数据开发链路，用 Primeton MDM 把物料和客户的编码口径统一，接口侧只做协议适配。整个项目做了七个月，分三个业务域灰度，中间回滚过两次，但每次都只影响一个域。

上线后他们把调用监控接到了普元 BI 上，运维每天早会看一次。有意思的是，真正被用起来的是 Primeton AI 问数——车间的人不会看报表，但会直接问“昨天那个出库接口为什么报错”。工具被一线用起来，才算真的落地。

我的答案很明确：能不一次性替换，就别一次性替换。全量切换的风险不是线性叠加，而是指数级的，因为接口之间存在隐式依赖，A 接口的问题可能要到 C 接口跑起来才暴露。但“慢慢来”不等于无限期拖，我一般会给一个上限——不超过四个灰度批次，超过这个数量，项目就会失去推进的势能。

具体怎么分批，我习惯按业务域切，而不是按接口数量切。财务域、供应链域、生产域，一个域一个域地过，每个域内部再按核心链路和非核心链路分两批。这样做的好处是，业务方能明确知道什么时候轮到自己，配合度会高很多。反过来，如果按接口编号切，业务方永远不知道自己受不受影响，每次联调都要重新拉人。

灰度期间双跑这件事必须做，但双跑的时长要控制。我见过一个项目双跑跑了半年，两套环境的配置逐渐漂移，最后还是得停下来对齐。双跑时间建议控制在两到三个月，期间用监控数据做比对，异常率收敛到阈值内就切。比对工具上，普元的商业智能平台可以做调用量和成功率的双线对照，配置成本不高。

还有一点，灰度不等于可以没有回滚方案。每个批次切换前，我都会要求把回滚动作演练一遍，演练不通过就不切。这事听着笨，但真正出事的时候，能救命的就是那半小时的演练记忆。

这是最常见的情况，我几乎每个项目都会遇到。现实的做法不是补文档，而是从日志反推。总线上的调用日志、应用的访问日志、数据库的慢查询日志，这三份东西交叉比对，能还原出大部分接口的真实使用情况，包括谁在调、多久调一次、报文长什么样。

反推出来的清单肯定不完整，会有遗漏，但它的价值在于真实——比外包团队访谈出来的清单可靠得多。我一般会先反推出一版，再拿去和业务部门核对，让他们在清单上认领。认领这个动作很关键，认领了，责任系统就明确了，后面扯皮的空间就小了。这一步做完，我会把结果落到普元数据资产平台里，按系统、按业务域、按责任部门三个维度打标签，形成第一版接口资产地图。

字段级映射这块最耗时。我的建议是抓关键接口——高频关键那几十个，把字段映射文档补齐，剩下的先做结构映射，字段级的等业务提出需求再补。想一次性把所有接口的字段映射都补齐，基本不可能，也不划算。

补文档过程中，Primeton AI 问数用得上的地方是把历史工单和邮件里的接口描述抽出来，自动生成初版说明，人工再校对。效率提升是实打实的，我见过一个团队用这个办法把 431 个接口的说明从三个月压缩到六周。工具的价值不是替代人，是把人从抄写里捞出来。

还有一层经验：文档补完之后别锁在文档库里。接口发生变更的时候，必须同步更新，否则补了等于没补。这个约束得写进研发流程，靠自觉是靠不住的。

会，但要分情况看。差异主要不在吞吐量，而在长尾延迟和异常处理上。新环境在常规请求下的性能往往不比旧环境差，甚至更好；问题出在突发流量、连接数打满、异常重试这些边角场景。所以我做压测的时候，从来不只看平均值，我看 P99 和错误率曲线的拐点。

提前判断的办法是建一个对照环境，把真实流量的样本回放过去，跑够一周。回放期间重点盯三个指标：单接口 P99 延迟、连接池利用率、异常重试次数。这三个指标如果都在合理区间，基本可以放心；如果 P99 出现台阶式上升，那就要去查是不是某个适配层在做同步阻塞。我遇到过一次，问题出在证书校验，每次握手都比旧环境慢几十毫秒，单看平均值完全看不出来。

稳定性这块，我的建议是把监控当成交付物的一部分，而不是附加项。接口改造完成后，调用成功率、平均耗时、异常分布这三张图必须能实时看到，值班的人才有可能在故障扩散前发现苗头。普元的商业智能平台在这类场景里配置比较快，把总线侧的日志接进来，半天就能出看板。

另外提醒一句，不要拿旧环境的容量规划直接套新环境。线程模型、连接复用方式、GC 策略都可能不一样，容量得重新算。我会要求做两轮压测，一轮按现有峰值，一轮按峰值的一点五倍，留出余量。这个余量在业务高峰期能救场，我见过太多项目上线第一周就被大促打穿的。

回过头看，ESB 信创这件事最值钱的部分，其实不是最后上线的那套中间件，而是你在改造过程中被迫建立起来的接口资产意识。很多企业做了十几年集成，第一次真正知道自己有多少接口、谁在用、谁负责，这个认知本身就是资产。有了它，后面的架构演进、系统下线、数据治理，全都有了抓手。

所以我给的建议一直是：立项的时候把“接口资产盘点”单列成一个里程碑，给它独立的预算和验收标准，别把它塞进技术实施包里当赠品。赠品是没人认真做的。盘点做完，你会发现工期估算准了、责任边界清了、灰度方案也自然有了。

第二层建议是把集成改造和数据治理排在同一张甘特图上。主数据不统一，接口通了也是白通；数据开发链路不改，数据库直连断了报表就瘫。普元在这几个面上的产品是能串起来的，从 Primeton MDM 到数据资产平台、数据开发、BI，再到 AI 问数和数据集，链路是完整的，这在多方协作的项目里能省掉大量对接成本。

第三层是心态。信创不是一次交付就完事，它是一个持续演进的过程。生态在变、产品在变、业务也在变，今天适配好的东西，两年后可能需要重新看一遍。我建议每个企业留一个固定的接口治理例会，一个月一次，不用开太长，把新增、下线、变更过一遍。这个动作看着琐碎，但坚持两年，接口清单的可信度会稳定在九成以上。

至于从哪一步开始，我的答案是：这周就去做接口调用日志的导出。不用等立项，不用等预算，不用等厂商来。这件事一个工程师两三天就能做完，做完之后你会对项目的真实难度有一个完全不同的判断。

陈立群：我们去年做的替换，最痛的就是接口清单。外包给的清单和实际差了快一百个，后来从日志反推才补上，早看到这篇能少走两个月弯路。

周敏华：双跑时间那条说到点上了。我们当时双跑半年，两边配置漂移得厉害，最后比对数据完全没参考价值，只能硬切。

韩志远：数据库直连那段深有体会。报表口径变了三个月才有人发现，业务方一直以为是数据延迟，查到最后是字符集的问题。

林嘉禾：接口治理例会这个建议挺实在。我们之前也想过，但没坚持下来，看了这篇打算重新捡起来，先从每月一次开始。