Go Microservice Production Readiness Scoring¶
概念概覽
六維度評分框架¶
核心知識¶
六維度評分框架¶
| 面向 | 權重 | 常見問題 |
|---|---|---|
| 資料庫架構 | 25% | 核心 table 未做 HASH 分區（inventory、currencies、heroes），autovacuum 和 index bloat 在高 CCU 下成為寫入瓶頸 |
| 快取策略 | 20% | write-through cache 每次 inventory 寫入觸發 5 個平行 DB 查詢，1M CCU 下多出約 20K queries/sec |
| 應用架構 | 20% | adapter 接線錯誤、ConfigManager fail-open 在 fail-closed 依賴場景 |
| 可觀測性 | 15% | cleanup success gauge 語義錯誤，lock 失敗不應更新 success counter |
| 韌性 | 10% | Redis 故障期間 rate limiter fail-open，所有速率限制被旁路 |
| 安全性 | 10% | — |
關鍵 trade-off¶
- fail-open vs fail-closed：Redis 故障 rate limiter fail-open 是刻意設計（可用性優先），但 ConfigManager fail-open 在有 fail-closed 依賴時不可接受
- write-through cache：提供更快的後續讀取，但每次寫入多 5 個 DB 查詢，需在 CCU 規模下重新評估
- 不分區 player 核心 table：簡化 schema，但 1M CCU 下寫入瓶頸風險高
建議執行節奏¶
每個 sprint 結束時執行一次，特別關注分區策略和連線池設定是否隨 CCU 目標調整。
經驗教訓¶
-
player 核心 table（inventory, currencies, heroes）未做 HASH 分區是 1M CCU 寫入瓶頸的主要風險
-
write-through cache 的代價在高 CCU 下被放大，每次寫入觸發的平行 DB 查詢數量需精確計算
-
生產就緒評分應定期執行，而非僅在上線前做一次
常見陷阱¶
-
只看整體分數而忽略各維度權重，資料庫架構佔 25% 最重，分數低時影響最大
-
高測試覆蓋率（如 1071 個測試）容易給人虛假的安全感，無法替代 JIT 盲點測試
最佳實踐¶
-
CCU 目標確定後，立即審查 player 核心 table 的分區策略
-
write-through cache 在設計時就計算寫入放大係數（N 個平行 DB 查詢 × 預期 write QPS）
-
fail-open 元件清單應在設計時明確列出，並確認其下游是否有 fail-closed 依賴
相關概念¶
- ConfigManager Fail-open Anti-pattern
- JIT Blind-spot Testing
- postgresql-table-partitioning----dangling-------dangling---
- redis-cache-strategy----dangling-------dangling---
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- Production Readiness Audit Methodology — 共享：
1m-ccu,audit,production-readiness/ 獨特：p0-p1-p2,parallel-agents - PostgreSQL Write Capacity Planning — 共享：
1m-ccu/ 獨特：capacity-planning,database - Release Gate Layering — 共享：
production-readiness/ 獨特：go-live,p0
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-17 | 056f9176-f6b2-4663-9b7e-19679837f204 | 提供了一套針對 1M CCU 目標的 Go 微服務生產就緒六維度評分框架，含具體權重與常見扣分點 |