Airlock 是一個面向多服務入口的輕量網關。它不承載業務邏輯，只負責判斷一個請求是否應該進入、應該進入哪裡，以及進入之後如何被觀察。
項目最初的動機很直接：當服務數量增加後，鑑權、限流、超時、重試和日誌會在每個服務裡重複出現。與其讓每個團隊各自維護一套策略，不如把這些邊界問題收斂到一層。
請求如何通過
一次請求會經過固定的幾段路徑：
- 監聽器接受連接，解析協議與基礎元數據；
- 路由層根據 host、path 和 header 選擇上游；
- 中間件鏈依次處理 request id、身份、限流、超時預算和重試策略；
- 上游選擇器讀取健康狀態，選擇一個可用實例；
- 響應返回時記錄狀態碼、延遲和上游信息。
路由和中間件都通過配置描述，而不是寫死在代碼裡。目標是讓新增一個上游只需要改配置，不需要重新理解整個入口。
邊界與取捨
網關最容易犯的錯誤是慢慢長成第二個業務系統。Airlock 明確不處理業務編排、不做數據庫訪問，也不替上游決定領域規則。
它只做幾件事：
- 認證與身份透傳；
- 按路由和租戶限流；
- 為每條路由設置獨立的超時預算；
- 對冪等請求做有限重試；
- 在上游異常時快速失敗並熔斷。
重試只發生在明確可重試的請求上。否則，網關會把一次失敗放大成多次寫入。
可觀測性
每個請求從入口開始攜帶 request id，並在日誌、指標和 trace 中繼續傳遞。除了常規的 QPS 和錯誤率，還會分別記錄上游延遲、限流命中、重試次數和熔斷狀態。
健康檢查不只看端口是否存活，還會觀察最近一段時間的錯誤率和延遲。一個能接受連接但持續超時的上游，不應該繼續接收新請求。
當前狀態
目前正在搭建路由、中間件鏈和配置熱更新，限流先支持進程內計數，再接入 Redis 做多實例共享。下一步會補充管理接口、灰度路由和壓測腳本。
好的網關在正常時應該是隱形的；出問題時，它必須把原因說清楚。