:-:  **設置流控規則的地方**  **限流規則組成因素** * 資源名：限流規則的作用對象，唯一名稱，默認為請求路徑。 * 針對來源：可以針對調用者限流，為微服務的名稱，default為不區分來源。 * 閾值類型： * QPS是每秒請求次數。 * 線程數與QPS的區別是：QPS是指當超過閾值時會將多余的請求拒之門外，多余的請求根本就進不了微服務里面；而線程數是指所有的請求都可以進到微服務里面，多余的請求則在微服務里面直接丟棄。 * 單機閾值：填寫整數。 * 是否集群：不勾選則不是集群。 * 流控模式： * 直接：當一個請求超出閾值時，超出部分直接被限流。 * 關聯：如果請求B關聯請求A，則當請求B超出閾值時，對請求A限流。 * 鏈路：在指定的鏈路上的入口資源超出閾值則限流。 * 流控效果： * 快速失敗：當請求超出閾值后，超出的部分直接拋出異常，請求失敗。 * Warm Up：稱為預熱/冷啟動方式。假如設置閾值為10，預熱時長為5s，則初始閾值為 `$ 10/codeFactor(默認為3)=3 $`，經過5s后閾值更改為10。 * 排隊等待：就是當請求超出閾值后，超出的部分需要排隊處理，可以規定每多少秒處理一個請求，只針對QPS閾值類型有效。 下面演示流控模式和流控效果的使用效果。 **1. 流控模式-直接** （1）流控規則：1s內只處理一次請求。  （2）演示效果：在1s超出的請求被限流了。  <br/> **2. 流控模式-關聯** （1）流控規則：`/testB`1s內只處理一次請求。 關聯模式下，設置的單機閾值是`/testB`的閾值，不是`/testA`的閾值。  （2）演示效果：我使用Postman在1s內向`/testB`請求100次，由于`/testB`1s內被請求的次數超過1次，所以導致`/testA`被限流了。  **3. 流控模式-鏈路** （1）流控規則： <br/> **4. 流控效果-快速失敗** 這種方式適用于對系統處理能力確切已知的情況下，比如通過壓測確定了系統的準確水位時。 （1）流控規則：1s內只處理一次請求。  （2）演示效果：在1s超出的請求被限流了，直接拋出異常。  <br/> **5. 流控效果-Warm Up** 當系統長期處于低水位的情況下，當流量突然增加時，直接把系統拉升到高水位可能瞬間把系統壓垮。通過"冷啟動"，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮。 （1）流控規則：設置閾值為10，預熱時長為5s，則初始閾值為 `$ 10/codeFactor(默認為3)=3 $`，經過5s后閾值更改為10。  （2）演示效果：開始的時候閾值為3，1s內請求次數超過3次后被限流，經過5s后閾值為10，承擔的請求次數變多就沒有被限流了。  <br/> **6. 流控效果-排隊等待** 這種方式主要用于處理間隔性突發的流量，例如消息隊列。想象一下這樣的場景，在某一秒有大量的請求到來，而接下來的幾秒則處于空閑狀態，我們希望系統能夠在接下來的空閑期間逐漸處理這些請求，而不是在第一秒直接拒絕多余的請求。 >[info] 注意：勻速排隊模式暫時不支持 QPS > 1000 的場景。 （1）流控規則：1s只處理一個請求，如果某一個請求在2000ms還沒有被處理則丟棄。  （2）演示效果：我使用Postman在1s內發出100次請求，但是這些請求每隔1s才被處理。