微服務架構—服務降級

1 簡介

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

        若是仍是不理解，那麼能夠舉個栗子：假如目前有不少人想要給我付錢，但個人服務器除了正在運行支付的服務以外，還有一些其它的服務在運行，好比搜索、定時任務和詳情等等。然而這些不重要的服務就佔用了JVM的很多內存與CPU資源，爲了能把錢都收下來（錢纔是目標），我設計了一個動態開關，把這些不重要的服務直接在最外層拒掉，這樣處理後的後端處理收錢的服務就有更多的資源來收錢了（收錢速度更快了），這就是一個簡單的服務降級的使用場景。

2 使用場景

        服務降級主要用於什麼場景呢？當整個微服務架構總體的負載超出了預設的上限閾值或即將到來的流量預計將會超過預設的閾值時，爲了保證重要或基本的服務能正常運行，咱們能夠將一些 不重要 或 不緊急 的服務或任務進行服務的 延遲使用 或 暫停使用。

3 核心設計

3.1 分佈式開關

        根據上述需求，咱們能夠設置一個分佈式開關，用於實現服務的降級，而後集中式管理開關配置信息便可。具體方案以下：

服務降級-分佈式開關

3.2 自動降級

• 超時降級 —— 主要配置好超時時間和超時重試次數和機制，並使用異步機制探測恢復狀況

• 失敗次數降級 —— 主要是一些不穩定的API，當失敗調用次數達到必定閥值自動降級，一樣要使用異步機制探測回覆狀況

• 故障降級 —— 如要調用的遠程服務掛掉了（網絡故障、DNS故障、HTTP服務返回錯誤的狀態碼和RPC服務拋出異常），則能夠直接降級

• 限流降級 —— 當觸發了限流超額時，可使用暫時屏蔽的方式來進行短暫的屏蔽

        當咱們去秒殺或者搶購一些限購商品時，此時可能會由於訪問量太大而致使系統崩潰，此時開發者會使用限流來進行限制訪問量，當達到限流閥值，後續請求會被降級；降級後的處理方案能夠是：排隊頁面（將用戶導流到排隊頁面等一會重試）、無貨（直接告知用戶沒貨了）、錯誤頁（如活動太火爆了，稍後重試）。

3.3 配置中心

        微服務降級的配置信息是集中式的管理，而後經過可視化界面進行友好型的操做。配置中心和應用之間須要網絡通訊，所以可能會因網絡閃斷或網絡重啓等因素，致使配置推送信息丟失、重啓或網絡恢復後不能再接受、變動不及時等等狀況，所以服務降級的配置中心須要實現如下幾點特性，從而儘量的保證配置變動即便達到：

服務降級-配置中心

• 啓動主動拉取配置 —— 用於初始化配置（減小第一次定時拉取週期）

• 發佈訂閱配置 —— 用於實現配置及時變動（能夠解決90%左右的配置變動）

• 定時拉取配置 —— 用於解決發佈訂閱失效或消失丟失的狀況（能夠解決9%左右的發佈訂閱失效的消息變動）

• 離線文件緩存配置 —— 用於臨時解決重啓後鏈接不上配置中心的問題

• 可編輯式配置文檔 —— 用於直接編輯文檔的方式來實現配置的定義

• 提供Telnet命令變動配置 —— 用於解決配置中心失效而不能變動配置的常見

3.4 處理策略

        當觸發服務降級後，新的交易再次到達時，咱們該如何來處理這些請求呢？從微服務架構全局的視角來看，咱們一般有如下是幾種經常使用的降級處理方案：

• 頁面降級 —— 可視化界面禁用點擊按鈕、調整靜態頁面

• 延遲服務 —— 如定時任務延遲處理、消息入MQ後延遲處理

• 寫降級 —— 直接禁止相關寫操做的服務請求

• 讀降級 —— 直接禁止相關度的服務請求

• 緩存降級 —— 使用緩存方式來降級部分讀頻繁的服務接口

        針對後端代碼層面的降級處理策略，則咱們一般使用如下幾種處理措施進行降級處理：

• 拋異常

• 返回NULL

