高可用架構之限流降級

• 2019 年 10 月 3 日
• 筆記

 我們常說的N個9，就是對SLA的一個描述。

SLA全稱是ServiceLevel Agreement，翻譯為服務水平協議，也稱服務等級協議，它表明了公有雲提供服務的等級以及品質。

例如阿里雲對外承諾的就是一個服務周期內集群服務可用性不低於99.99%，如果低於這個標準，雲服務公司就需要賠償客戶的損失。

1.1 做到4個9夠好了嗎

對互聯網公司來說，SLA就是網站或者API服務可用性的一個保證。

9越多代表全年服務可用時間越長服務更可靠，4個9的服務可用性，聽起來已經很高了，但對於實際的業務場景，這個值可能並不夠。

我們來做一個簡單的計算，假設一個核心鏈路依賴20個服務，強依賴同時沒有配置任何降級，並且這20個服務的可用性達到4個9，也就是99.99%，

那這個核心鏈路的可用性只有99.99的20次方 = 99.8%，

• 如果有10億次請求則有3,000,000次的失敗請求

• 理想狀況下，每年還是有17小時服務不可用

   

  

   

這是一個理想的估算，在實際的生產環境中，由於服務發布，宕機等各種各樣的原因，情況肯定會比這個更差，

對於一些業務比較敏感的業務，比如金融，或是對服務穩定要求較高的行業，比如訂單或者支付業務，這樣的情況是不能接受的。

1.2 微服務的雪崩效應

除了對服務可用性的追求，微服務架構一個繞不過去的問題就是服務雪崩。

在一個調用鏈路上，微服務架構各個服務之間組成了一個鬆散的整體，牽一髮而動全身，

服務雪崩是一個多級傳導的過程，首先是某個服務提供者不可用，由於大量超時等待，繼而導致服務調用者不可用，並且在整個鏈路上傳導，繼而導致系統癱瘓。

二、限流降級怎麼做

如同上面我們分析的，在大規模微服務架構的場景下，避免服務出現雪崩，要減少停機時間，要儘可能的提高服務可用性。

提高服務可用性，可以從很多方向入手，比如快取、池化、非同步化、負載均衡、隊列和降級熔斷等手段。

• 快取以及隊列等手段，增加系統的容量

• 限流和降級則是關心在到達系統瓶頸時系統的響應，更看重穩定性

快取和非同步等提高系統的戰力，限流降級關注的是防禦。

限流和降級，具體實施方法可以歸納為八字箴言，分別是限流，降級，熔斷和隔離。

2.1 限流和降級

限流顧名思義，提前對各個類型的請求設置最高的QPS閾值，若高於設置的閾值則對該請求直接返回，不再調用後續資源。

限流需要結合壓測等，了解系統的最高水位，也是在實際開發中應用最多的一種穩定性保障手段。

降級則是當伺服器壓力劇增的情況下，根據當前業務情況及流量對一些服務和頁面有策略的降級，以此釋放伺服器資源以保證核心任務的正常運行。

從降級配置方式上，降級一般可以分為主動降級和自動降級。

主動降級是提前配置，自動降級則是系統發生故障時，如超時或者頻繁失敗，自動降級。

其中，自動降級，又可以分為以下策略：

• 超時降級

• 失敗次數降級

• 故障降級

在系統設計中，降級一般是結合系統配置中心，通過配置中心進行推送，下面是一個典型的降級通知設計

2.2 熔斷隔離

如果某個目標服務調用慢或者有大量超時，此時熔斷該服務的調用，對於後續調用請求，不在繼續調用目標服務，直接返回，快速釋放資源。

熔斷一般需要設置不同的恢復策略，如果目標服務情況好轉則恢復調用。

服務隔離與前面的三個略有區別，我們的系統通常提供了不止一個服務，但是這些服務在運行時是部署在一個實例，或者一台物理機上面的，

如果不對服務資源做隔離，一旦一個服務出現了問題，整個系統的穩定性都會受到影響！

服務隔離的目的就是避免服務之間相互影響。

一般來說，隔離要關注兩方面，一個是在哪裡進行隔離，另外一個是隔離哪些資源。

• 何處隔離

一次服務調用，涉及到的是服務提供方和調用方，我們所指的資源，也是兩方的伺服器等資源，服務隔離通常可以從提供方和調用方兩個方面入手。

• 隔離什麼

