📚 课程目录第2章审计接口整体架构

审计接口整体架构：系统分层、模块划分、数据流向与交互关系

说实话，很多同学在做 DLP 外发审计闭环时，一上来就直接啃接口文档、写代码，结果常常被复杂的调用关系搞晕。我个人习惯——先啃透架构。你只有把全局的骨架看清楚，才知道哪个模块该跟谁说话，数据怎么流转，出了问题去哪里排查。

这一章我就带你从高处俯看整个审计接口的架构。不会太深，但核心的分层、模块、流向我都会讲清楚。嗯，咱们开始。

我把审计接口体系分为四层。每层只管自己的一摊事，层与层之间通过明确的接口契约通信。我记得在早期一个项目中，我们硬是把所有逻辑堆在一层，结果后期改一个字段，上下游全崩。后来我重构时强行切分了这四层——再也没有因为改需求而加班到凌晨。

核心思想：每一层只依赖下一层提供的接口，禁止跨层调用。例如业务层不能直接调用数据层的 API 获取用户信息，必须经过数据访问服务。这样做的好处——任何一层替换实现，其他层不用动。

分层定了，咱们再看每一层里具体有哪些模块。我跟你细说几个关键模块。

它是整个审计的大脑。哪些文件外发需要审批？阈值是多少？触发后走自动放行还是人工审批？都由它控制。我在项目中遇到过，策略模块的数据结构如果设计成平铺的 key-value，后期维护就是噩梦。建议用规则引擎（比如 Drools 或自行实现的 DSL）来表达策略，扩展性会好很多。

外发审计说到底是记录“谁、在什么时候、用什么方式、把什么文件、发到了哪里”。日志模块要保证写入性能高、查询快。我的做法是：实时写入用 Kafka，批量落盘到 ES，再配合时间分区表做冷热分离。

遇到高风险外发请求，不能直接放行，得进入审批流程。这个模块要支持动态审批人（比如按部门主管、安全团队）、超时自动升级、加签会签。说白了就是一个工作流引擎，但不需要太重的框架，用状态机模式就能搞定。

审批结果、审计告警、闭环反馈都需要通知。支持邮件、企微、钉钉。反馈闭环是审计接口的终点——请求方必须收到“成功/失败/原因”，否则整个审计链条就断了。

一句话概括：外发请求到达接入层 → 业务层进行策略匹配、审批流转 → 数据层记录日志 → 最终通过通知模块反馈给请求者。

具体数据流向我画了一张图，你看看。

从上往下看：外发请求先被接入层拦截，做身份校验、频率限制；合规的请求转发到业务层。业务层里，策略匹配先跑——如果命中低风险策略，直接放行并记录日志；如果命中高风险策略，转到审批流转。审批通过后，再记录日志，最后通过通知模块返回结果。数据的写入与查询都落在数据层。

注意逆时针那条虚线——闭环反馈。很多人只关心请求怎么进来，忽略了怎么出去。我曾经犯过这个错，上线后发现业务方一直收不到回调，排查半天才发现通知模块没接入。所以你在设计接口时，务必留好异步通知的 callback 地址或消息队列。

刚才的流程图里，大部分箭头是同步的（实线），但日志写入和通知发送我推荐走异步。为什么？

经验建议：接入层用同步，业务层内部可以根据场景混用。比如策略匹配同步，审批流转可以异步（先返回“待审批”，审批完成后再回调）。数据写入一定要异步，否则高并发下数据库容易被打死。

各层之间怎么通信？我列一个我常用的对照表。

接口契约建议用 OpenAPI（Swagger）统一管理。我在团队里推行过一段时间，每次改动都要更新 yaml 文件，然后自动生成客户端代码，联调效率高了不少。

我曾经踩过的一个坑：日志模块直接写 MySQL 单表，数据量大了之后查询超时，还影响了业务链路的正常读写。后来我改成写 Kafka 再消费到 ES，配合日志归档策略（30 天热数据保留在 ES，历史数据转存对象存储），问题才彻底解决。

再给你几个实用的建议：

好了，审计接口的整体架构就说到这儿。你如果能把这张图刻在脑子里，后面写代码调接口就会特别顺。记住一句话——架构清晰，代码才不会散架。