Engineering · 3 min read
共享資源的影響範圍：當一個死，全部一起死
集中化省了資源，也集中了風險。一個共用瀏覽器死了，所有 in-flight 的請求跟著死。Bulkhead 被拆掉了。
集中化省了資源，也集中了風險。加回的限制就是 semaphore。
影響範圍反過來
Backpressure 不會自動跨 process
- In-process 排程器只看得見自己 process 裡的資源。Out-of-process 的瓶頸 = 不可見，沒有自動 backpressure（GMP 排程器與 netpoller、GOMAXPROCS 限制平行不限並發）。
- Bulkhead pattern = 刻意分區，一區壞了，其餘不受影響。共用 pool 是 anti-bulkhead（拆掉了隔離，一個出事全部受影響）。
- 原則：集中化的時候，把隔離原本免費給你的上限補回去。
Fan-in 的數學
Per-pod 的 cap 只約束本地 sidecar。如果下游是共享 singleton，N 個 replica 的 cap 加總就是實際負載。用 global limiter（Redis / Envoy）、per-replica resource（sidecar）、或 pull-based queue 才能真正 bound。
在這個 OOM 裡的角色
從獨立瀏覽器改成共用瀏覽器，省了啟動成本，但影響範圍從「一個請求」變成「所有 in-flight 請求」。Go runtime 不知道瀏覽器快滿了，沒有 backpressure，goroutine 繼續開分頁。修法：在 Go 端（process 邊界）加 semaphore + 429（用 TryAcquire 做 load shedding）。
一個共享資源沒有上限，等於整個系統沒有上限。
參考來源：
- https://sreschool.com/blog/bulkhead/
- https://oneuptime.com/blog/post/2026-01-25-bulkhead-pattern-go-microservices/view
- https://www.abstractalgorithms.dev/bulkhead-pattern-isolate-capacity-and-failure-domains
- https://medium.com/expedia-group-tech/traffic-shedding-rate-limiting-backpressure-oh-my-21f95c403b29
- https://dev.to/saumya_karnwal/distributed-rate-limiting-five-problems-that-break-your-counters-454
Related： 參見用 TryAcquire 做 load shedding、keep-alive 讓重試卡在同一台、錯誤的修法，或回到系列總覽。