# 為什麼造一個 kitchen-sink 框架

> gortex 是研究用的 kitchen-sink 框架。當目標從單一微服務的輕量化轉向跨服務的一致性與治理，框架層選擇集中複雜度，用維護負擔換強制一致、內建可觀測性與依賴集中管理。

原文：https://sheng.page/posts/gortex-why-kitchen-sink-framework/ · 發布：2026-01-11 · 作者：Sheng

現代 Go 社群偏好小而組合的庫，這在微服務裡是對的。但情境換成平台團隊，目標就從「輕量」變成「強制一致性」。gortex 復刻的正是後者的思維。

> 前置閱讀：〈[net/http 與 middleware 模式](/posts/go-net-http-and-middleware/)〉、〈[struct tag 與 reflect](/posts/go-struct-tags-and-reflection/)〉、〈[interface 與組合](/posts/go-interfaces-and-composition/)〉、〈[goroutine 與 channel](/posts/go-goroutines-and-channels/)〉、〈[記憶體與併發原語](/posts/go-memory-and-sync-primitives/)〉

## YAGNI vs Platform Engineering

Go 社群的主流是把標準、小巧的庫組起來，像 Go 1.22+ 的原生 `ServeMux`、或 `chi`。對單一微服務來說，這完全符合 YAGNI：不需要的東西就別先蓋。gortex 同意這個判斷，在那個情境下。

但把鏡頭拉到平台工程（大型基礎設施團隊），目標就不同：轉向跨幾十個服務強制一致、高可觀測。kitchen-sink 框架回答的是這一題，不是微服務那題；同一個設計，放在微服務是過度設計，放在平台治理才是對的場合。

## 一致性、可觀測性、依賴收斂

gortex 把複雜度刻意集中到框架層，換三件事（架構哲學文件講得很清楚）：

1. **強制一致性**：自訂 `Context`、強制綁定的 `Config`、統一的 `Logger`，讓跨部門、跨服務的程式碼在處理請求、寫 log、讀設定時長一個樣，維運跨專案除錯的認知成本就低。Config 支援 YAML / `.env` / 環境變數混搭覆蓋，正是為了 K8s：本地讀設定檔、上線同一個 image 改由 K8s 注入環境變數，兩邊共用同一套解析。

2. **內建可觀測性**：分散式 tracing（Jaeger / OpenTelemetry）、httpclient 連線池指標、內建 `/_routes` 與 `/_monitor` 端點，全部框架底層吸收。業務開發者不用每開一個新專案就重接一次 Prometheus 或 tracing middleware。

3. **依賴收斂**：路由、參數綁定、中介層都收在框架內。遇到資安漏洞或要全域改行為（改 CORS 預設、調全域 timeout），只要升框架版本，不用去每個 repo 逐一追它用了哪套第三方庫。

```go
app, _ := app.NewApp(app.WithHandlers(&HandlersManager{}))
// 路由、Context、Logger、tracing、/_monitor 都在這一層之下，業務碼不重接
```

## 權衡與技術債

把複雜度留在框架層，對業務端友善，但框架自己要扛高維護責任：

- **與標準庫解耦**：自訂 `Context` 換來一致性，代價是社群那些針對原生 `http.Handler` 寫的 middleware 不能直接套，得自己做轉接層。
- **維護成本**：自維 segment-trie 路由器與 HTTP client 連線池，等於要自己處理極端邊界與效能瓶頸，像 goroutine leak、惡意連線、慢消費者。這些後面逐篇拆：路由比對在〈[Segment-trie 路由器：不靠正則的匹配](/posts/gortex-segment-trie-router/)〉、Hub 的 graceful shutdown 在〈[WebSocket Hub：Go 版 Actor 模型](/posts/gortex-websocket-actor-hub/)〉、安全預設在〈[安全中介層全家桶：CORS / CSRF / JWT / rate limit / binder](/posts/gortex-security-middleware-suite/)〉。

天下沒有白吃的抽象。整合帶來的好處，是用框架層的維護負擔換來的。

## 定位：研究與紀錄

直說：gortex 不是要跟 Gin、Echo 或標準庫競爭的開源框架。它是一個 reference implementation，主要由 AI 協助、在本地復刻過去那種「通用基礎設施框架」的架構哲學，**研究與紀錄用途，不為 production**。它要展示的是一件事：當系統開發的重點從「單一微服務的輕量化」轉向「跨服務的基礎設施統一與治理」，框架層會被迫做出哪些設計決策與取捨。


## 補充筆記

- 小庫組合在微服務是對的（YAGNI）；kitchen-sink 是回答另一題：跨服務的一致性與治理。
- 三支柱：強制一致性（Context / Config / Logger）、內建可觀測性（tracing / metrics / `_monitor`）、依賴收斂（改一次框架，不用追每個 repo）。
- 代價誠實列出來：與標準庫解耦要 adapter，自維 router 與連線池要扛邊界與效能。
- 定位是 reference implementation，研究與紀錄，不是 production 框架。
- 接下來幾篇逐一拆這些決策怎麼實作，從〈[Struct tag 宣告式路由：reflect 實戰](/posts/gortex-struct-tag-routing/)〉開始。

原始碼：[yshengliao/gortex](https://github.com/yshengliao/gortex)。

---

> 想法與技術判斷出自 Sheng，和 Claude 一起起草 · 環境 Go 1.24（gortex go.mod）· 本系列為事後回填整理 · 列入 20260613 blog 翻新計劃，新漆未乾。