3、集成架构设计：系统分层、模块划分、数据流转与接口定义

这一章，我们开始真正画架构图了。说白了，不管你的 DLP 策略多复杂、加密算法多高级，最终都要落在具体的代码分层和模块边界上。我在几个项目里都遇到过这样的坑——架构图画得漂漂亮亮，结果一落地模块相互耦合，数据流乱成一团。今天我们就把它掰开揉碎了讲清楚。

3.1 系统分层：怎么切才不疼？

我习惯把集成架构分成三层：应用层、策略调度层、加密执行层。你想想看，每一层只关注一件事，改动才不容易炸。

曾经有个项目，他们把加密逻辑直接塞进业务代码里，结果换了加密厂商后改了半个月。所以我的建议是：每一层都通过接口解耦，你换底层 SDK 时上层代码一行都不用动。

3.2 模块划分：谁该管什么事？

我一般这样拆分模块：

• DLP 规则引擎模块：负责加载策略、匹配上下文、返回动作（阻断/加密/放行）。
• 加密 SDK 适配模块：封装不同厂商的 SDK，提供统一的 encrypt() / decrypt() 接口。
• 密钥管理模块：对接 KMS 或本地密钥库，管理密钥生命周期。
• 数据脱敏模块：对敏感字段做脱敏处理，比如身份证号只显示前6后4。
• 审计日志模块：记录每次 DLP 决策和加解密行为，方便事后回溯。

嗯，这里要注意：密钥管理模块一定不要跟加密 SDK 混在一起。我记得有一次生产事故，密钥轮转的时候加密 SDK 直接崩溃了，就是因为它们共用了同一份配置。

3.3 数据流转：报文是怎么走的？

我得跟你讲讲典型的数据流转路径。假设用户上传了一个 Excel 文件：

1. 应用层收到文件后，先调用 DLP 规则引擎做内容识别。
2. 规则引擎匹配到“工资单”模板，返回动作：加密并审计。
3. 应用层将文件完整内容传给策略调度层。
4. 调度层检查缓存：这个用户的权限是否有加密密钥？如果没有，调用密钥管理模块获取。
5. 获取到密钥后，调度层调用加密 SDK 适配模块的 encryptFile() 接口。
6. 加密 SDK 将文件加密后返回密文，应用层将其写入存储。
7. 同时，审计日志模块记录：谁、什么时间、对哪个文件、执行了什么操作。

整个过程其实就两个要点：同步调用（业务等待加密结果）和异步审计（日志通过消息队列发送，不阻塞主流程）。

3.4 接口定义：说清楚才能干活

我习惯先定义接口再写实现。下面是我常用的核心接口范式：

// 加密 SDK 适配接口
public interface EncryptionAdapter {
    /**
     * 加密文件
     * @param plainBytes 明文数据
     * @param keyId 密钥标识
     * @return 密文 + 元信息（算法、IV、标签等）
     */
    EncryptionResult encrypt(byte[] plainBytes, String keyId);
    
    /**
     * 解密文件
     * @param cipherResult 密文结果（含元信息）
     * @param keyId 密钥标识
     * @return 明文
     */
    byte[] decrypt(EncryptionResult cipherResult, String keyId);
}

// DLP 规则引擎接口
public interface DlpPolicyEngine {
    /**
     * 根据上下文返回动作
     * @param context 包含用户、文件类型、敏感级别等
     * @return 动作指令：ALLOW / ENCRYPT / BLOCK / AUDIT
     */
    PolicyAction evaluate(DlpContext context);
}

你想想看，接口的参数不要设计得太胖。一旦生产环境需要加字段，你还能平滑升级。我踩过这种坑：一个接口传了10个参数，后来新增了一个“是否强制重新加密”，结果改了所有调用方。

整体架构图

下面这张图展示了我推荐的分层与数据流关系：

接口定义要点总结

最后我把接口设计时要留意的几个点列出来：

好了，这一节的架构核心就是这些。记住：分层是骨架，模块是器官，数据流是血液，接口是契约。按这个思路去设计，你的集成系统想不稳都难。