大家好，我是架構擺渡人，這是流量治理系列的第9篇原創文章，如果有收穫，還請分享給更多的朋友。
曾經有人問過我，限流有痛點嗎？我當時的回答是：限流閥值不太好評估以及限流降低了使用者的體驗，這是我認為的痛點。
限流閥值到底怎麼評估還是得有壓測的動作，特別是現在電商平臺，在大促前都會進行全鏈路壓測，將問題暴露出來，看能承受多少流量的請求。然後再根據業務預期，就知道要不要擴容，以及流控的指標了，說難也不難，就是需要多種手段進行佐證。
降低使用者體驗這個是限流必須經歷的，使用者正在下單，然後收到的提示就是伺服器當前太擁擠，網路異常，請重試等等提示，說簡單點就是降低了使用者的體驗，因為使用者需要反覆操作。說的嚴重點就是影響了下單的轉換率，所以這也是為什麼電商平臺大促前要壓測的原因。不是說直接限流到很低的水位就行，就是使用者體驗和系統複雜度要權衡。
其實還有一個更痛的點就是：資源利用率上不去。
當我們經過壓測後，評估單節點的效能最大值時，流控的閥值在70%是比較穩妥的做法。比如你單機壓到1000 QPS, 然後CPU和記憶體都在50%左右，那麼直接就流控 1000 即可。
這1000裡面可能還會細分介面，不同的介面限流的值也不同。比如你某個介面配置了500限流，只要這個介面的請求量超過了500那麼必定會限流，但是有可能這個時候只有這個介面的訪問量比較多，其他的都沒什麼訪問量，機器的CPU,記憶體什麼的還很低，包括資料庫的響應也很快。此時好像不限流也沒關係，但是因為限流配置的是固定的值，只能限制了。
面對這種情況，一種新的限流方式就誕生了，就是自適應限流。自適應限流就是沒有固定的限流閥值，限流的閥值會變化，變化的因素就是依賴的資源是否足夠，比如CPU，記憶體等資源。
自適應限流還是比較複雜的，複雜點在於需要實時採集各種資料，然後通過大量的計算，再提取出決策，這個決策就是是否要限流，並且計算速度還得快。
大概的架構如下：
當然這個計算是單獨的服務，還是內嵌在當前的應用中都是可以的，取決於效能影響以及是否叢集流控。
有了自適應限流，資源的利用率將被大大提升。因為不用在設定一個比較穩妥的固定的值了，而是根據資源的使用情況來決定是否限流，最大程式利用資源。
在開源框架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
自適應限流的好處一個是能夠提高資源的利用率，還有就是能否適應不確定的因素帶來的影響。相比於靜態的限流配置，我們一定是基於壓測後的結果來配置，即使是壓測後，到了真正大流量來襲的時候，也無法保證跟壓測時的結果一模一樣。萬一有突發情況，一條慢Sql把資料庫的CPU打滿了，你限流的閥值還是那麼多QPS, 慢SQL增加幾百倍，這個限流此時就失去了作用。
通過自適應限流，根據實時計算的結果決定是否要流控，保證系統穩定性。同時也避免了繁瑣的人工配置過程，系統自動調節。
再舉一個例子：下單介面限流值為1000，訂單詳情為500。如果按照固定的值做限流，下單超過1000就會被限制，如果下單的請求量大於訂單詳情的量，那麼自適應限流是否可以先滿足業務價值更高的流量，讓這部分流量先通過，如果此時有其他流量來是否可以自動先限制住。這部分的價值不用我多說，大家都明白。
所以自適應限流能做很多東西，主要是智慧，智慧提現在演算法層面，有點人工智慧的意思哈。