擴展前先窮盡低成本手段

加實例是有成本的手段，不該是遇到壓力的第一反應。一個健康的擴展決策，會先窮盡零成本或低成本的手段，確認真的不夠了才擴機。以讀取變慢為例，加副本或加機器之前，先做過補索引、讓儀表板改讀預聚合的摘要表、把降採樣 job 調到避開高峰時段——這些預聚合類的手段常常是「加機器前」最有效的降載，做完可能就不需要擴了。擴展的觸發原則是按觀察到的真實瓶頸行動、不按預測搶跑，且在擴機之前先把便宜的優化用盡。

觸發訊號分層，各層對應不同動作

擴展的觸發不是單一訊號、單一動作，成熟的系統分層應對。本站 collector 的 ingestion 就分四層防線，每層有各自的觸發條件與動作：源頭的 SDK 在超過粒度時自動降取樣、單機的背壓與限流在寫入接近滿載時擋、水平擴展在單機 CPU 或連線飽和時加實例、佇列解耦在突發流量超過整個 collector 群的即時處理能力時插入緩衝。訊號從源頭到基礎設施逐層升級，先用便宜的層擋，擋不住才動到貴的層。

共享儲存的擴展也有量化的觸發訊號。collector 的 SQLite 後端撞到「database is locked 每分鐘出現一次以上」或「聚合查詢超過 3 秒」，就是該換 PostgreSQL 的訊號；PostgreSQL 撐到每秒數萬筆持續寫入或需要自動降採樣，就是該換時間序列資料庫的訊號。這些訊號的共通原則還是那條：按觀察到的瓶頸切換，不按預測提前重構。

縮回要先 drain，不能硬砍

縮回的核心難點是實例身上還有活。減一台實例前，要走跟關閉服務同一套收束流程：先把它從負載平衡的目標裡摘掉（停止送新流量）、等它手上的在途請求處理完、再真正終止。這跟 模組四 graceful shutdown 是同一套機制——縮容其實就是一次有計畫的實例退場，退場的固定順序（摘流量、drain、終止）在那裡展開。硬砍一台正在處理請求的實例，那些請求全部中斷，用戶端看到的就是一批莫名其妙的失敗。

縮回還有兩個容易出事的地方。一是縮太快造成容量不足——流量剛回落就急著縮，結果下一波又上來、新實例還沒起好。二是縮縮擴擴的抖動，訊號在門檻上下跳、實例反覆增減，這靠冷卻時間（cool-down）壓住：擴或縮之後強制等一段時間再判斷，不讓它對每個瞬間波動都反應。擴縮該選哪個訊號、冷卻時間怎麼配，在 規模拐點判斷 的擴縮訊號段有完整對照。

有一種源頭的縮回不靠減實例，而靠降載。collector 的背壓 buffer 滿了就回 429 加一個 Retry-After，SDK 收到 429 自動把取樣率從 1.0 降到 0.5、再降到 0.1；等連續成功幾十次，再逐步回升到 1.0。這是一個閉環的自動降載與恢復——不加機器、直接在源頭把進來的量壓下去，撐過尖峰再放回來。對短暫的高峰，這種源頭降載比擴實例划算得多。

該擴、還是該解耦

擴展到某個點會遇到一個判斷：繼續加實例、還是改變架構。當 collector 群已經水平擴展、仍無法即時消化突發流量時，繼續加實例的邊際效益在下降，這時該考慮插入一個佇列解耦——collector 簡化成「接收、驗證、寫進佇列、回 202」，後面的 worker 按自己的速度消化積壓，把「即時處理」換成「保證不丟、慢慢處理」。但這個決策有反向的一面：如果只是短暫的高峰，佇列的維護成本可能高於它的收益，這時回到源頭用動態取樣降量更划算。佇列解耦的完整設計在 模組七 突發流量 展開，這裡的判斷點是：加實例、源頭降載、佇列解耦是三個不同成本的選項，按尖峰是短暫還是持續來選。

下一步路由

• 什麼訊號代表系統進入飽和、該擴容 → 規模拐點判斷
• 縮回的實例退場順序、drain 怎麼做 → 模組四 Graceful shutdown
• 佇列解耦怎麼接、突發流量的完整應對 → 模組七 突發流量
• 垂直還是水平——擴的方向怎麼選 → 垂直與水平擴展的判斷

收束的相對面是硬砍。平台給的收束時間是有上限的，超過上限服務就被 SIGKILL 強制結束、不走任何清理。所以 graceful shutdown 的成敗判準是清理邏輯能不能在 grace period 內跑完——跑不完，清理邏輯寫得再完整也等於沒有。

信號路徑與 grace period

關閉從一個信號開始，設計的第一件事是確認這個信號真的到得了服務、以及服務有足夠時間反應。在 Kubernetes 上，平台先執行 preStop hook、再送 SIGTERM；terminationGracePeriodSeconds 是平台願意等的最長時間，超過就 SIGKILL。這個值要覆蓋 preStop、drain、資源釋放的總時間——設太短，收束到一半被硬砍。

