先说这块模块在系统里的位置。它多数时候不在主流程的页面上而是挂在旁边业务照常走日志在旁边记。这个位置决定了它有两个硬要求——写入要轻别拖慢主流程查询要独立别和业务抢资源。两条叠在一起比较自然的落法是把写入和查询拆成两条链路各走各的。下面按这两条链路分别说。其一写入端放在哪一条日志带哪几样写入端的一个常见误区是在业务代码里顺手写一行落库。业务一多日志的字段就各写各的格式五花八门事后想统一很难。更稳的做法是抽出一个事件业务侧只管把「发生了什么」抛出来记不记、怎么记、落到哪交给一个独立的写入服务去接。一条日志里至少带这几样op_user谁、op_ts什么时候全局统一到一个时区、op_type做了什么用受控枚举别用自由文本、before_val与after_val改动前后各是什么。如果一次操作横跨几张表还要再加一个txn_id把同一次操作串成一组。少了它事后想还原一次改动就得靠人工拼图。写入做成异步也是常见选择。日志先投进队列由消费端落库。好处是主链路不被拖累代价是查询会有延迟一般在毫秒级到一秒出头。这个延迟能不能接受取决于日志拿来做什么——事后审计没问题指望它做实时拦截就不合适。其二查询端怎么切出来查询端如果和写入共用一个库、一张表量一上来两边就会互相影响。比较稳的做法是把日志单独落一个库甚至落在与业务库物理隔开的实例上。写入只对业务负责查询只对读日志的人负责中间用一个边界隔开。查询本身要解决的事是把同一次操作串起来。前面那个txn_id就是为此准备的一次改动产生多条日志按它分组就能还原这次改动的全貌。此外还要支持按操作人、按时间范围、按操作类型这几个维度过滤——这三样基本覆盖了日常排查的用法。再往深一层日志表通常会随时间膨胀。按时间分区、冷热分层是常见处理近期的留在快存储里随时可查久远的归档到便宜的介质上按需调取。保留期定多长跟业务对追溯的要求有关不必一刀切。其三两条路分开之后还差什么链路拆开了还有几件收尾的事。一件是查询权限。日志里往往带着操作人、客户标识这些信息谁能查全量、谁只能查自己名下的得分开。这一层比较稳妥的是和业务侧的权限体系保持同源别各建一套否则同一件事要在两处维护、两份口径。另一件是日志自身不能被随意改写。常见做法是只追加不修改写入后不提供更新与删除接口需要更正时另写一条更正记录。这样即便有人动过系统也不至于把痕迹一起抹掉。还有一件是量与成本的平衡。不是所有动作都值得逐条落盘可以按重要性分级涉及费用、涉及权限变更、涉及资料导出的动作逐条留高频的纯读操作聚合统计即可。分级之后存储压力会小很多真正要看的那一刻也不会缺料。其四字段设计定了才谈得上查不少团队是先上功能、后补日志补的时候才发现关键的几个字段当初没记。比如只记了「改过」没记「改前是什么」只记了时间没记时区一次操作拆成几条却没有能把它们串起来的那一列。这几种情况下日志表看着是满的真要还原一个动作还是凑不齐。所以这块的设计动作比较合适的是和业务功能一起做而不是等出问题再回头补。写入时多带一个字段成本很低事后要回填历史基本不可能。收尾能对上靠的是结构回头看这两条链路写入端解决「记不记得住」查询端解决「找不找得到」。两头分开各自的容量、性能和权限才好分别设计。至于日志里能不能还原出「是谁、在什么时候、动了什么」其实在写入那一刻的字段设计上就定了——后面再怎么查也查不出当初没记的东西。操作日志审计要能对上靠的是结构不是态度。这一块鲲极鲲鹏的鲲在实现上的处理是把写入与查询分别落在独立服务上用事务号把一次操作串成一组保留期与分区策略交给使用方按自己的追溯要求去定不预设一个统一的默认值。以上为一类模块实现方式的整理供技术同行参考。