← 返回項目列表
業務服務
稽核日誌服務
由 12 個微服務發布的全平台稽核軌跡
從零打造 · 設計全平台事件契約 · 2024.10 — 2025.08
Go go-zero gRPC Kafka MySQL/GORM pprof
項目概述
平台上每一次管理端寫入都會產生一筆稽核事件。我設計了事件契約及其仰賴的 gRPC 中繼資料，重寫共用的發布元件，撰寫 diff 工具，並打造消費服務與其查詢 API。
核心技術亮點
01
Kafka 事件契約，攜帶操作者、IP、請求路徑、模組/動作與 trace ID，以及變更前後快照
02
共用發布元件目前由 12 個微服務呼叫；JSON diff 工具只儲存有變動的欄位，並附上易讀的標籤
03
消費者透過平行 gRPC 呼叫，為每筆事件補上操作者與操作對象的詳細資訊
04
以租戶為範圍的查詢 API，對租戶隱藏平台管理員的操作
05
以 pprof 找出正式環境的記憶體洩漏：以值複製的 RPC 用戶端每處理一則訊息就開啟一條新的 gRPC 連線
核心實現
1
稽核即平台契約
一個 Topic、一套訊息 schema 與一組 gRPC 中繼資料 key，所有服務都以相同方式使用，因此每筆稽核事件都能說明誰、從哪裡、在哪條 trace 下做了什麼。
Why: 唯有每個團隊一致地記錄，稽核軌跡才有價值；共用的契約與發布元件讓這成為預設行為。
Result: 已由 12 個服務發布。
2
記憶體洩漏調查
負載下記憶體持續上升。我開放 pprof、分析 heap profile，發現 RPC 用戶端包裝以值傳遞，導致其延遲建立的連線從未被快取。修正方式是改用指標接收者、提前初始化用戶端，並將大型快照欄位移出熱路徑。
Why: 暫時性的定期 GC 掩蓋了症狀；效能分析才找到根本原因。