廣義的服務隔離，不僅包括伺服器資源，還包括資料庫分庫，快取，索引等，這裡我們只關注服務層面的隔離。

2.3 降級和熔斷的區別

服務降級和熔斷在概念上比較相近，通過兩個場景，談談我自己的理解。

• 熔斷，一般是停止服務

典型的就是股市的熔斷，如果大盤不受控制，直接休市，不提供服務，是保護大盤的一種方式。

• 降級，通常是有備用方案

從北京到濟南，下雨導致航班延誤，我可以乘坐高鐵，如果高鐵票買不到，也可以乘坐汽車或者開車過去。

• 兩者的區別

降級一般是主動的，有預見性的，熔斷通常是被動的，

服務A降級以後，一般會有服務B來代替，而熔斷通常是針對核心鏈路的處理。

在實際開發中，熔斷的下一步通常就是降級。

三、常用限流演算法設計

剛才講了限流的概念，那麼怎樣判斷系統到達設置的流量閾值了？

這就需要一些限流策略來支援，不同的限流演算法有不同的特點，平滑程度也不同。

3.1 計數器法

計數器法是限流演算法里最簡單也是最容易實現的一種演算法。

假設一個介面限制一分鐘內的訪問次數不能超過100個，維護一個計數器，每次有新的請求過來，計數器加一，這時候判斷，如果計數器的值小於限流值，並且與上一次請求的時間間隔還在一分鐘內，

允許請求通過，否則拒絕請求，如果超出了時間間隔，要將計數器清零。

