一、服務降級的目的

為什么服務降級？

當對業務的請求超過業務系統預設的上限閾值時，為了保證基本和重要的業務模塊正常運行，

1.拒絕部分請求

2.不重要的業務模塊暫停服務或延遲提供服務。

二、服務降級的實現手段

服務降級的手段有兩大類：

第一類是關閉部分非核心服務。例如雙12當天，京東暫時關閉退貨服務。

第二類是拒絕部分請求。這里面又分成三個手段

（1）根據RPC隊列方式，把舊的請求丟棄。我們還是想想雙12買東西。在業務邏輯層pendding的舊的請求，或許客戶端已經取消了，因此要舍棄請求，一定先舍棄最久的。但這種方式有個問題，舊的請求可能是核心請求，新的可能是非核心請求的。

（2）根據請求報文CMD的優先級。在CMD列表的請求保留，不在列表中的CMD舍棄。

實際應用中，需要前兩種相結合，即（1）決定什么時候開啟、關閉丟棄  （2）決定丟棄誰

（3）隨機拒絕方式：這種不靠譜，實際環境沒人用。

三、服務降級的設計

我們將服務降級設置在什么位置？網關還是全鏈路？

1.在網關層做服務降級：

   這樣做不靠譜的地方是，因為一個網關后面可能有多個業務邏輯層。

2.全鏈路降級。也就是使用上上個圖中兩種方法結合的方式。讓網關、業務邏輯層、數據訪問層都有降級的機制。每一層能處理多少請求自己說了算。

和方案1比，方案2更靠譜。

那么，有一個小疑問，在方案2中，DB層是否需要做降級？

在上圖的模型中，讀同步寫異步。讀的時候，DAO層已經做了限流，就不用在DB層限流。在寫請求時，會先寫到MQ，所以只要是MQ沒有超限，DB就不會出現問題。

四、熔斷的實現

熔斷的實現有兩種方式：組件級、平臺級：

1.組件級解決方案

Neflix的Hystrix熔斷組件是個jar包。Hystrix的熔斷機制是API顆粒度的。如下圖所示：

前面說過，Hystrix是組件級的熔斷，好處是使用的時候，直接引入Jar包就可以。壞處是，任何要做熔斷的微服務，它的上上游都需要引入jar，而且Hystrix限制哪個API，是需要硬編碼的。

2.平臺級解決方案

如果上下游調用是RPC。我們能否把熔斷的功能寫入到RPC Client。這樣上游引入RPC Client客戶端就可以，而不需要引入單獨的jar包。此外，哪些API需要熔斷，最好寫在配置中心。

如下圖所示，我們在dashboard寫入要限制API的名稱以及參數，然后通過服務管理平臺將配置規則推送給網關。網關上的RPC Client（RPC Over TCP）可以解析這些配置，并其下游的業務邏輯層對應的API進行熔斷。

服務管理平臺的本質如下圖所示，即服務數據平臺是控制面板。

服務治理平臺實現熔斷的邏輯圖，圖示比較清楚，不再贅述：

在構建服務治理平臺時，可以參照現在市面上新型的熔斷器框架，例如Resilience4j，會有服務器模式和嵌入模式。前者會有一個獨立的 Resilience4j server，后者還是引入jar包。前者性能會好不少。