驗證信號到不到得了服務，靠實際觸發一次關閉看紀錄：在 staging 觸發實例刪除，看 log 有沒有出現關閉處理器的紀錄。沒看到，代表信號根本沒傳到服務，要先修傳遞路徑、再談清理邏輯——清理邏輯寫得再完整，信號收不到就一行都不會跑。

退場的固定順序

實例退場的四個步驟要固定順序：平台先把這個實例從流量目標摘掉、服務停止接受新請求、服務完成手上的在途請求、實例退出。順序穩定，rollback 這種「反向操作」才能在同一套機制下運作。這條順序的第一步對應 readiness——關閉的起手式是把 readiness 轉為否，讓平台停止送新流量，而不是直接關進程。先把流量停掉再收束在途工作，跟先關進程再期待流量自己不來，是完全不同的結果。

這裡有一個單機環境不會遇到、多機才有的細節：readiness 轉為否，到平台真的停止送流量之間，有一段傳播延遲。Kubernetes 把 endpoint 跟 readiness 綁定，readiness 轉否要先傳到 endpoint controller、再傳到每個節點的 kube-proxy 或 envoy，這段期間客戶端仍可能打到已經標記為 not-ready 的實例。穩定的做法是在 preStop hook 加一段短暫等待（5 到 15 秒），讓摘除的狀態傳播到所有轉發層，再開始真正的收束。這段等待是 drain 總窗口的一個子區間，不是浪費——它填的正是「服務說我不 ready」跟「流量真的不再進來」之間的空隙。

drain 窗口按 workload 決定

Drain 要留多久，取決於服務跑的是哪種 workload，沒有通用值：

• 短請求 API（HTTP REST、gRPC unary）：窗口通常 5 到 30 秒，收束條件是在途請求數歸零。主要風險是負載平衡的 deregistration delay 仍會送幾秒流量進來，drain 窗口要覆蓋這段。
• 長連線（WebSocket、gRPC streaming、SSE）：窗口從 30 秒到數分鐘，收束條件是現有連線收斂、且重連的波形穩定。主要風險是 reconnect storm——一堆連線同時被斷、同時重連，把接手的實例壓垮。
• 背景 worker：窗口取決於單一 job 的最長執行時間，收束條件是不可中斷的 job 跑完。風險是被強制結束的 job 留下不一致狀態。

服務若混合了多種 workload，drain 窗口取最嚴格（最長）的那個——短請求 5 秒就收完，但同一個服務還有一個要跑兩分鐘的 job，總窗口就得容納兩分鐘。用短請求的窗口去砍一個長 job，等於每次部署都中斷它。

信號收不到，收束就變硬砍

清理邏輯的前提是收得到信號，容器環境有三個常見的信號傳不到陷阱，都跟 PID 1 有關。第一個是用 shell 當 PID 1 又不轉發——ENTRYPOINT ["sh", "-c", "java -jar app.jar"] 這種寫法，SIGTERM 送到 sh，sh 預設不轉發給 java，java 一直收不到、等 grace period 到期被 SIGKILL 強殺；修法是用 exec form 或在腳本裡 exec，讓服務直接當 PID 1。第二個是多進程容器的殭屍回收——PID 1 不做 wait()，結束的子進程累積成殭屍，這屬於 supervisor 選型 裡 init process 的職責。第三個是啟動腳本的 trap handler 卡住，把本來 graceful 的關閉拖成 ungraceful 的 hang——trap handler 本身要設逾時，不能無限等。

這三個陷阱的共同表現是一樣的：log 裡看不到關閉處理器跑過的紀錄、服務每次都撐到 grace period 上限才消失。看到這個表現，先查 PID 1 是誰、信號有沒有轉發，而不是先懷疑清理邏輯。

收束要保護的是已承諾未完成的工作

Graceful shutdown 真正要保護的，是那些「已經對外承諾、但還沒真正完成」的工作。本站 collector 是個具體例子：它收到事件先回 202、事件進 channel buffer、再非同步寫入儲存。從回 202 到真正寫入之間有一個窗口，這段期間若被 SIGKILL 硬砍，這些已承諾但未持久化的事件就遺失了。graceful shutdown 的收束序列要 flush 這些 pending write——把 buffer 裡還沒寫的先寫完，再退出。

哪些關閉保護得了、哪些保護不了，看退出走不走 graceful。走 SIGTERM 加 grace period 的正常關閉，收束序列有機會 flush；但 OOM kill、硬體故障這種非 graceful 的結束，不走任何清理、在途工作直接中斷——這也是 liveness 要在記憶體逼近上限時主動回報 unhealthy 的理由：主動回報讓平台在還能 graceful 的時候有序重建，好過等 OOM kill 硬砍中斷在途工作。這條「有沒有走 graceful」的分界在監控上也留得下痕跡——collector 正常關閉會送一個 collector.shutdown 事件，這個事件的有無，就是區分有序退場跟異常中斷的訊號。

下一步路由

• 收束的第一步是 readiness 轉否、停止接流量 → Liveness 與 Readiness
• 信號傳不到的 PID 1 選型問題 → Process supervisor 選型
• 部署替換時 drain 與 rollback 的完整流程 → Backend 部署替換、drain 與 rollback
• 端到端資料完整性：已承諾未持久化窗口的更多場景 → 端到端資料完整性