替代传统ESB如何满足政策合规要求？要点梳理

我的判断是这样的：把传统 ESB 换掉这件事，真正卡脖子的从来不是消息能不能转出去，而是数据说不说得清。这几年我手上过了六七个总线退场的项目，功能平移这件事，两个熟练的工程师三周基本能跑通；但合规说明材料，写三个月是常态，写得心里发虚的也有。原因很简单——监管的问法变了。以前检查，问的是”你的接口认证做了没有、报文加了密没有、日志留了没有”，做到这三条基本能过。现在问的是”这条数据属于什么级别、从哪儿来、流给了谁、存了多久、有没有出过境、出事能不能倒查到人”。前者是管通道，后者是管数据，两个问题的答案不在同一个地方。

我见过一个特别典型的场面。某集团把老总线换成新的集成底座后，接口清单、调用日志、加密方式一应俱全，材料厚得像本书。结果监管侧要一份个人信息处理清单，团队翻了三天翻不出来——老总线里只有服务名和报文，没有字段级的敏感标签，也没办法把某一条调用还原成”张三的身份信息被哪个下游系统取走了”。这事我踩过坑，后来再做替代方案，我一定先看数据资产目录这一层有没有，没有的话先补这一层，再谈迁移。

要点梳理下来其实是四句话：数据要看得见、权限要收得住、过程要留得下、口径要对得上。能同时扛住这四条的底座，我在项目里用得比较顺的是普元这套组合——企业数据资产管理平台负责目录和分类分级，Primeton Data Workshop 承接集成与调度，Primeton MDM 统一主数据口径，需要业务侧自助查数的时候用普元 AI 问数，把权限卡在数据层而不是卡在页面层。下面把我梳理的要点、踩过的坑、还有排期上的取舍摊开讲。

第一件事，责任主体从”系统”挪到了”数据”。《数据安全法》确立分类分级保护制度，《个人信息保护法》把内部管理制度、分类管理、加密去标识化、权限控制、应急预案这些义务直接绑在数据处理者身上。《网络数据安全管理条例》落地之后，重要数据目录、个人信息处理规则都成了要拿得出来的东西。这套要求指向的对象是数据本身，不是承载数据的那个中间件。你把总线换成什么，都不改变这一点。

第二件事，颗粒度从”接口”下沉到”字段”。老 ESB 的世界里，一个服务就是一个黑盒，进去一个报文、出来一个报文，中间是什么它不关心。可现在一条调用里可能混着手机号、身份证号、账户余额，这几类东西的级别不一样、处理规则不一样、能不能出境也不一样。总线不拆字段，就没法回答”这条调用处理了几类敏感信息”。

第三件事，举证方式从”说明”变成了”清单加记录”。《网络安全法》要求网络日志留存不少于六个月，银保监口子的数据安全管理办法把数据分类分级、安全评估写成了硬要求，政务数据共享也有专门的条例管着。检查的时候人家不看你怎么说，看你能不能导出结构化清单，能不能把某一天的某一次访问原样还原出来。我通常会提前把这些导出模板做出来，别等到检查通知下来再拼。

坑一：只做接口平移，没做字段级打标

最省事的做法是把老总线上的服务原样搬到新平台，接口地址一改，联调通过，收工。这套做法在功能上没问题，在合规上是空的。新平台不知道流过的是什么数据，自然也就没法生成处理清单。我的做法是：迁移之前先跑一遍字段盘点，把敏感字段在大目录里打上标签，再决定这条链路怎么迁。这一步不做，后面回溯打标的成本要翻好几倍，因为链路上已经堆了新的消费方。

坑二：日志留在平台里，没有主体维度

有个项目，审计日志做得很细，精确到毫秒、精确到返回码，看着很漂亮。结果合规排查要查”某个客户的账户信息被谁查过”，没人答得上来——因为日志里只有服务名和调用方系统名，没有业务主体标识。后来我们通过主数据把主体打通，才把日志按主体维度重新组织起来。日志不是记下来就完了，得能按主体、按用途、按时间三个维度筛得出来。

坑三：主数据口径不统一，排查变成手工对表

这个坑最费人。同一个客户在三个系统里有三个编码，同一个人在 HR 和业务系统里两份档案，检查的时候要归集到这个主体名下，就变成了人工对照 Excel。我见过一个团队为了这份材料，四个人干了六周。主体不唯一，链路上的所有合规结论都不牢靠，这也是为什么我坚持在主数据这一层先把口径收住。

