需求背景
系統包含多個應用伺服器，需統一管理資料庫存取，引入快取層以降低 DB 壓力，避免各服務獨立開啟連線池造成資源浪費。
推薦架構模式
1. 獨立資料存取微服務
- 將所有 SQL/NoSQL 操作封裝為獨立服務（RESTful API 或 gRPC）。
- 應用服務透過 HTTP/2 或 gRPC 呼叫，資料服務內部管理連線池、快取、讀寫分離。
- 優點：職責單一、可獨立擴展、技術棧解耦。缺點：網路延遲、序列化開銷、運維複雜度提升。
2. 共用資料庫存取函式庫 + 分散式快取
- 將 DAO、Repository 封裝為共用 Library (JAR/AAR/NuGet)，各服務引用。
- 快取層使用 Redis Cluster / Memcached，Library 內部統一處理快取邏輯（Cache-Aside, Read-Through）。
- 連線池配置集中管理（如 HikariCP 參數外部化至設定中心）。
- 優點：部署簡單、效能高（本地呼叫）、開發體驗好。缺點：Library 升級需協調所有服務、快取一致性需自行處理。
3. API Gateway + BFF (Backend for Frontend) 模式
- 前端/行動端呼叫 BFF，BFF 編排多個下游微服務（含資料服務）回傳聚合資料。
- 資料服務專注於單一資料域操作，BFF 處理業務編排與資料組裝。
關鍵設計細節
- 連線池隔離：各服務維持獨立連線池，但參數由設定中心下發，避免單一服務佔滿連線。
- 快取策略：熱點資料用 Redis，本地熱點用 Caffeine/Guava Cache 兩級快取；寫入採用 Write-Behind 或事件驅動失效。
- 熔斷降級：整合 Resilience4j / Hystrix，DB 故障時快速失敗、回傳預設值或快取舊值。
- 觀測性：所有 SQL 執行時間、快取命中率、連線池使用率納入 Prometheus + Grafana 監控。
技術選型建議
| 場景 | 推薦方案 |
|---|
| 微服務架構、跨語言 | gRPC + Protobuf 定義資料服務介面 |
| 單體或模組化單體、Java/Kotlin 技術棧統一 | 共用 Library + Redis |
| 需支援多種前端（Web/App/小程式） | BFF + GraphQL 聚合查詢 |
總結
「統一存取層」不等於「單一服務」。視組織架構、團隊規模、技術債務選擇：共用函式庫適合中小團隊快速落地；獨立微服務適合大型組織長期演進。核心在於集中管理連線池、快取策略與觀測能力，而非單純抽象 SQL。
