微服務之熔斷降級限流

在io型服務中，假設服務a依賴服務b和服務c，而b服務和c服務有可能繼續依賴其他的服務，繼續下去會使得呼叫鏈路過長。如果在a的鏈路上某個或幾個被呼叫的子服務不可用或延遲較高，則會導致呼叫a服務的請求被堵住。

堵住的請求會消耗占用掉系統的執行緒、io等資源，當該類請求越來越多，占用的計算機資源越來越多的時候，會導致系統瓶頸出現，造成其他的請求同樣不可用，最終導致業務系統崩潰，雪崩效應。

當服務者無法正常為消費者提供服務時，如請求超時、後台服務無響應、後台服務異常等，通過容斷機制直接返回統一處理結果，並對下次請求進行同樣處理，直到後台服務功能正常。

微服務的提供者可能是乙個基礎服務也能是乙個聚合服務，當消費者的請求到來，如果服務中的乙個或者幾個無法正常工作（掛了），此時在不做任何處理的情況下，消費者只能等待，直到超時，在高負載場景下，此類問題可能會導致服務提供者的資源耗盡甚至整個系統崩潰。

防止爆發式流量直接壓到後台服務例項，造成資源耗盡、甚至應用崩潰

控制訪問流量，通過指定的策略消減流量（如網路層面限制訪問流量、後服務例項使用技術手段限制併發數量等），使得落到後台服務例項的請求在能承受的範圍內。高併發是常常討論的話題，如何限流，以及服務的例項能承受的範圍是多大，什麼情況下需要增加服務例項，調整資源，都需要結合實際進行嚴格的測試。

這樣乙個場景，provider是乙個核心服務，給n個consumer提供服務，突然某個consumer抽風，流量飆公升，占用了provider大部分機器時間，導致其他可能更重要的consumer不能被正常服務。

所以，provider端，需要根據consumer的重要程度，以及平時的qps大小，來給每個consumer設定乙個流量上線，同一時間內只會給a consumer提供n個執行緒支援，超過限制則等待或者直接拒絕。

常見的限流演算法有：令牌桶、漏桶。計數器也可以進行粗暴限流實現。

當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的效能時，仍然需要保證服務還是可用的，即使是有損服務。

棄卒保帥，最終目的是保證核心服務可用，即使是有損的。但是核心服務肯定是無法捨棄的，捨棄也就意味著應用系統無法正常工作。只能是一種保障或者拯救措施。

觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；

管理目標的層次不太一樣，熔斷其實是乙個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）

微服務之熔斷 降級 限流