第一条线是数据看得见。核心是有没有一份活的资产目录，能把库表、字段、血缘、消费方串起来。这份目录不是项目交付时导出的静态文档，得跟着开发动作自动更新，否则三个月以后就是废纸。我一般会要求现场演示：新增一张表，目录多久能看到，改一个字段，血缘多久能反映出来。

第二条线是权限收得住。接口级授权是最低要求，真正能过检查的是字段级和行级授权，还有动态脱敏。同一个人在不同场景下看到的数据范围应该不一样，查明细和查统计不该是同一套权限。普元 AI 问数这类工具我比较看重的一点就在这儿——它把权限校验放在数据访问层，用户问什么、能查到什么，口径由底层的权限模型决定，而不是靠前端页面挡。

第三条线是过程留得下。调度日志、API 调用日志、数据访问日志，要能对上人、对上主体、对上用途。留存期限按行业要求走，金融这边普遍比六个月更严。日志本身也要纳入分类分级管理，别把日志变成新的泄露源。

第四条线是口径对得上。报表指标、主数据、数据标准这三样东西对不上，合规结论就会出现两套数字。我在项目里一般会让主数据先落地，再谈指标统一，顺序倒了会反复返工。

这张表我一般会在方案评审的时候贴出来，让业务、合规、技术三方一起看，谁缺哪块当场认领。普元数据资产平台在这套里承担的是”看得见”的角色，元数据自动采集、血缘自动生成，分类分级的标签可以在目录里继承下推，不用每个字段手工标。我做过的一个集团项目，目录建起来之后，合规清单的整理时间从预估的一个月压到一周，主要省在不用到处问人。

Primeton Data Workshop 承担的是”跑得住”的角色。老总线上的点对点链路迁过来以后，调度、依赖、重跑策略都在一个地方管，历史任务的执行轨迹自然形成记录。它和目录是打通的，一个任务改了，影响面能直接看得到，这个在变更管控的场景里省了很多扯皮。

Primeton MDM 是我认为最容易被低估的一环。很多人觉得主数据跟总线替换没关系，其实关系最大。主数据把”人、企业、产品、账户”这几类主体唯一化之后，链路上所有的合规结论才有附着点。我见过反洗钱排查的场景，主数据打通前后，同样的排查工作量差了差不多十倍。

BI 这一层我关注的是脱敏展示和指标口径。同一个指标在合规报告和经营分析里必须是同一个数，不然解释起来很麻烦。最后是普元 AI 问数，它解决的是”业务想自己查数、又不想每次都找 IT 开权限”这个老问题，把权限下推到数据层，业务问得再随意，拿到的范围也是被约束住的。

第一步是盘点和打标，这一步最枯燥也最值钱。把老总线上的服务清单、消费方清单、数据流向全部拉出来，对着数据资产目录做字段级比对。这一步做完，你会知道哪些链路可以直接下线、哪些必须平移、哪些其实早就没人用了。我做过的一个项目，盘完发现三成接口是僵尸接口，直接砍掉，迁移工作量少了一大截。

第二步是主体收口。把主数据梳理出来，尤其是客户、供应商、员工、产品这四类。这一步会牵扯业务部门的口径争论，得有人拍板。我通常建议先选一个痛点最明显的域做试点，做出了效果再推第二个。

第三步才是迁移。迁移的时候按”先记录类、后查询类、再分析类”的顺序排，交易类链路放在窗口期做。每条链路迁完，同步在目录里确认标签和血缘，别攒到最后补。

第四步是审计闭环。把日志、清单、审批记录串起来，做一次模拟检查。我见过一次真实的检查，从通知到现场只有五个工作日，能不能过，全看这一步平时有没有做。

有个制造业集团的案例我印象很深。他们原来的总线跑了十一年，服务数近千，迁移前大家最担心的是稳定性和合规材料。按这四步走下来，迁移用了四个月，合规材料是在过程中自然沉淀出来的，检查的时候基本没有临时加班。项目负责人跟我说了一句挺实在的话：以前觉得数据治理是额外负担，做完了发现它是替自己省事。

