第2章：现有审计系统架构分析与常见痛点归纳总结

做系统迁移升级，第一步不是写方案，而是把老家伙摸透。

我见过太多项目，上来就画新架构图，结果一迁移才发现旧系统里全是“历史遗留宝藏”——要么数据格式不兼容，要么接口根本没人维护。说白了，你不把现有系统的五脏六腑看清楚，迁移就是个雷区。

2.1 典型审计系统架构全景

国内大部分审计系统，不管是用Java还是.NET写的，架构上都大同小异。我从实际项目里提炼了一套通用分层模型：

这张图我画了好几个项目才定型。你仔细看看，每层之间都有依赖关系。往下层是基础设施，往上是用户界面。数据从底层往上流，指令从上层往下走。

2.2 各模块功能与数据流，你得知道这些

我习惯拆开每层看具体模块。咱们先从最熟悉的业务层说起。

2.2.1 业务应用层——审计员天天打交道的东西

• 审计作业管理：立项、分配、底稿、报告，一条龙。
• 项目管理：进度跟踪、资源调度、成本核算。
• 风险预警：基于规则或模型，自动推送异常。
• 数据分析：抽样、趋势分析、疑点挖掘。

这里有个坑——我见过好几个系统，数据分析模块用的是存储过程直接在库里算，业务层代码反而很薄。迁移的时候，这些存储过程才是最头疼的。

2.2.2 服务支撑层——被忽视的“幕后英雄”

• 工作流引擎：审计流程审批，有的用Activiti，有的自研。
• 权限中心：角色、菜单、数据权限，嗯，粒度非常关键。
• 消息队列：异步通知、日志采集，很多老系统压根没有。
• 报表引擎：润乾、帆软，或者自己写的POI导出。

2.2.3 数据存储层——核心中的核心

数据类型	存储方式	常见容量	迁移关注点
结构化业务数据	Oracle / SQL Server	200GB ~ 2TB	表结构差异、分区策略
审计底稿附件	文件服务器 / NAS	几十TB常见	路径变更、断点续传
日志与审计轨迹	文件或数据库表	日均几百MB	归档策略、清理方案
配置与规则	数据库或XML	通常小于5GB	版本对齐、兼容性测试

2.3 那些你迟早会遇到的架构痛点

你想想看，一个系统跑了五六年甚至十年，能不积累点“技术债务”吗？我个人总结下来，痛点主要集中在下面几个方面。

2.3.1 数据采集性能瓶颈

很多审计系统需要从ERP、财务系统拉数据。老做法是写定时任务，每天半夜跑一次。

• 痛点A：源系统接口慢，一跑就是七八个小时。
• 痛点B：数据量大时直接挤爆内存。
• 痛点C：没有断点续传，半夜跑崩了，第二天谁都不敢动。

2.3.2 数据处理模型陈旧

老系统多用存储过程做ETL，一个过程动不动几百行。逻辑藏得太深，维护成本极高。

举个例子：

-- 典型的“面条式”存储过程
CREATE PROCEDURE sp_ETL_AuditData(@batchDate DATE)
AS
BEGIN
    -- 这里用了临时表，没有索引
    SELECT * INTO #tmp FROM source_table WHERE ...
    -- 这里游标循环，逐条处理
    DECLARE cur CURSOR FOR SELECT ... 
    -- 三百行以后还在处理异常
    ...
END

这种代码，换个人根本不敢改。我建议迁移升级时，能重写就重写，别想着“兼容”。

2.3.3 存储扩容困难

老系统上线时可能只规划了500GB空间，现在业务量翻了十倍。文件存储用的还是单机NAS，一旦磁盘满，整个系统都受影响。

• 扩容要停机
• 备份窗口不够
• 文件路径硬编码在代码里

这些，你迁移的时候都得考虑进去。

2.3.4 权限模型混乱

用户角色混在一起，有的按岗位授权，有的按部门授权，还有按项目授权的。而且很多老系统登录还用的是HTTP明文，密码也没加盐。

2.3.5 日志与审计轨迹缺失

老系统往往只记了操作日志，但谁改了数据、改之前是什么值，完全没有。这在审计系统本身来说，简直是“灯下黑”。

2.4 痛点快速映射与影响评估

痛点	影响范围	对迁移的影响程度	我的建议处理策略
数据采集性能瓶颈	全系统	高	改用增量同步 + 消息队列
存储过程逻辑复杂	数据处理层	高	重写为Java/Python ETL
存储扩容困难	文件服务	中	迁移至对象存储或分布式存储
权限模型混乱	安全模块	中	迁移前做权限治理
日志审计缺失	合规功能	低（但必须补）	新系统统一接入审计日志

2.5 说说我的“三步走”痛点分析法

1. 文档审阅：找老系统所有的架构设计文档、接口说明、数据字典。没有文档的系统，我会让团队直接搭测试环境逆向分析。
2. 现场访谈：找一线审计人员聊。我最怕听到“这个功能我们很少用”或“这里有个bug但没人敢改”。这些都是暗雷。
3. 运行监控：先跑一周的监控，看CPU、内存、磁盘IO、慢SQL。数据不会骗人，比任何文档都真实。

你想想看，这三步走下来，系统的“家底”基本就清楚了。剩下的，就是把这些痛点挨个转化到迁移方案里，变成一个一个可执行的任务。

痛点分析是整个迁移升级的起点。起点偏一点，后面全歪。嗯，这里要特别提醒——别因为赶进度跳过这一步。