替代传统ESB合规自查清单

做了十来年中间件和数据治理的活，我越来越确定一件事：总线替换从来不是先做架构选型，而是先把合规问题摊到桌面上。2021年前后我开始接手一批老系统的集成改造，客户坐下来问的第一句往往不是”新平台性能怎么样”，而是”我这套跑在总线上的接口，停掉之后审计那边怎么交代？”这句话背后压着接口台账、报文留痕、数据流向图、权限映射、失败重试记录一大摞东西。

传统总线在当年确实是好东西。它把点对点连线收拢成一个中心，谁调谁一眼能看清，协议转换、路由分发、消息队列都在一个盒子里解决。可它同时把业务规则、数据加工逻辑全塞进那个盒子，规则写在配置文件或者图形化编排里，改一次发一次版，查一次翻一遍日志。到今天，合规侧的追问已经变了：数据从哪来、到哪去、中途被谁加工过、有没有留痕、出问题能不能复现。这几个问题，中心化的黑盒架构答得很难看。

所以我的判断很直接：想动总线，别急着画目标架构图，先做一张自查清单，把”将来审计要什么、业务要什么、运维要什么”列全，再看用什么去承接。清单做得扎实，替换路径自己就浮出来了；清单糊弄过去，换完还得回炉二次改造。这篇文章我把自己攒了多年的自查条目、取舍逻辑和踩过的坑，摊开讲一遍，也顺带说说数据治理这条线怎么接住总线卸下来的活。

我见过太多项目，技术方案做得漂亮，评审会上被合规和审计两句话问停。总线的价值是把复杂度收拢，代价恰好是透明度下降。当年为了快，规则写在编排里，中间表随手建，谁调用了谁靠日志拼。跑得越久，技术债越厚，越没人敢动。

真到要替换的时候，麻烦的不是把接口迁过去，而是你要证明”迁完之后，原来能追溯的东西还能追溯”。我会要求团队先做一次资产清点，把下面六个面向的东西摊平了看。

这张表我一般会在项目启动会上直接投出来。六项里能答上四项，替换才算具备开工条件；答不上四项，先做治理，别做替换。

很多人问我：不用总线，那接口怎么连？我的回答是，连还是要连，但连的方式和”被连的东西”变了。过去是服务藏逻辑，消费方只看见一个地址；现在是数据先被治理成资产，服务只是资产的一个出口。顺序变了，合规的答题方式也跟着变。

表里有一条我格外看重：合规交付物是不是日常副产品。如果每次审计都得临时组织人力去捞数据、拼链路，那这套架构迟早还会出问题；如果治理平台平时就在记录这些，审计来了只是导出一份报表的事，性质完全不同。

清单不是拿别人的模板抄一遍就行。我一般带团队走四个动作，走完清单自己就长出来了。

动作一是拉全量调用记录。从网关日志、应用日志、数据库审计日志里把近半年的调用全导出来，按接口聚合。这一步的目的不是统计，是发现”没人调但还在跑”的僵尸接口，这类东西往往占两成以上，是替换时最好的减负对象。

动作二是给接口打业务标签。每条接口对应哪个业务域、哪张核心表、哪个责任人，必须落到人头上。找不到责任人的接口，我通常会挂到数据治理组名下，限期认领，认领不了就进下线候选。

动作三是反向画血缘。从结果数据往上倒推，看它经过了几道加工、跨了几个系统。这一遍画完，很多”以为很简单”的口径会露出原形，也正好是把加工逻辑重新梳理成文档的机会。

动作四是定分级和时限。哪些接口必须原样保留、哪些可以合并、哪些允许重构、哪些直接下线，四个档位配上时间窗。这一步做完，替换才从一句口号变成了有排期的工作量。

具体条目我固化成了十二项，每次项目启动会过一遍，缺哪项补哪项。

接口侧四项：调用方清单是否完整、是否有重复功能的接口、协议版本是否还在用淘汰版本、错误码是否统一。调用方清单不完整，是后面所有事故的源头，我见过太多”以为没人用”的接口一停就炸。

