現行在很多高通量的服務(例如 APIm)之中會使用一些限流(熔斷)機制,例如記錄每個 IP 能打進這個服務的次數或限制同時能夠擁有的連線數。但是這會造成幾個問題:
1. 應用程式避免被熔斷通常都會高估使用量,例如高峰每秒只會打 10 個請求,但卻申請 15 個的 quota
2. 服務為了滿足各個 client 在限制下的流量通常都會拉高承載力(capacity),例如 client A 和 client B 限制每秒 10 個請求,這時這個服務就要有約每秒 25 個請求的承載力,就會造成大部分時間資源的浪費
3. 當有合理的流量上升,會阻擋到非必要限制的使用者,例如某服務突然變得很有名,限流的設定卻是舊的
4. 以 APIm 為例,上游承載能力是會動態浮動的,所以原本限流 20 可以避免上游服務崩壞,但是某天上游服務突然變得很慢,每秒 5 個請求就會讓他崩壞,限流的保護機制如同虛設
併行管理系統就是要解決這些問題,這些東西並不新,在 TCP 設計時就有很多這種機制,包括 AIMD、Vegas、Gradient 等等,現行的服務都應該要有這些東西,但我們卻很少意識到這件事。
放一些原始碼,並提供給參與者。
本文與連結相關資源非經取得作者授權,不得任意轉載或公開傳輸