架構設計之服務限流

限流能夠認爲服務降級的一種，限流就是限制系統的輸入和輸出流量已達到保護系統的目的。通常來講系統的吞吐量是能夠被測算的，爲了保證系統的穩定運行，一旦達到的須要限制的閾值，就須要限制流量並採起一些措施以完成限制流量的目的。好比：延遲處理，拒絕處理，或者部分拒絕處理等等。

v服務限流概念

在介紹限流概念以前，咱們先來聊聊身邊有哪些限流，若是有在帝都的碼農估計對限流是最深有感觸的，帝都但凡開個XXX會議，各大地鐵站都會限流。

每一年的雙11都是剁手族的天堂，11月11號0點0幾秒的時候，下面這些場景或許你曾經遇到過。

固然，這幾年雙11各大電商對併發的支持作的愈來愈好，這裏只是借鑑雙11剛推出之際，經常須要應對的一些問題。

經過這兩個場景，基本上服務限流的做用也就明白：

「服務限流」實際上是指當系統資源不夠，不足以應對大量請求，即系統資源與訪問量出現矛盾的時候，咱們爲了保證有限的資源可以正常服務，所以對系統按照預設的規則進行流量限制或功能限制的一種方法。

v爲什麼要服務限流

再舉一個咱們生活中的例子：一些熱門的旅遊景點，每每會對每日的旅遊參觀人數有嚴格的限制，好比北京的故宮、歡樂谷等，天天只會賣出固定數目的門票，若是你去的晚了，可能當天的票就已經賣完了，當天就沒法進去遊玩了，即便你進去了，排隊也能排到你懷疑人生。

爲何旅遊景點要作這樣的限制呢？多賣一些門票多賺一些錢豈不是更好？

其實對於旅遊景點而言，她們也很無奈，由於景點的服務資源有限嘛，每日能服務的人數是有限的，一旦放開限制了，景點的工做人員就會不夠用，衛生狀況也得不到保障，安全也有隱患，超密集的人羣也會嚴重的影響遊客的體驗。但因爲景區名氣大，來遊玩的旅客絡繹不絕，遠超出了景區的承載能力，所以景區只好作出限制每日人員流量的舉措。

同理，在IT軟件行業中，系統服務也是這樣的。

若是你的系統理論是時間單位內可服務100W用戶，可是今天卻忽然來了300W用戶，因爲用戶流量的隨機性，若是不加以限流，頗有可能這300W用戶一會兒就壓垮了系統，致使全部人都得不到服務。

所以爲了保證系統至少還能爲100W用戶提供正常服務，咱們須要對系統進行限流設計。

有的人可能會想，既然會有300W用戶來訪問，那爲啥系統不乾脆設計成能足以支撐這麼大量用戶的集羣呢？

這是個好問題。若是系統是長期有300W的用戶來訪問，確定是要作上述升級的，可是經常面臨的狀況是，系統的平常訪問量就是100W，只不過偶爾有一些不可預知的特定緣由致使的短期的流量激增，這個時候，公司每每出於節約成本的考慮，不會爲了一個不常見的尖峯來把咱們的系統擴容到最大的尺寸。

v如何服務限流

對系統服務進行限流，通常有以下幾個模式：

1. 熔斷：

這個模式是須要系統在設計之初，就要把熔斷措施考慮進去。當系統出現問題時，若是短期內沒法修復，系統要自動作出判斷，開啓熔斷開關，拒絕流量訪問，避免大流量對後端的過載請求。系統也應該可以動態監測後端程序的修復狀況，當程序已恢復穩定時，能夠關閉熔斷開關，恢復正常服務。

2. 服務降級：

將系統的全部功能服務進行一個分級，當系統出現問題，須要緊急限流時，可將不是那麼重要的功能進行降級處理，中止服務，這樣能夠釋放出更多的資源供給核心功能的去用。

例如在電商平臺中，若是突發流量激增，可臨時將商品評論、積分等非核心功能進行降級，中止這些服務，釋放出機器和CPU等資源來保障用戶正常下單，而這些降級的功能服務能夠等整個系統恢復正常後，再來啓動，進行補單/補償處理。除了功能降級之外，還能夠採用不直接操做數據庫，而所有讀緩存、寫緩存的方式做爲臨時降級方案。

3. 延遲處理：

這個模式須要在系統的前端設置一個流量緩衝池，將全部的請求所有緩衝進這個池子，不當即處理。而後後端真正的業務處理程序從這個池子中取出請求依次處理，常見的能夠用隊列模式來實現。這就至關於用異步的方式去減小了後端的處理壓力，可是當流量較大時，後端的處理能力有限，緩衝池裏的請求可能處理不及時，會有必定程度延遲。

4. 特權處理：

這個模式須要將用戶進行分類，經過預設的分類，讓系統優先處理須要高保障的用戶羣體，其它用戶羣的請求就會延遲處理或者直接不處理。

那在實際項目中，對訪問流量的限制，可採用以下幾種技術方法：

♛ 熔斷技術

熔斷的技術能夠重點參考Netflix的開源組件hystrix的作法，主要有三個模塊：熔斷請求判斷算法、熔斷恢復機制、熔斷報警。

來自hystrix github wiki          查看大圖

♛ 計數器方法

系統維護一個計數器，來一個請求就加1，請求處理完成就減1，當計數器大於指定的閾值，就拒絕新的請求。

基於這個簡單的方法，能夠再延伸出一些高級功能，好比閾值能夠不是固定值，是動態調整的。另外，還能夠有多組計數器分別管理不一樣的服務，以保證互不影響等。

♛ 隊列方法

就是基於FIFO隊列，全部請求都進入隊列，後端程序從隊列中取出待處理的請求依次處理。

基於隊列的方法，也能夠延伸出更多的玩法來，好比能夠設置多個隊列以配置不一樣的優先級。

♛ 令牌桶方法

首先仍是要基於一個隊列，請求放到隊列裏面。但除了隊列之外，還要設置一個令牌桶，另外有一個腳本以持續恆定的速度往令牌桶裏面放令牌，後端處理程序每處理一個請求就必須從桶裏拿出一個令牌，若是令牌拿完了，那就不能處理請求了。咱們能夠控制腳本放令牌的速度來達到控制後端處理的速度，以實現動態流控。

v注意事項

咱們在作服務限流的時候，仍是有一些原則和事項須要注意的：

• 實時監控：系統必需要作好全鏈路的實時監控，才能保證限流的及時檢測和處理。
• 手動開關：除系統自動限流之外，還須要有能手動控制的開關，以保證隨時均可以人工介入。
• 限流的性能：限流的功能理論上是會在必定程度影響到業務正常性能的，所以須要作到限流的性能優化和控制。

v博客總結

系統故障經常都是不可預測且難以免的，所以做爲系統設計師的咱們，必需要提早預設各類措施，以應對隨時可能的系統風險。

做　　者：請叫我頭頭哥
出　　處：http://www.cnblogs.com/toutou/
關於做者：專一於基礎平臺的項目開發。若有問題或建議，請多多賜教！
版權聲明：本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文連接。
特此聲明：全部評論和私信都會在第一時間回覆。也歡迎園子的大大們指正錯誤，共同進步。或者直接私信我
聲援博主：若是您以爲文章對您有幫助，能夠點擊文章右下角【推薦】一下。您的鼓勵是做者堅持原創和持續寫做的最大動力！