4. 现有审计SDK分析：单租户下的问题与挑战
咱们先聊聊单租户时代的审计SDK。说实话，很多团队做多租户改造时，最头疼的就是这块。我去年接手过一个遗留审计系统，代码跑了五年，租户从三家涨到五十家，数据库表里一条审计记录连个 tenant_id 字段都没有。你想想看，当时排查一个用户的操作日志，得从几十万条记录里模糊匹配用户名——效率低不说，还经常窜数据。
单租户下的审计SDK，说白了就是为“一个系统服务一个客户”设计的。架构简单，表结构也简单，所有日志写进同一张表。但业务一扩展，问题就全冒出来了。下面我把常见的“坑”逐一拆开讲。
4.1 租户数据隔离：从“无”到“有”的阵痛
单租户模式下，审计数据天然就没有隔离意识。无论是操作日志、访问记录还是配置变更，全都混合存储。我见过最典型的一个场景：运维同事在后台查某个租户的异常操作，结果 SQL 语句里忘了加租户过滤条件，把其他租户的敏感操作记录也拽出来了。虽然没出大事故，但合规审计时被问了一句——“你们怎么保障租户数据不串？”
核心问题：
- 缺少租户标识字段——表里没有 tenant_id，根本没法区分数据归属。
- 查询无租户过滤——即使后来加了字段，老代码到处是
SELECT * FROM audit_log，改起来动全身。 - 分库分表粒度粗——有些团队强行按租户分表，但审计SDK写死了单库单表，改造成本极高。
tenant_id VARCHAR(64)，但老代码的 SELECT 语句压根没带这个条件。结果上线后租户B能查到租户A的日志，差点被客户投诉。切记：改表结构只是第一步，必须同步把所有查询入口加上租户过滤器，并用单元测试覆盖。
4.2 性能瓶颈：共享池里的拥堵
单租户SDK一般把审计数据存在同一个数据库实例里。租户少时还好，租户一多，写入压力就上来了。我做过一次压测：20个租户同时高频操作，审计接口的 P99 延迟从 50ms 飙到了 800ms。为什么？因为单表写入锁竞争，加上索引维护开销，数据库扛不住了。
| 场景 | 单租户模式 | 多租户期望 |
|---|---|---|
| 写入并发 | 所有租户争用同一张表写入 | 按租户拆分写入通道 |
| 查询隔离 | 大表全量扫描，相互影响 | 按租户分区/分表，互不干扰 |
| 连接池 | 共享连接，一个租户慢查询拖慢全部 | 租户级连接池，限流隔离 |
嗯，这里要注意一个细节：单租户SDK通常会在业务线程里同步写日志。如果数据库抖一下，业务接口也跟着抖。我曾经有个项目，线上突然慢查询，排查了半天才发现是审计SDK在高峰期批量刷日志导致的。后来我们改成了异步队列，才把影响降下来。
4.3 权限模型：一杆子打翻一船人
单租户下的审计权限管理，多数是“一个管理员管所有”。你想想看，A租户的运维人员理论上只能看自己租户的日志，但单租户系统里没这个控制，所有审计日志都在同一个页面里展示。要么全给权限，要么全不给，没有中间档。
典型问题：
- 没有租户级角色定义，审计员能看到所有租户的操作记录。
- 审计日志的查询API没有租户上下文参数，后端无法判断请求来自哪个租户。
- 前端页面也没有租户筛选能力——不是不想加，是后端接口不支持。
X-Tenant-Id 请求头。即使内部代码还没完全隔离，先把通道打通。这样后面改权限时，至少知道是谁在查。
4.4 可扩展性：牵一发而动全身
单租户审计SDK往往和业务代码耦合得很紧。常见写法：在业务方法里直接 auditService.log("操作描述", userId) 。如果后期想扩展审计维度（比如增加地理信息、设备指纹），就得改SDK核心代码，然后波及所有调用方。
- 事件定义无扩展位——审计事件结构写死了字段，新增内容只能往
extra字段里塞JSON，解析时容易出错。 - 存储层不支持热迁移——单表结构说改就改，但几十个租户同时在用，改表结构意味着停机。
- 策略配置硬编码——审计规则（哪些操作需要记录、哪些忽略）写死在配置文件里，不同租户想用不同策略？没门。
4.5 审计日志的可追溯性：混在一起就是灾难
我记得有一次做安全审计复盘，客户要求导出指定时间内某个租户的所有管理员操作。结果数据库里没有 tenant_id 字段，只能靠操作人的部门名称模糊匹配，还漏掉了跨部门协作的场景。审计日志的可追溯性，在单租户模式下几乎等于零——因为你根本不知道这条日志属于哪个客户。
关键缺失：
- 没有租户归属标识，日志回放无从谈起。
- 没有操作链路的全局请求ID，无法串联一次业务操作的所有审计点。
- 日志保留策略全局统一——有些租户要求保留3年，有些要求1年，单租户系统做不到差异化的TTL。
4.6 配置管理：一个配置管所有？不够
单租户下，审计配置是全局生效的。比如“记录所有登录操作”，A租户觉得太细，日志太多；B租户要求更细，连页面浏览都要记。全局配置没法满足差异化需求。我见过最夸张的情况：运维直接在代码里写了一堆 if-else，根据租户ID判断审计级别。你能想象吗？审计逻辑里嵌套了十几种租户特殊处理，维护成本高到头大。
- 数据层面：无租户标识、无隔离、无差异化保留策略。
- 性能层面：共享资源竞争、同步写阻塞、无独立连接池。
- 权限层面：无租户级角色、无租户上下文传递。
- 扩展层面：事件结构僵化、策略硬编码、存储层紧耦合。
- 运维层面：日志追溯困难、配置无法按租户定制。
这些并不是理论问题。我在上一家公司做多租户改造时，光是审计SDK这一块就花了两个迭代。第一个迭代只做数据隔离——给所有审计表加 tenant_id，重构所有查询接口。第二个迭性能隔离——引入写队列和租户级线程池。第三个迭代才开始动权限和配置。
如果你现在正在评估现有审计SDK，我建议你画一张类似的痛点地图，标注出哪些是阻塞性的（不改没法上线）、哪些是优化性的（改完体验更好）。这样改造时才能分清轻重缓急，不至于一上来就想一口气吃成胖子。
嗯，单租户下的问题梳理到这。这些痛点恰恰指明了多租户改造的方向。接下来我们就要针对这些问题，设计一个既隔离又高效的审计SDK方案。