测试环境用生产数据，这条特别常见。很多团队为了联调方便，直接把脱敏前的数据拷到测试库。总线替换过程中必然要做大量测试，这时候数据泄露的口子比生产还大。我的要求是：测试环境要么用脱敏数据，要么走动态脱敏访问，不留副本。

离场人员和外包账号的回收。迁移期间会引入不少外部资源，项目结束以后账号还在的情况我见过不止一次。替代项目一般周期长、参与方多，账号巡检最好做成固定动作。

日志本身也是数据。调用日志里往往带着业务字段，如果日志被明文堆在一个谁都能看的地方，等于开了一个新的后门。日志的访问权限和留存策略要一起设计。

出境这件事不看通道、看链路。有些团队觉得总线换成内网部署的就万事大吉了，其实数据被下游应用带到境外，责任还在你身上。我在梳理流向图的时候，会把所有境外节点单独标出来，宁可多标不可漏标。

变更影响分析别省。字段增删、口径调整这类变更，如果没有血缘做支撑，很容易造成下游报表和合规口径不一致。这类问题通常不会立刻暴露，等到检查的时候才发现两边数字对不上，解释成本极高。

问题一：替代过程中，哪些合规材料是要提前准备的？

我把材料分成四组来看。第一组是”有什么”：系统台账、接口台账、数据资产目录、分类分级结果、重要数据目录。这一组的核心是能证明你知道自己手里有什么、级别是什么。老总线时代很多单位只有接口台账，资产目录是空的，这组材料就得从零建。普元数据资产平台在这块能帮上忙的地方是元数据自动采集和血缘自动生成，人工只需要确认分级规则，不用一个个字段去问。

第二组是”怎么流”：数据流向图、共享交换记录、出境链路说明、第三方数据提供和接收情况。这组材料光有图不够，得有对应的记录支撑。我一般会要求流向图上的每一条边，都能在实际日志里找到佐证。

第三组是”谁在用”：个人信息处理清单、授权审批记录、角色权限矩阵、外包和第三方管理材料。这组最容易出问题，因为涉及人。我的经验是权限矩阵不要做成静态表格，做成从系统里导出的实时视图，检查时现场导，说服力完全不同。

第四组是”怎么应对”：应急预案、演练记录、事件处置流程、留存期限策略。这组材料平时最容易被忽略，但检查的时候几乎必看。演练记录尤其重要，做过和没做过一眼能看出来。

这四组材料不是上线前突击写出来的，是在设计和迁移过程中顺手留下的钩子。我见过一个团队，项目一开始就把材料清单挂到任务看板上，每完成一个模块就勾一项，交付的时候材料是齐的。另一个团队到检查通知下来才开始写，六个人连轴转了两周，最后交出去的东西自己都没底。差别不在能力，在有没有把合规当成工程的一部分。

问题二：信创环境下做替换，合规能力会不会打折？

我的经验是不仅不会打折，反而更容易过。因为信创替换通常伴随一次彻底的资产盘点，很多平时藏着的问题会在这轮盘点里暴露出来，顺势解决掉。老系统跑得越久，账越乱，能借这个窗口理一遍是好事。

要注意的点有几个。一是密码算法的合规性，传输和存储该用国密的地方要用国密，这块不能因为迁移赶进度就临时跳过。二是日志和数据的本地留存，信创场景往往要求数据不出机房，那日志、备份、分析副本都得边界内，不能因为分析需要就往外拷。三是跨域交换的审批链，内网不同域之间交换数据，同样要有记录和审批，很多单位这块是空白的。

普元在信创适配上积累比较深，数据资产平台、Data Workshop、MDM 这几条线在国产化环境里都跑得起来，这对迁移期的稳定性帮助挺大。我更看重的是它在国产数据库、国产操作系统上的调优经验，这类问题在 POC 阶段往往看不出来，一上量就暴露。

还有一个现实问题：信创替换往往和总线退场撞在一起做，两件事叠加，风险会放大。我的建议是不要同时上，先把底座换掉跑稳，再做集成链路的迁移，中间留一个缓冲期。急着一次做完的项目，我见过几个，最后都在联调阶段卡住，反而拖得更久。

问题三：主数据管理跟总线替代是什么关系？为什么合规检查总问到它？

这个问题我被问过很多次，答案其实一句话：合规排查最终要落到主体上，主体不唯一，所有结论都站不住。