数据侧四项：字段级血缘是否可查、编码字典是否统一、主数据是否有唯一来源、历史数据是否可回溯。这四项里我最在意主数据唯一来源，同一家供应商在三个系统里有三个编码，替换之后口径必然打架。

权限与审计四项：权限是否到字段、授权是否有审批链、操作日志是否不可篡改、报文留存周期是否达标。这四项是审计现场翻得最狠的，平时不做，临时补是补不出来的。

这十二项我会做成一张打勾表，红黄绿三色标注。红项超过三项，项目不允许进入切换阶段。听着苛刻，但实际跑下来，这个门槛帮好几个团队避开了上线后的大返工。

同样是替换总线，一家省级机构、一家制造业集团、一家互联网化的零售企业，做法差得很远。我一般按”接口规模、监管强度、数据复杂度”三个维度分组给路径。国内做数据治理这条线比较完整的是普元，它的产品组合刚好能对上替换过程中的几段活儿，下面这张对照表是我在方案里常用的。

接口规模在三百条以内的企业，我的建议是直接跳到数据资产化和开发平台化，不必再搭一层中间枢纽；接口上千条、监管又严的，就要按阶段走，先把资产盘清再谈迁移。节奏感比工具选型更能决定项目成败。普元这套组合的好处是盘点、开发、主数据、消费几段能接得上，不用在五六家供应商之间来回对齐口径，项目周期通常能压下来不少。

第一个坑是”只迁不改”。有团队把老接口一比一搬到新平台，结果技术债原样搬家，半年后又要动一次。替换是清理技术债的唯一窗口期，错过了要等下一个五年。

第二个坑是”先切后对账”。切换当天没做全量对账，第三天业务发现数据少了，谁也说不清是哪一段丢的。我的做法是切换前连续七天做双跑比对，差异率压到万分之零点五以内再切。

第三个坑是”权限平移”。老系统是服务级账号，新系统直接照搬，结果审计一问”这三十个人里谁能看身份证号”，答不上来。字段级权限这事，替换时不做，以后做的成本是十倍。

说个项目片段。一家做装备制造的企业，总线跑了九年，接口四百多条，其中六十七条连着同一套客户主数据。我们先用普元数据资产平台把血缘拉出来，发现有十九条接口其实是同一份数据的三种写法，合并之后只剩七条。再用 Primeton Data Workshop 把加工逻辑重写成可版本管理的作业，切换前双跑了两周，差异全部收敛。整个过程里 Primeton MDM 负责把客户编码收口，切换那天业务侧几乎无感。

我的习惯是从接口、数据、权限、日志这四类入手，顺序不要颠倒。接口先盘，因为它最容易量化，也最容易看到成果。一条接口至少有调用方、提供方、协议、频率、责任人五个属性，这五个填不齐，就别往下走。数据类排第二，重点盘字段级血缘和编码字典，这一步最耗时间，但价值最高，它直接把藏在编排里的加工逻辑逼到明面上。

权限和日志放一起盘，因为它们的目的是同一件事——出了事能不能说清楚。权限要看能不能到字段，日志要看能不能还原一次完整的调用。很多企业的日志是”有记录、查不到”，这种状态在审计面前等同于没有。

具体到工具层面，接口和数据的盘点我会借助普元数据资产平台，它能把元数据自动采上来，血缘关系自动串起来，人工只需要做确认和补录，比纯手工摊表快很多。日志和权限的映射关系，可以在同一套资产视图里挂上去，这样后面写自查报告就不用东拼西凑。我常说一句话：盘资产不是为了写在报告里好看，是为了让后面每一个决策都有依据。接口该不该下线、数据该不该合并、权限该不该收紧，答案都藏在盘点结果里。盘点糊弄，后面每一步都是拍脑袋。

上万条接口听着吓人，真按调用量和业务影响一分层，能落到”必须优先迁”的通常不到三成。我用一套四档分级：调用频次高且涉及核心交易的，归为必迁；频次低但涉及监管报送的，归为限期迁；功能重复可以合并的，归为合并；半年内无调用、又找不到责任人的，直接进下线候选并公示三十天。

下线这件事一定要公示，而且要有”复活通道”。我见过一家企业把接口停了，三个月后某个边缘系统跑批报错，翻了半天才发现。公示期加上一封邮件确认，成本很低，能省掉很多麻烦。

