一、問題的產生（為什麼要引入熔斷）
微服務架構的應用系統通常包含多個服務層。微服務之間通過網路進行通訊，從而支撐起整個應用系統，因此，微服務之間難免存在依賴關係。我們知道，任何微服務都並非100%可用，網路往往也很脆弱，因此難免有些請求會失敗。
我們常把「基礎服務故障」導致「級聯故障」的現象稱為雪崩效應。雪崩效應描述的是提供者不可用導致消費者不可用，並將不可用逐漸放大的過程。
如下圖所示：a作為服務提供者，b為a的服務消費者，c和d是b的服務消費者。a不可用引起了b的不可用，並將不可用像滾雪球一樣放大到c和d時，雪崩效應就形成了。
要想防止雪崩效應，必須有乙個強大的容錯機制。該容錯機制需要實現以下兩點。
一次遠端呼叫對應著乙個執行緒/程序。如果響應太慢，這個執行緒/程序就得不到釋放。而執行緒/程序又對應著系統資源，如果得不到釋放的執行緒/程序越積越多，資源就會被逐漸耗盡，最終導致服務的不可用。
因此，必須為每個網路請求設定超時，讓資源盡快釋放
熔斷器的原理很簡單，如同電力過載保護器。它可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤，會強迫其以後的多個呼叫快速失敗，不再訪問遠端伺服器，從而防止應用程式不斷地嘗試執行可能會失敗的操作，使得應用程式繼續執行而不用等待修正錯誤，或者浪費cpu時間去等到長時間的超時產生。熔斷器也可以使應用程式能夠診斷錯誤是否已經修正，如果已經修正，應用程式會再次嘗試呼叫操作。
熔斷器模式就像是那些容易導致錯誤的操作的一種**。這種**能夠記錄最近呼叫發生錯誤的次數，然後決定使用允許操作繼續，或者立即返回錯誤。
熔斷器開關相互轉換的邏輯如下圖：
—正常情況下，斷路器關閉，可正常請求服務。
—當一段請求過後，請求失敗率達到一定閾值，例如錯誤率50%，熔斷器就會開啟，因此，不會再去請求依賴的服務。
—斷路器開啟一段時間後，會自動進入「半開」狀態。此時，熔斷器可允許少量請求訪問依賴的服務。如果成功，則關閉熔斷器；否則繼續轉為開啟狀態。
resilience4j在請求數量達到設定的緩衝池大小時才會進行失敗率計算，計算完成後會清空緩衝池，所以熔斷的間隔是一輪緩衝池大小，不是每請求失敗一次就熔斷一次，不是用滑動視窗計算失敗率，也跟時間無關，緩衝池邏輯結構圖如下所示：
熔斷器的環形緩衝池
熔斷器就是保護服務高可用的最後一道防線。
resilience4j circuitbreaker工作流程圖
熔斷器方案：resilience4j circuitbreaker,resilience4j retrofit。
熔斷器通過circuitbreaker.onsuccess(durationinnanos)和 circuitbreaker.onerror(durationinnanos, throwable)來統計失敗率
staticsupplierdecoratesupplier(circuitbreaker circuitbreaker, suppliersupplier)catch(throwable throwable)
};
}
onsuccess()和onfailure()**
floatonsuccess()
floatonerror()
privatefloatgetfailurerate(intnumberoffailedcalls)
returnnumberoffailedcalls *100.0f / ringbuffersize;
}
微服務 Ocelot熔斷
ocelot快取 閘道器除了可以做請求 外，還可以做快取功能。在閘道器服務的自定配置檔案configuration.json中新增快取配置節點，就可以實現將相同請求在一定時間內返回同一內容，閘道器直接將後面的請求攔截並處理，請求不會被 到consul。filecacheoptions filecac...
微服務之熔斷器
熔斷器模式可以防止應用程式不斷地嘗試執行可能會失敗的操作，使得應用程式繼續執行而不用等待修正錯誤，或者浪費cpu時間去等到長時間的超時產生。熔斷器模式也可以使應用程式能夠診斷錯誤是否已經修正，如果已經修正，應用程式會再次嘗試呼叫操作。假設我們有兩個服務servicea serviceb，servic...
微服務之熔斷 降級 限流
在io型服務中，假設服務a依賴服務b和服務c，而b服務和c服務有可能繼續依賴其他的服務，繼續下去會使得呼叫鏈路過長。如果在a的鏈路上某個或幾個被呼叫的子服務不可用或延遲較高，則會導致呼叫a服務的請求被堵住。堵住的請求會消耗占用掉系統的執行緒 io等資源，當該類請求越來越多，占用的計算機資源越來越多的...