軟件架構 - 服務限流降級熔斷機制詳解

大部分老鐵都沒用過 hystrix，一般來說能用到 hystrix 的公司都是比較大型的互聯網公司， 服務的限流，降級，熔斷，超時這些東西很多老鐵經常聽說，在一些技術演講技術大會上，聽一些大牛演講常說服務限流，熔斷，降級這些東西，很多公司的流量，性能，併發達不到那麼大，對於高可用沒有高的要求，用到這些技術機會很少，所以老鐵對今天的內容很陌生，非常的感興趣，確實這是技術 BAT 用到最多的技術。所以今天一起探祕，看起來很牛逼的技術讓他技術的落地，能徹底的瞭解掌握這門技術。

分佈式系統中，會出現哪些問題？（一）

分佈式系統集羣系統中一定會遇到的一個問題：服務雪崩效應 或者叫級聯效應
那麼什麼是服務雪崩效應呢？
在一個高度服務化的系統中, 我們實現的一個業務邏輯通常會依賴多個服務, 比如:
商品詳情展示服務會依賴商品服務, 價格服務, 商品評論服務.

調用三個依賴服務會共享商品詳情服務的線程池. 如果其中的商品評論服務不可用, 就會出
現線程池裏所有線程都因等待響應而被阻塞, 從而造成服務雪崩.

服務雪崩效應：因服務提供者的不可用導致服務調用者的不可用, 並將不可用逐漸放大的過
程，就叫服務雪崩效應。

  1. 【大流量請求】：在秒殺和大促開始前, 如果準備不充分, 瞬間大量請求會造成服務提供者的
    不可用。

  2. 【硬件故障】：可能爲硬件損壞造成的服務器主機宕機, 網絡硬件故障造成的服務提供者的
    不可訪問。

  3. 【緩存擊穿】：一般發生在緩存應用重啓, 緩存失效時高併發， 所有緩存被清空時, 以及短
    時間內大量緩存失效時. 大量的緩存不命中, 使請求直擊後端, 造成服務提供者超負荷運行, 引
    起服務不可用。

  1. 【用戶重試】：在服務提供者不可用後, 用戶由於忍受不了界面上長時間的等待, 會不斷刷新頁面
    甚至提交表單。

  2. 【代碼邏輯重試】：服務調用端的會存在大量服務異常後的重試邏輯.
    這些重試最終導致：進一步加大請求流量。

大量請求線程同步等待造成的資源耗盡，當服務調用者使用同步調用 時, 會產生大量的等待線程佔用系統資源. 一旦線程資源被耗盡, 服務調用者提供的服務也將處於不可用狀態, 於是服務雪崩效應產生了。

解決方案（二）

  1. 超時機制

  2. 服務限流

  3. 服務熔斷

  4. 服務降級

服務級聯失敗（服務雪崩效應）的最根本原因是：大量請求線程同步等待造成的資源耗盡那麼，在不做任何處理的情況下，服務提供者不可用會導致消費者請求線程強制等待，而造成系統資源耗盡，而且，既然服務提供者已經不可用了，還在作死的請求的話，是毫無意義的。那麼，如果我們加入超時機制，例如 2s，那麼超過 2s 就會直接返回了，那麼這樣是不是一定程度上可以抑制消費者資源耗盡的問題。

限制請求核心服務提供者的流量，使大流量攔截在覈心服務之外，這樣可以更好的保證核心服務提供者不出問題，對於一些出問題的服務可以限制流量訪問，只分配固定線資源訪問，這樣能使整體的資源不至於被出問題的服務耗盡，進而整個系統雪崩那麼服務之間怎麼限流，怎麼資源隔離了？例如通過線程池 + 隊列的方式，通過信號量的方式。當商品評論服務不可用時, 即使商品服務獨立分配的 20 個線程全部處於同步等待狀態, 也不會影響其他依賴服務的調用.

遠程服務不穩定或網絡抖動時暫時關閉，就叫服務熔斷。舉個通俗易懂的例子，就跟我們現實生活中的 “跳閘” 一樣，跳閘應該都聽說過吧，比如說家裏有點短路了，那是不是閘會跳掉，等你把短路的問題找到並且修復後，然後你把這個閘一送，是不是整個家庭的電路又恢復了正常。這就是熔斷器。

所以，同樣的道理，當依賴的服務有大量超時時，在讓新的請求去訪問根本沒有意義，只會無畏的消耗現有資源。比如我們設置了超時時間爲 1s, 如果短時間內有大量請求在 1s 內都得不到響應，就意味着這個服務出現了異常，此時就沒有必要再讓其他的請求去訪問這個依賴了，這個時候就應該使用熔斷器避免資源浪費。

有服務熔斷，必然要有服務降級。所謂降級，就是當某個服務熔斷之後，服務將不再被調用，此時客戶端可以自己準備一個本地的 fallback（回退）回調，返回一個缺省值。例如：(備用接口 / 緩存 / mock 數據) 這樣做，雖然服務水平下降，但好歹可用，比直接掛掉要強，當然這也要看適合的業務場景。

PS：這次說了雪崩的解決方案和這幾種方案的介紹，下次講講如何通過 springclud 技術完成技術的落地。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/DY7jB5yFOJqrme5MH6tTYg

猜你喜歡