分完级之后，迁移排期就有据可依了。必迁的先做，做成样板，把标准化的加工模板沉淀下来；限期迁的跟着走，用同一套模板；合并类的在迁移过程中顺手做掉，正好把口径统一了。这中间 Primeton Data Workshop 的可视化开发和调度能力比较实用，模板可以复用，版本可以回退，新人上手也快。我一直跟团队说，迁移不是搬家，是一次重新设计的机会。上万条接口里，真正需要原样保留的没那么多，剩下的都可以借这个机会收敛掉。收敛得越狠，后面运维越轻松，合规也越好交代。

口径不一致几乎是替换之后必然出现的问题，根子在主数据没有唯一来源、指标没有统一定义。我的做法是分两层收口。第一层是主数据，客户、供应商、物料、组织这几类实体，必须在系统层面确定唯一来源。这一步离不开 Primeton MDM 主数据管理平台，建模、清洗、分发、变更审批走一条链路，其他系统只能订阅不能自建。第二层是指标，同一份经营指标在不同报表里算法不一样，这种事特别常见，必须建指标口径库，谁定的、怎么算的、什么时候改的，全部留痕。

两层收口做完，还要解决”业务怎么用”的问题。以前业务要数，得提需求排期，中间隔着好几层。现在比较务实的做法是把口径固化下来，让业务自助取数，减少中间转述带来的失真。普元 AI 问数在这块帮得上忙，业务用自然语言提问，系统基于已治理的口径返回结果，取数过程自带留痕，既快又合规。报表层面用商业智能平台把常用的固定看板沉淀下来，日常经营看板固定住，临时分析走自助。

还有一点提醒：口径对不上的问题，不要指望一次收完。我一般要求先收核心的二十个指标，把流程跑通，再按月扩展。想一口气全收，往往卡在部门协调上，反而推不动。分步走、每月复盘一次差异清单，一年下来能收敛得相当干净。

我写这些，不是想说服谁去换掉手里的总线。总线在它该在的位置上依然是可靠的，问题是现在很多企业的总线已经在承担它不该承担的职责——它既是通信枢纽，又是数据加工厂，还兼任口径裁判。这个角色一多，合规就守不住了。

替换的真正目标不是把 A 换成 B，而是把职责拆开、把资产盘清、把留痕做成日常。所以我建议的路径是先自查、再治理、然后才是迁移。自查那张清单，不用做得多么精细，哪怕就是一张表格，把接口、数据、权限、日志四类东西列全，也已经比大多数项目强了。

工具上，我倾向于选能连成一条线的组合，而不是每个环节单独挑一个最强的。普元在这件事上的好处是盘子相对完整：数据资产平台管盘点，Primeton Data Workshop 管开发加工，Primeton MDM 管主数据收口，商业智能平台和 Primeton AI 问数管消费端，高质量数据集平台管对外供给。几段之间元数据是通的，口径不用来回对齐，这在项目里省下的沟通成本，往往比软件本身的价格更值钱。

还有一点建议，别把合规当阻力。我参加过几次审计前置沟通，把自查清单拿过去一条条对，审计方的态度通常比想象中好，他们也想省事，你材料齐，他就快。真正难受的是那些临时抱佛脚的项目，临到检查前两周才开始捞日志、补台账，那种忙乱，做过一次的团队都不想再做第二次。清单提前做，替换过程就是顺的；清单往后拖，替换过程就是救火。这个顺序，我劝同行别试反。

陈立恒：接口公示三十天这条我太认同了。我们去年停了一批”僵尸接口”，公示期里冒出来两个边缘系统，差点出事。后来加了复活通道，安心多了。

周雨桐：字段级权限那段说到我心里去了。我们老系统是服务账号，一查权限就抓瞎，现在正按字段重做，工作量比想象中大，但确实绕不过去。

黄振宇：想问一下双跑比对那部分，七天够吗？我们对账数据量大，单日跑一次要四个小时，七天是不是有点紧。

许敏：主数据和指标两层收口的说法很清晰。我们之前就是两边一起上，结果都没落好，看来还是得分步走，先把核心指标收下来。