雙十一當天晚上的十一點多，我下班回到家中，看到平時很早就睡覺的女朋友今天竟然還沒有睡覺。於是我問她：

服務降級：當伺服器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放伺服器資源以保證核心交易正常運作或高效運作。

服務降級

服務降級的概念聽起來可能不是很容易理解，舉一個生活中的例子就很好理解了。

有的時候我們去飯店吃飯，吃完飯以後服務員會拿一張問卷，讓就餐者填寫一下使用者反饋。但是，這種讓使用者填寫反饋的請求，只有在店裡不忙的時候才會出現。如果店裡非常忙，顧客很多的話，店員就不會再找就餐者填寫問卷了。

其實，這種就是服務降級。在人流量大的時候，使用者反饋這個功能就被降級了。因為他相對來說並沒有那麼重要。

接著再來看分散式系統的降級。

 上圖是一張淘寶商品的詳情頁，對於很多剁手黨來說這個頁面真的是再熟悉不過了。

但是，這個頁面我粗略的大致數了一下，至少有15個以上的功能模組，如：圖片、標題、定價、庫存、推薦、評價、物流、收藏、下單等。

雖然這些功能都展示在同一個頁面上，但是其實這些功能並不都是在同一個應用裡面的。這十幾個模組可能分別在十幾個應用中實現的。

詳情頁在渲染的時候，要和十幾個應用進行網路互動。

這些功能中，有一些是非常重要的，比如：定價、庫存、下單等。還有一些是相對來說沒那麼重要的，比如：推薦、收藏等。

這個識別哪些功能是核心功能、哪些功能是非核心功能，然後對非核心功能採取不通的降級方案制定的過程叫做降級預案。

雙十一當天，整個網站的流量十分巨大的，詳情頁的訪問量更是整個網站的重災之地。所以，一旦有大促的時候，需要有限保證主要功能的可用，至於那些次要的功能就可以被降級掉，即不顯示某些模組，或者返回一些預設內容。

降級的方式

還拿之前的飯店中給使用者做問卷調查的例子來說。當人流量大的時候，直接取消問卷調查只是一種方式。還有很多其他方式可以選擇的。比如：

1、先讓使用者填寫一下手機號，然後離店後，給使用者發簡訊，讓其填寫電子問卷。

2、在店門口放一個問卷，使用者離店時自己去填寫問卷。 等等，只要願意想，其實是有很多種方案的。

同樣，對於大型網站來說，服務的降級其實也是有很多方式可以選的，常見的幾種如下：

延遲服務

比如發表了評論，重要服務，比如在文章中顯示正常，但是延遲給使用者增加積分，只是放到一個快取中，等服務平穩之後再執行。

在粒度範圍內關閉服務（片段降級或服務功能降級）

比如關閉相關文章的推薦，直接關閉推薦區

頁面非同步請求降級

比如商品詳情頁上有推薦資訊/配送至等非同步載入的請求，如果這些資訊響應慢或者後端服務有問題，可以進行降級； 頁面跳轉（頁面降級）

比如可以有相關文章推薦，但是更多的頁面則直接跳轉到某一個地址。

寫降級

比如秒殺搶購，我們可以只進行Cache的更新，然後非同步同步扣減庫存到DB，保證最終一致性即可，此時可以將DB降級為Cache。

讀降級

比如多級快取模式，如果後端服務有問題，可以降級為只讀快取，這種方式適用於對讀一致性要求不高的場景；

降級的介入方式

按照是不是可以自動化降級，降級共有兩種介入方式，分別是：自動開關降級和人工開關降級。

 自動開關降級

自動開關降級的方式一般是當系統達到某些設定的條件（系統負載、資源使用情況、SLA等指標）之後，自動執行一些策略。

常見的可以作為自動降級條件的指標有以下幾個：

服務超時

當訪問的資料庫/http服務/遠端呼叫響應慢或者長時間響應慢，且該服務不是核心服務的話可以在超時後自動降級；

比如前面提到的詳情頁上有推薦和收藏功能，即使出現問題也不會影響使用者的正常下單。如果是呼叫別人的遠端服務，和對方定義一個服務響應最大時間，如果超時了則可以自動降級。

失敗次數

呼叫外部服務的時候，除了超時意外，最常見的異常情況就是呼叫失敗。比如詳情頁中的庫存資訊，如果是某一次查詢請求失敗了，那麼可以那麼就可以通過讀取快取資料等方式直接降級掉。

但是，這種降級可能存在一個問題，就是雖然一次請求展示了快取，但是其他使用者訪問的時候還是會查詢庫存資訊，這對於庫存系統來說就是雪上加霜。因為他可能已經有問題了，但是上游系統還是在不斷的對他傳送請求。

所以，可以針對這個查詢庫存的介面做統一的降級。設定一個失敗次數的閾值，一旦整體失敗次數達到這個閾值了，就對後續一段時間內的改查詢介面做降級。直到其功能恢復。

發生故障

上面提到的失敗可能是服務不穩定造成的，過一段時間可以自動恢復的。還有一種情況可能是依賴的服務徹底跪了、或者網路不通了等等。這種情況就可以直接降級了。

當HTTP請求返回固定的錯誤碼、或者一個RPC請求的時候底層服務拋了異常以後，就認為有故障發生，對其進行降級即可。

限流降級

還有種電商網站常見的策略，那就是限流降級。對於某些功能，設定一個流量閾值，一旦流量達到閾值的話，就進行降級。

比如秒殺功能，如果一瞬間流量太大，就可以進行限流降級。對於後續訪問的使用者直接提示已售空、跳轉錯誤頁、或者讓他輸入驗證碼重試等。

人工開關降級

還有一種降級方式，那就是人工開關降級。

人工開關降級的方式是指當系統維護人員在發現系統異常之後，通過人工修改引數、關閉服務等方式進行降級的方法。

這種方式的好處是比較靈活，能夠根據異常情況靈活應對；但弊端是對人的要求比較高，一來需要維護人員對系統有足夠的瞭解，另外要求維護人員在系統異常時能夠在第一時間進行處置。

還有一種情況，可能也會人工介入，那就是在大促之前，預估到流量會十分巨大，提早的識別出風險，為了節省資源保證主流程的可用，開發人員可以手動將某個功能降級掉。

這裡說的人工開關降級，並不一定是一定要人工操作，也可能是人工通過一個定時任務進行定時觸發的。

降級工具

目前市面上，針對流量控制，限流降級主要有以下兩種選擇：Netflix Hystrix 和 Alibaba Sentinal。

Hystrix

Hystrix是一個庫，它提供了服務與服務之間的容錯功能，主要體現在延遲容錯和容錯，從而做到控制分散式系統中的聯動故障。Hystrix通過隔離服務的訪問點，阻止聯動故障，並提供故障的解決方案，從而提高了這個分散式系統的彈性。

Hystrix 的關注點在於以 隔離 和 熔斷 為主的容錯機制，超時或被熔斷的呼叫將會快速失敗，並可以提供 fallback 機制。

Sentinel

Sentinel 是阿里中介軟體團隊開源的，面向分散式服務架構的輕量級高可用流量控制組件，主要以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度來幫助使用者保護服務的穩定性。

Sentinel 的側重點在於：多樣化的流量控制、熔斷降級、系統負載保護、實時監控和控制檯等

對比

 上圖是Sentinel的文件中，關於Sentinel-與-Hystrix-的對比。