[Alibaba微服務技術入門]_Sentinel系統自適應限流_第15講
Sentinel系統自適應限流官方文件：https://github.com/alibaba/Sentinel/wiki/%E7%B3%BB%E7%BB%9F%E8%87%AA%E9%80%82%E5%BA%94%E9%99%90%E6%B5%81
簡介：
Sentinel 系統自適應限流從整體維度對應用入口流量進行控制，結合應用的 Load、CPU 使用率、總體平均 RT、入口 QPS 和併發執行緒數等幾個維度的監控指標，通過自適應的流控策略，讓系統的入口流量和系統的負載達到一個平衡，讓系統儘可能跑在最大吞吐量的同時保證系統整體的穩定性
背景：
在開始之前，我們先了解一下系統保護的目的：
- 保證系統不被拖垮
- 在系統穩定的前提下，保持系統的吞吐量
長期以來，系統保護的思路是根據硬指標，即系統的負載 (load1) 來做系統過載保護。當系統負載高於某個閾值，就禁止或者減少流量的進入；當 load 開始好轉，則恢復流量的進入。這個思路給我們帶來了不可避免的兩個問題
- load 是一個“結果”，如果根據 load 的情況來調節流量的通過率，那麼就始終有延遲性。也就意味著通過率的任何調整，都會過一段時間才能看到效果。當前通過率是使 load 惡化的一個動作，那麼也至少要過 1 秒之後才能觀測到；同理，如果當前通過率調整是讓 load 好轉的一個動作，也需要 1 秒之後才能繼續調整，這樣就浪費了系統的處理能力。所以我們看到的曲線，總是會有抖動
- 恢復慢。想象一下這樣的一個場景（真實），出現了這樣一個問題，下游應用不可靠，導致應用 RT 很高，從而 load 到了一個很高的點。過了一段時間之後下游應用恢復了，應用 RT 也相應減少。這個時候，其實應該大幅度增大流量的通過率；但是由於這個時候 load 仍然很高，通過率的恢復仍然不高
TCP BBR 的思想給了我們一個很大的啟發。我們應該根據系統能夠處理的請求，和允許進來的請求，來做平衡，而不是根據一個間接的指標（系統 load）來做限流。最終我們追求的目標是 在系統不被拖垮的情況下，提高系統的吞吐率，而不是 load 一定要到低於某個閾值。如果我們還是按照固有的思維，超過特定的 load 就禁止流量進入，系統 load 恢復就放開流量，這樣做的結果是無論我們怎麼調引數，調比例，都是按照果來調節因，都無法取得良好的效果
Sentinel 在系統自適應保護的做法是，用 load1 作為啟動自適應保護的因子，而允許通過的流量由處理請求的能力，即請求的響應時間以及當前系統正在處理的請求速率來決定
系統規則：
系統保護規則是從應用級別的入口流量進行控制，從單臺機器的 load、CPU 使用率、平均 RT、入口 QPS 和併發執行緒數等幾個維度監控應用指標，讓系統儘可能跑在最大吞吐量的同時保證系統整體的穩定性
系統保護規則是應用整體維度的，而不是資源維度的，並且僅對入口流量生效。入口流量指的是進入應用的流量（EntryType.IN），比如 Web 服務或 Dubbo 服務端接收的請求，都屬於入口流量
系統規則支援以下的模式：
- Load 自適應（僅對 Linux/Unix-like 機器生效）：系統的 load1 作為啟發指標，進行自適應系統保護。當系統 load1 超過設定的啟發值，且系統當前的併發執行緒數超過估算的系統容量時才會觸發系統保護（BBR 階段）。系統容量由系統的 maxQps * minRt 估算得出。設定參考值一般是 CPU cores * 2.5。
- CPU usage（1.5.0+ 版本）：當系統 CPU 使用率超過閾值即觸發系統保護（取值範圍 0.0-1.0），比較靈敏。
- 平均 RT：當單臺機器上所有入口流量的平均 RT 達到閾值即觸發系統保護，單位是毫秒。
- 併發執行緒數：當單臺機器上所有入口流量的併發執行緒數達到閾值即觸發系統保護。
- 入口 QPS：當單臺機器上所有入口流量的 QPS 達到閾值即觸發系統保護。
原理：
我們把系統處理請求的過程想象為一個水管，到來的請求是往這個水管灌水，當系統處理順暢的時候，請求不需要排隊，直接從水管中穿過，這個請求的RT是最短的；反之，當請求堆積的時候，那麼處理請求的時間則會變為：排隊時間 + 最短處理時間