• 調用Mock數據

• 調用Fallback處理邏輯

4 高級特性

        咱們已經爲每一個服務都作好了一個降級開關，也已經在線上驗證經過了，感受徹底沒問題了。
        場景一：某一天，運營搞了一次活動，忽然跑過來講，如今流量已經快漲到上限了，有沒有批量降級全部不重要服務的方式？開發一臉懵逼的看着，這又不是操做DB，哪裏有批量操做呀。
        場景二：某一天，運營又搞事了，說咱們等下要搞一個活動，讓咱們趕忙提早把不重要的服務都降級了，開發又是一臉懵逼，我怎麼知道要降級哪些服務呀。
        反思：服務降級的功能雖然是實現了，但是沒有考慮實施時的體驗。服務太多，不知道該降級哪些服務，單個操做降級速度太慢……

4.1 分級降級

        當微服務架構發生不一樣程度的狀況時，咱們能夠根據服務的對比而進行選擇式捨棄（即丟車保帥的原則），從而進一步保障核心的服務的正常運做。

        若是等線上服務即將發生故障時，纔去逐個選擇哪些服務該降級、哪些服務不能降級，然而線上有成百上千個服務，則確定是來不及降級就會被拖垮。同時，在大促或秒殺等活動前纔去梳理，也是會有很多的工做量，所以建議在開發期就須要架構師或核心開發人員來提早梳理好，是否能降級的初始評估值，便是否能降級的默認值。

        爲了便於批量操做微服務架構中服務的降級，咱們能夠從全局的角度來創建服務重要程度的評估模型，若是有條件的話，建議可使用 層次分析法（The analytic hierarchy process，簡稱AHP） 的數學建模模型（或其它模型）來進行定性和定量的評估（確定比架構師直接拍腦殼決定是否降級好不少倍，固然難度和複雜度也會高許多，即你須要一個會數學建模人才），而層次分析法的基本思路是人對一個複雜的決策問題的思惟和判斷過程大致上是同樣的。

        如下是我的給出的最終評價模型，可做爲服務降級的評價參考模型進行設計：

        咱們利用數學建模的方式或架構師直接拍腦殼的方式，結合服務可否降級的優先原則，並根據颱風預警（都屬於風暴預警）的等級進行參考設計，可將微服務架構的全部服務進行故障風暴等級劃分爲如下四種：

評估模型：

• 藍色風暴 —— 表示須要小規模降級非核心服務

• 黃色風暴 —— 表示須要中等規模降級非核心服務

• 橙色風暴 —— 表示須要大規模降級非核心服務

• 紅色風暴 —— 表示必須降級全部非核心服務

設計說明：

• 故障嚴重程度爲：藍色＜黃色＜橙色＜紅色

• 建議根據二八原則能夠將服務劃分爲：80%的非核心服務+20%的核心服務

        以上模型只是總體微服務架構的服務降級評估模型，具體大促或秒殺活動時，建議以具體主題爲中心進行創建（不一樣主題的活動，因其依賴的服務不一樣，而使用不一樣的進行降級更爲合理）。固然模型可使用同一個，但其數據須要有所差別。最好能創建一套模型庫，而後實施時只須要輸入相關服務便可輸出最終降級方案，即輸出本次大促或秒殺時，當發生藍色風暴時須要降級的服務清單、當發生黃色風暴時須要降級的服務清單……

4.2 降級權值

        微服務架構中有服務權值的概念，主要用於負載時的權重選擇，一樣服務降級權值也是相似，主要用於服務降級選擇時的細粒度優先級抉擇。全部的服務直接使用以上簡單的四級劃分方式進行統一處理，顯然粒度太粗，或者說出於同一級的多個服務須要降級時的 降級順序 該如何？甚至我想要人工智能化的 自動降級，又該如何更細粒度的控制？

        基於上述的這些AI化的需求，咱們能夠爲每個服務分配一個降級權值，從而便於更加智能化的實現服務治理。而其評估的數值，一樣也可使用數學模型的方式進行 定性 與 定量 的評估出來，也能夠架構師根據經驗直接拍腦殼來肯定。