1、超時（timeout）
在接口調用過程中，consumer調用provider的時候，provider在響應的時候，有可能會慢，如果provider 10s響應，那么consumer也會至少10s才響應。如果這種情況頻度很高，那么就會整體降低consumer端服務的性能。
這種響應時間慢的症狀，就會像一層一層波浪一樣，從底層系統一直涌到最上層，造成整個鏈路的超時。
所以，consumer不可能無限制地等待provider接口的返回，會設置一個時間閾值，如果超過了這個時間閾值，就不繼續等待。
這個超時時間選取，一般看provider正常響應時間是多少，再追加一個buffer即可。
2、重試（retry）
超時時間的配置是為了保護服務，避免consumer服務因為provider 響應慢而也變得響應很慢，這樣consumer可以盡量保持原有的性能。
但是也有可能provider只是偶爾抖動，那么超時后直接放棄，不做后續處理，就會導致當前請求錯誤，也會帶來業務方面的損失。
那么，對於這種偶爾抖動，可以在超時后重試一下，重試如果正常返回了，那么這次請求就被挽救了，能夠正常給前端返回數據，只不過比原來響應慢一點。
重試時的一些細化策略：
重試可以考慮切換一台機器來進行調用，因為原來機器可能由於臨時負載高而性能下降，重試會更加劇其性能問題，而換一台機器，得到更快返回的概率也更大一些。
3、熔斷（circuit break）
重試是為了應付偶爾抖動的情況，以求更多地挽回損失。
可是如果provider持續的響應時間超長呢?
如果provider是核心路徑的服務，down掉基本就沒法提供服務了，那我們也沒話說。 如果是一個不那么重要的服務，卻因為這個服務一直響應時間長導致consumer里面的核心服務也拖慢，那么就得不償失了。
單純超時也解決不了這種情況了，因為一般超時時間，都比平均響應時間長一些，現在所有的打到provider的請求都超時了，那么consumer請求provider的平均響應時間就等於超時時間了，負載也被拖下來了。
而重試則會加重這種問題，使consumer的可用性變得更差。
因此就出現了熔斷的邏輯，也就是，如果檢查出來頻繁超時，就把consumer調用provider的請求，直接短路掉，不實際調用，而是直接返回一個mock的值。等provider服務恢復穩定之后，重新調用。
4、限流(current limiting)
上面幾個策略都是consumer針對provider出現各種情況而設計的。
而provider有時候也要防范來自consumer的流量突變問題。
這樣一個場景，provider是一個核心服務，給N個consumer提供服務，突然某個consumer抽風，流量飆升，占用了provider大部分機器時間，導致其他可能更重要的consumer不能被正常服務。
所以，provider端，需要根據consumer的重要程度，以及平時的QPS大小，來給每個consumer設置一個流量上線，同一時間內只會給A consumer提供N個線程支持，超過限制則等待或者直接拒絕。
5、資源隔離
provider可以對consumer來的流量進行限流，防止provider被拖垮。
同樣，consumer 也需要對調用provider的線程資源進行隔離。 這樣可以確保調用某個provider邏輯不會耗光整個consumer的線程池資源。
6、服務降級
降級服務既可以代碼自動判斷，也可以人工根據突發情況切換。