讓服務在流量暴增時保持不倒

服務自適應降載保護設計

設計目的

• 保證系統不被過量請求拖垮
• 在保證系統穩定的前提下，儘量提供更高的吞吐量

設計考慮因素

• 如何衡量系統負載
  • 是否處於虛機或容器內，須要讀取cgroup相關負載
  • 用1000m表示100%CPU，推薦使用800m表示系統高負載
• 儘量小的Overhead，不顯著增長RT
• 不考慮服務自己所依賴的DB或者緩存系統問題，這類問題經過熔斷機制來解決

機制設計

• 計算CPU負載時使用滑動平均來下降CPU負載抖動帶來的不穩定，關於滑動平均見參考資料

  • 滑動平均就是取以前連續N次值的近似平均，N取值能夠經過超參beta來決定
  • 當CPU負載大於指定值時觸發降載保護機制

• 時間窗口機制，用滑動窗口機制來記錄以前時間窗口內的QPS和RT(response time)

  • 滑動窗口使用5秒鐘50個桶的方式，每一個桶保存100ms時間內的請求，循環利用，最新的覆蓋最老的
  • 計算maxQPS和minRT時須要過濾掉最新的時間沒有用完的桶，防止此桶內只有極少數請求，而且RT處於低機率的極小值，因此計算maxQPS和minRT時按照上面的50個桶的參數只會算49個

• 知足如下全部條件則拒絕該請求

  1. 當前CPU負載超過預設閾值，或者上次拒絕時間到如今不超過1秒(冷卻期)。冷卻期是爲了避免能讓負載剛下來就立刻增長壓力致使立馬又上去的來回抖動

  2. averageFlying > max(1, QPS*minRT/1e3)

     • averageFlying = MovingAverage(flying)

     • 在算MovingAverage(flying)的時候，超參beta默認取值爲0.9，表示計算前十次的平均flying值

     • 取flying值的時候，有三種作法：

       1. 請求增長後更新一次averageFlying，見圖中橙色曲線
       2. 請求結束後更新一次averageFlying，見圖中綠色曲線
       3. 請求增長後更新一次averageFlying，請求結束後更新一次averageFlying

       咱們使用的是第二種，這樣能夠更好的防止抖動，如圖：

     • QPS = maxPass * bucketsPerSecond

       • maxPass表示每一個有效桶裏的成功的requests
       • bucketsPerSecond表示每秒有多少個桶

     • 1e3表示1000毫秒，minRT單位也是毫秒，QPS*minRT/1e3獲得的就是平均每一個時間點有多少併發請求

降載的使用

• 已經在rest和zrpc框架裏增長了可選激活配置
  • CpuThreshold，若是把值設置爲大於0的值，則激活該服務的自動降載機制
• 若是請求被drop，那麼錯誤日誌裏會有dropreq關鍵字

參考資料

• 滑動平均
• Sentinel自適應限流

項目地址

github.com/tal-tech/go…

若是以爲文章不錯，歡迎 github 點個 star 🤝