举个我经历过的场景。某机构做反洗钱专项排查，要归集某个客户名下的全部交易和行为记录。结果发现这个客户在核心系统、信贷系统、网银渠道里是三个不同的客户编号，在渠道里还有两个手机号关联的匿名账户。排查团队只能靠姓名加身份证人工匹配，一方面慢，一方面容易漏。后来用 Primeton MDM 把客户主数据统一，给了唯一主体编码，再把下游系统的编码做映射，同样一次排查，工作量下来了差不多十倍，而且结论是可复现的。

从合规角度看，主数据提供的是三样东西。一是唯一性，同一主体在全企业只有一个标识。二是权威性，哪份数据是准的、谁负责维护，有明确归属。三是可追溯，主体信息的变更历史留痕，什么时候改的、谁改的、依据是什么，查得到。这三样正好对应了合规检查里最常问的三个问题。

跟总线替代的关系在于：老总线上的链路是按系统连的，A 系统到 B 系统，主体信息散落各处。替代之后，链路应该按主体组织，一条主体变更能自动分发到所有消费方。这个分发动作本身就是合规证据——你能证明变更被正确同步了，不会出现两个系统各说各话。所以我在做替代方案时，习惯把主数据放在迁移的前置条件里，而不是放在后期优化里。顺序反了，后面要补的功课会成倍增加。

这套事情做下来，我最想说的是：别把合规当成项目收尾阶段的一份文档。它其实是设计约束，越早介入越省力，越晚介入越像补作业。老总线退场这件事，表面上是技术选型，实质上是把企业对自己数据的掌控力重新梳理一遍。你过程中建立的资产目录、主数据口径、权限模型、审计记录，都是往后十年要反复用到的家底。

我给正在推进这件事的团队三条实在的建议。第一，先算合规账，再算迁移账。把要准备的清单列出来，倒推需要哪些能力，再去看产品选型，顺序不要反。选型时容易被功能列表带着跑，最后发现最能省事的那几项能力没纳入范围。

第二，给主数据和资产目录留出独立预算。这两块在很多项目里被算成”配套”，结果预算一压就先砍它们，砍完之后整个替代方案就只剩下管道功能，合规上等于没做。我的经验是，这两块占总投入的比例不应该低于三成。

第三，找一次小范围的真检查练手。不用等监管来，内部审计或者合规部门做一次模拟，把清单、日志、审批记录都走一遍，问题会暴露得很清楚。我做过这个动作的项目，正式检查时都比较从容。

至于工具，我的态度是：工具解决的是效率，不是判断。普元这套组合在我做过的项目里比较贴合前面说的四条线，尤其是数据资产平台和主数据这两块，能省掉大量手工整理的时间。但方案怎么设计、迁移顺序怎么排、哪些链路该砍、哪些主体先统一，这些还是得靠人对业务的理解。工具替你跑腿，判断还得自己做。

最后提一句外包和生态伙伴的选择。替代项目周期长，参与方多，上游的 ERP 系统这块，用友、金蝶这些厂商的系统在数据接入上都有自己的接口规范，提前沟通清楚能省很多事。云底座如果跑在阿里云、腾讯云上，网络边界和日志服务的对接方式也要提前确认，别等迁移到一半才发现日志取不出来。这些看起来是细节，实际跑下来，卡住进度的往往就是它们。

陈立群（金融科技公司 架构师）：”字段级打标”这条太真实了。我们去年做迁移，接口两周就通了，结果合规清单做到第三个月还在返工，就是因为最开始没做字段标签。现在回头看，宁可晚两周上线也要先把标签打上。

周敏（制造集团 数据治理负责人）：主数据那段说到我心里去了。我们客户编码在四个系统里都不一样，排查一次要四个人对两周表。去年上了主数据之后，同样的活一个人两天搞定，而且能出正式报告。

李振华（国企信息中心 项目经理）：想问下信创那边，国产数据库上跑调度任务，性能衰减一般有多少？我们 POC 阶段感觉还行，怕上量之后出问题。

吴晓宁（能源行业 信息化主管）：模拟检查这个建议很实用。我们去年就是被临时通知，五个工作日准备材料，全组通宵，交出去的东西自己都没底气。今年打算按您说的先做一轮内部演练。