public class CounterLimiter {  ​      //初始時間      private static long startTime = System.currentTimeMillis();  ​      //初始計數值      private static final AtomicInteger ZERO = new AtomicInteger(0);  ​      //時間窗口限制      private static final long interval = 10000;  ​      //限制通過請求      private static int limit = 100;  ​      //請求計數      private AtomicInteger requestCount = ZERO;  ​      //獲取限流      public boolean tryAcquire() {  ​          long now = System.currentTimeMillis();  ​          //在時間窗口內          if (now < startTime + interval) {  ​              //判斷是否超過最大請求              if (requestCount.get() < limit) {                  requestCount.incrementAndGet();                  return true;              }              return false;  ​          } else {  ​              //超時重置              startTime = now;              requestCount = ZERO;              return true;          }  ​      }  }  

計數器限流可以比較容易的應用在分散式環境中，用一個單點的存儲來保存計數值，比如用Redis，並且設置自動過期時間，這時候就可以統計整個集群的流量，並且進行限流。

計數器方式的缺點是不能處理臨界問題，或者說限流策略不夠平滑。

假設在限流臨界點的前後，分別發送100個請求，實際上在計數器置0前後的極短時間裡，處理了200個請求，這是一個瞬時的高峰，可能會超過系統的限制。

計數器限流允許出現 2*permitsPerSecond 的突發流量，可以使用滑動窗口演算法去優化，具體不展開。

3.2 漏桶演算法

假設我們有一個固定容量的桶，桶底部可以漏水（忽略氣壓等，不是物理問題），並且這個漏水的速率可控的，那麼我們可以通過這個桶來控制請求速度，也就是漏水的速度。

我們不關心流進來的水，也就是外部請求有多少，桶滿了之後，多餘的水會溢出。

漏桶演算法的示意圖如下：

將演算法中的水換成實際應用中的請求，可以看到漏桶演算法從入口限制了請求的速度。使用漏桶演算法，我們可以保證介面會以一個常速速率來處理請求，所以漏桶演算法不會出現臨界問題。

這裡簡單實現一下，也可以使用Guava的SmoothWarmingUp類，可以更好的控制漏桶演算法，

public class LeakyLimiter {  ​      //桶的容量      private int capacity;  ​      //漏水速度      private int ratePerMillSecond;  ​      //水量      private double water;  ​      //上次漏水時間      private long lastLeakTime;  ​      public LeakyLimiter(int capacity, int ratePerMillSecond) {  ​          this.capacity = capacity;          this.ratePerMillSecond = ratePerMillSecond;          this.water = 0;      }  ​  ​      //獲取限流      public boolean tryAcquire() {  ​          //執行漏水，更新剩餘水量          refresh();  ​          //嘗試加水，水滿則拒絕          if (water + 1 > capacity) {              return false;          }  ​          water = water + 1;          return true;  ​      }  ​      private void refresh() {          //當前時間          long currentTime = System.currentTimeMillis();  ​          if (currentTime > lastLeakTime) {  ​              //距上次漏水的時間間隔              long millisSinceLastLeak = currentTime - lastLeakTime;              long leaks = millisSinceLastLeak * ratePerMillSecond;  ​              //允許漏水              if (leaks > 0) {                  //已經漏光                  if (water <= leaks) {                      water = 0;                  } else {                      water = water - leaks;                  }                  this.lastLeakTime = currentTime;              }          }      }  }  

​ 

3.3 令牌桶演算法

漏桶是控制水流入的速度，令牌桶則是控制留出，通過控制token，調節流量。

假設一個大小恆定的桶，桶里存放著令牌（token）。桶一開始是空的，現在以一個固定的速率往桶里填充，直到達到桶的容量，多餘的令牌將會被丟棄。

如果令牌不被消耗，或者被消耗的速度小於產生的速度，令牌就會不斷地增多，直到把桶填滿。後面再產生的令牌就會從桶中溢出。最後桶中可以保存的最大令牌數永遠不會超過桶的大小，

每當一個請求過來時，就會嘗試從桶里移除一個令牌，如果沒有令牌的話，請求無法通過。

public class TokenBucketLimiter {  ​      private long capacity;      private long windowTimeInSeconds;      long lastRefillTimeStamp;      long refillCountPerSecond;      long availableTokens;  ​      public TokenBucketLimiter(long capacity, long windowTimeInSeconds) {          this.capacity = capacity;          this.windowTimeInSeconds = windowTimeInSeconds;          lastRefillTimeStamp = System.currentTimeMillis();          refillCountPerSecond = capacity / windowTimeInSeconds;          availableTokens = 0;      }  ​      public long getAvailableTokens() {          return this.availableTokens;      }  ​      public boolean tryAcquire() {  ​          //更新令牌桶          refill();  ​          if (availableTokens > 0) {              --availableTokens;              return true;          } else {              return false;          }      }  ​  ​      private void refill() {          long now = System.currentTimeMillis();  ​          if (now > lastRefillTimeStamp) {  ​              long elapsedTime = now - lastRefillTimeStamp;  ​              int tokensToBeAdded = (int) ((elapsedTime / 1000) * refillCountPerSecond);  ​              if (tokensToBeAdded > 0) {                  availableTokens = Math.min(capacity, availableTokens + tokensToBeAdded);                  lastRefillTimeStamp = now;              }          }      }  ​  }  

這兩種演算法的主要區別在於漏桶演算法能夠強行限制數據的傳輸速率，而令牌桶演算法在能夠限制數據的平均傳輸速率外，還允許某種程度的突發傳輸。

在令牌桶演算法中，只要令牌桶中存在令牌，那麼就允許突發地傳輸數據直到達到用戶配置的門限，因此它適合於具有突發特性的流量。

3.4 漏桶和令牌桶的比較

漏桶和令牌桶演算法實現可以一樣，但是方向是相反的，對於相同的參數得到的限流效果是一樣的。

主要區別在於令牌桶允許一定程度的突發，漏桶主要目的是平滑流入速率，考慮一個臨界場景，令牌桶內積累了100個token，可以在一瞬間通過，但是因為下一秒產生token的速度是固定的，

所以令牌桶允許出現瞬間出現permitsPerSecond的流量，但是不會出現2*permitsPerSecond的流量，漏桶的速度則始終是平滑的。

3.5 使用RateLimiter實現限流

Google開源工具包Guava提供了限流工具類RateLimiter，該類基於令牌桶演算法實現流量限制，使用方便。

RateLimiter使用的是令牌桶的流控演算法，RateLimiter會按照一定的頻率往桶里扔令牌，執行緒拿到令牌才能執行，比如你希望自己的應用程式QPS不要超過1000，那麼RateLimiter設置1000的速率後，就會每秒往桶里扔1000個令牌，看下方法的說明：

RateLimter提供的API可以直接應用，其中acquire會阻塞，類似JUC的訊號量Semphore，tryAcquire方法則是非阻塞的：

public class RateLimiterTest {  ​      public static void main(String[] args) throws InterruptedException {  ​          //允許10個，permitsPerSecond          RateLimiter limiter = RateLimiter.create(10);  ​          for(int i=1;i<20;i++){              if (limiter.tryAcquire(1)){                  System.out.println("第"+i+"次請求成功");              }else{                  System.out.println("第"+i+"次請求拒絕");              }          }      }  }  ​