一、服務(wù)降級的目的

為什么服務(wù)降級？

當(dāng)對業(yè)務(wù)的請求超過業(yè)務(wù)系統(tǒng)預(yù)設(shè)的上限閾值時，為了保證基本和重要的業(yè)務(wù)模塊正常運行，

1.拒絕部分請求

2.不重要的業(yè)務(wù)模塊暫停服務(wù)或延遲提供服務(wù)。

二、服務(wù)降級的實現(xiàn)手段

服務(wù)降級的手段有兩大類：

第一類是關(guān)閉部分非核心服務(wù)。例如雙12當(dāng)天，京東暫時關(guān)閉退貨服務(wù)。

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

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

（2）根據(jù)請求報文CMD的優(yōu)先級。在CMD列表的請求保留，不在列表中的CMD舍棄。

實際應(yīng)用中，需要前兩種相結(jié)合，即（1）決定什么時候開啟、關(guān)閉丟棄  （2）決定丟棄誰

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

三、服務(wù)降級的設(shè)計

我們將服務(wù)降級設(shè)置在什么位置？網(wǎng)關(guān)還是全鏈路？

1.在網(wǎng)關(guān)層做服務(wù)降級：

   這樣做不靠譜的地方是，因為一個網(wǎng)關(guān)后面可能有多個業(yè)務(wù)邏輯層。

2.全鏈路降級。也就是使用上上個圖中兩種方法結(jié)合的方式。讓網(wǎng)關(guān)、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問層都有降級的機制。每一層能處理多少請求自己說了算。

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

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

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

四、熔斷的實現(xiàn)

熔斷的實現(xiàn)有兩種方式：組件級、平臺級：

1.組件級解決方案

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

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

2.平臺級解決方案

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

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

服務(wù)管理平臺的本質(zhì)如下圖所示，即服務(wù)數(shù)據(jù)平臺是控制面板。

服務(wù)治理平臺實現(xiàn)熔斷的邏輯圖，圖示比較清楚，不再贅述：

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