限流
C⇄S 的異常問題：C的請求太多，超出S的服務能力，導致S不可用。DoS攻擊就是根據此原理，耗盡被攻擊對象的資源，讓目標系統無法響應甚至崩潰。解決方案：S對C限流，保護S的服務資源。
限流通常在網關或網絡層面實施。對各類請求設置最高的QPS閾值，當請求高于閾值時直接阻斷。常用的限流算法有滑動計數，漏斗限流和令牌桶限流三種。
- 滑動計數限流
按時間片（比如1秒）定義滑動窗口，計數器記錄當前窗口的請求次數，達到閾值就限流，窗口滑動后計數器歸零。可采用循環隊列數據結構實現。
- 漏斗限流
維護一個隊列，所有請求進隊列，按FIFO服務，隊滿溢出則丟棄請求。
- 令牌桶限流
按固定速率往桶中存入令牌，服務前先從桶中取令牌，取到令牌才服務。
降級
C⇄S的異常問題：S自身出現異常，或者由于資源有限需要對部分C請求故意表現為異常（類似限流），為了不影響其他服務功能，主動關閉服務的一些功能。
降級的反義詞是升級，升級需要代碼開發，降級類似于把部分代碼注釋掉，犧牲部分功能。這要求S在實現時，需要具備感知異常的能力，并對關鍵邏輯實現開關控制。實際場景中，對異常的『感知』通常由熔斷器實現。
熔斷
C⇄S的異常問題：C發現S出現異常（比如大量超時），主動出擊，暫停對S的請求。
C對S熔斷后，那么原本需要調用S實現的邏輯怎么辦呢？可以用mock數據、緩存數據、缺省數據等替代，或者干脆就是拋異常返回錯誤信息。此時，如果C也是一個服務，它相當于做了服務降級。所以我們經常看到服務熔斷和服務降級一起出現（Hystrix的斷路器在實現時就是把熔斷和降級方案打包實現的）。但本質上它們不是一回事，降級發生在S，熔斷發生在C。之所以配合實現，是因為許多微服務模塊同時承擔C和S兩種角色。
熔斷的設計有兩個關鍵點：① 判斷何時熔斷，② 何時從熔斷狀態恢復。
判斷何時熔斷：通常使用無鎖循環隊列計數來實現。C對每次請求S的正常、異常（失敗、拒絕、超時）返回計數，當異常返回次數超過設定閾值時進行熔斷。
何時從熔斷狀態恢復：處于熔斷狀態時，C每隔一段時間（比如5秒），允許部分請求通過，若這部分請求正常返回，就恢復熔斷。
