待寫章節

• 反向代理的職責（TLS 終止、路由、負載分散、健康檢查）
• 負載分散演算法（round-robin / least-connections / IP hash / consistent hash）
• nginx 實務配置（upstream + health_check + 常見 gotcha）
• 健康檢查路由設計（被動 vs 主動、check interval、unhealthy threshold）
• 和模組二（水平擴展）的銜接：LB 是水平擴展的前提

跨分類引用

• → monitoring 模組四 Collector 架構：Collector 多實例部署時的 LB 設計
• → backend 部署平台：PaaS / container 的 LB 內建 vs 自管
• → infra 模組三：網路地基：ALB 掛在 public subnet、後端在 private subnet 的網路分層設計
• → infra 模組五：入口上 IaC：ALB 的 listener、target group、TLS 與健康檢查在 IaC 裡怎麼描述

待寫章節

• Health check endpoint 設計（什麼算健康、什麼算不健康、check 的深度）
• Liveness vs Readiness（活著 vs 準備好接流量 — Kubernetes 的兩種 probe）
• systemd watchdog + 自動重啟（WatchdogSec + Restart=on-failure）
• Process supervisor 的選型（systemd / supervisord / Docker restart policy）
• Graceful shutdown（收到 SIGTERM 後的清理流程）

跨分類引用

• → monitoring 模組四 Dashboard DevOps：DevOps dashboard 的服務狀態卡依賴 health check
• → backend 部署平台：部署平台的 health check 整合

概念位置

Readiness / Health Check 位在 rollout、load balancer 與 runtime platform 之間，是流量切換前的核心 gate。

可觀察訊號

• 部署後健康檢查綠燈但請求仍大量失敗。
• 新版啟動中就提早接到流量。
• rollout 失敗時缺少可觀測放行條件。

接近真實服務的例子

Kubernetes liveness 通過只代表 process 存活；readiness 通過才代表連線池、依賴服務與必要資料都已準備完成。

設計責任

Readiness / Health Check 要定義檢查內容、容錯窗口與失敗處理，讓 rollout decision 有可信訊號。

概念位置

Health Check 位在 load balancer、platform、diagnostic endpoint 與 application 之間。平台會依這個回應決定是否導流、是否重啟，或是否需要進一步檢查。 可先對照 Histogram。

可觀察訊號

系統需要 health check 的訊號是服務需要一個快速、低成本、可自動化的狀態回應，讓平台不用靠猜測判斷是否正常。

接近真實網路服務的例子

Load balancer 以 health check 判斷 instance 能否接新流量；運維工具以 health check 快速確認服務是否仍回應；Kubernetes 會把 health check 的責任拆到 readiness / liveness / startup probe。

設計責任

設計時要讓 health check 保持簡單、穩定、低成本，並且只反映它被設計要回答的問題。更細的流量條件交給 readiness，更細的存活條件交給 liveness，更完整的操作介面交給 diagnostic endpoint。