2. 现有SDK架构与局限

咱们先聊聊现在这套审计日志SDK长什么样。说实话，我刚接手的时候第一反应是——这玩意儿太“古老”了。设计还是好几年前的思路，能跑，但跑得憋屈。我带你一层层剥开看看。

2.1 整体架构概览

现存SDK是典型的三层结构：接入层 → 处理层 → 存储层。每一层都干自己的活，但层与层之间耦合度特别高。你改一个接口，后面两层都得跟着调。下面这张图你存着，后面讲局限的时候会反复提到。

2.2 核心组件详解

我记得刚排查线上问题那会儿，花了两天才理清楚各组件的关系。说白了，就这么几个关键东西：

• 日志采集器（Collector）：负责监听端口或文件变化。有几个老版本采集器在Linux下用polling，CPU占用率长期在15%左右。我后来换成了inotify，瞬间降到3%。
• 序列化引擎：早期选的是Java原生序列化，结构紧凑但跨语言一塌糊涂。你想，一个C#客户端发来的日志，这边的序列化器直接抛异常。改协议？那得上下游一起改。
• 本地缓冲区：一个环形内存队列。容量只有1024条，生产速度超过消费速度就直接丢弃旧日志。你说丢失审计日志意味着什么？合规可就泡汤了。
• 文件轮转器：按小时切分文件，超过1GB自动压缩。但轮转逻辑跟文件名硬编码在一起，如果哪天想改成按天、按大小混合策略，就得改SDK源码。

2.3 工作流程

从日志产生到落盘，经过了这么几步。流程本身不复杂，复杂的是每一步都可能“掉链子”。

1. 业务系统调用SDK提供的 AuditLogger.log() 方法，传入日志对象。
2. SDK内部做初步校验：时间戳、用户ID、操作类型是否为空。嗯，这里其实应该做更严格的参数校验，但旧代码里只检查了时间戳。
3. 对象被送入处理层：先压缩（默认gzip），再序列化（Java原生），然后加密（AES-256-CBC）。
4. 加密后的字节流放入内存环形队列。如果队列满了，调用 丢弃策略(DISCARD_OLDEST) —— 你想想，审计日志能被丢弃吗？
5. 后台线程每200ms从队列批量拉取，一次性写入本地文件。写入完成触发文件轮转检查。

2.4 主要局限分析

咱们把问题列个表，这样你看得清楚。我总结成四个维度：性能、扩展性、可观测性、兼容性。

2.5 还有几个“隐秘的角落”

除了上面表里列的，我还有几个比较隐蔽的痛点。你听听

• 日志格式不统一：不同业务团队调SDK时，传了个Map进去，key拼写五花八门。有的用驼峰(userId)，有的用下划线(user_id)。追溯同一个用户的操作时，你根本猜不到哪个字段被他写成了什么名字。
• 加密密钥硬编码：当初开发图省事，把AES密钥直接写在SDK的properties文件里。而且所有实例用的同一个密钥。这要是被攻破，全站审计日志等于明文。
• 缺少优雅退出机制：我记得有一次做维护重启，脚本直接kill -9。重启后发现最后10分钟的文件大小不对，打开一看，文件头损坏——因为缓冲区里的数据没来得及刷盘就被杀了。