← 返回项目列表
业务服务
审计日志服务
由 12 个微服务共同发布的全平台审计追踪
从零构建 · 设计全平台事件契约 · 2024.10 — 2025.08
Go go-zero gRPC Kafka MySQL/GORM pprof
项目概述
平台上每一次后台写操作都会产生一条审计事件。我设计了事件契约及其依赖的 gRPC metadata，重写了共享发布组件，编写了 diff 工具，并构建了消费服务及其查询 API。
核心技术亮点
01
Kafka 事件契约，携带操作员、IP、请求路径、模块/动作和 trace ID，以及变更前后快照
02
共享发布组件目前被 12 个微服务调用；JSON diff 工具只存储发生变化的字段，并附带可读标签
03
消费者通过并行 gRPC 调用为每条事件补充操作员和操作对象的详细信息
04
按租户隔离的查询 API，对租户隐藏平台管理员的操作
05
用 pprof 定位了一次生产环境内存泄漏：按值复制的 RPC 客户端每处理一条消息就新建一个 gRPC 连接
核心实现
1
审计即平台契约
一个 Topic、一套消息 schema 和一组 gRPC metadata key，所有服务以相同方式使用，因此每条审计事件都能说明谁、从哪里、在哪条 trace 下做了什么。
Why: 只有每个团队都一致地记录，审计追踪才有价值；共享的契约和发布组件让这成为默认行为。
Result: 已有 12 个服务接入发布。
2
内存泄漏排查
负载下内存持续增长。我开放了 pprof，分析 heap profile，发现 RPC 客户端封装是按值传递的，因此其延迟创建的连接从未被缓存。修复方式是改用指针接收者、提前初始化客户端，并从热路径中移除大体积快照字段。
Why: 临时的定期 GC 掩盖了症状；性能剖析找到了根因。