基本概念
超時、熔斷、限流聽起來好像很遠，但實際上用在方方面面。很多人可能還搞不懂熔斷是做什麼，其實可以把熔斷理解為一種防護措施。做個假設，在微服務體系下，某個下游服務響應很慢，然後隨著時間推移，會有越來越多的請求堆積，從而會導致各種嚴重後果，單說連線池大量被佔用就很要命。更不用說服務之間還要相互呼叫，你等我10秒，我等你5秒，不僅毫無體驗感，高可用也就成了空談。不如換個思路：與其等10秒返回一個請求失敗，不如馬上就返回請求失敗。這樣一來，請求堆不起來，資源也有時間釋放或者恢復。這個動作就叫熔斷，或者叫短路。有點像家用電路，一旦有漏電直接跳閘，最大程度保障安全。
熔斷的概念基本有了，接下來給閘道器整合。這裡需要用到一個叫polly的庫。
簡單說下它：polly由.net實現，是一個非常優秀的庫，主要提供重試、熔斷、超時、恢復等功能，當然今天主角不是它，想研究的可以去官方看下：https://github.com/App-vNext/Polly
接下來開始整合。首先新增nuget包：
然後註冊相關服務：
public void ConfigureServices(IServiceCollection services)
{
services.AddOcelot()
.AddPolly()
.AddConsul()
.AddConfigStoredInConsul();
}
接下來在配置檔案新增節點：
"QoSOptions": {
"ExceptionsAllowedBeforeBreaking":3,
"DurationOfBreak":10000,
"TimeoutValue":5000
}
ExceptionsAllowedBeforeBreaking：閾值，當轉發到下游的服務連續出現的異常次數達到閾值就會觸發熔斷。必須和DurationOfBreak一起設定。
DurationOfBreak：熔斷持續時間，單位毫秒。必須和ExceptionsAllowedBeforeBreaking一起設定。
TimeoutValue：限定時間內未響應的請求直接超時，單位毫秒。可以單獨設定
tips：ocelot預設超時時間是90秒，90秒啊
然後寫一個方法，休眠10秒：
[HttpGet]
public IActionResult TimeOut()
{
System.Threading.Thread.Sleep(10000);
return Ok();
}
超時
準備工作做完了，現在呼叫timeout方法：
方法是休眠10秒，但是等待5秒左右就主動返回了503，說明超時的設定已經生效。
熔斷
當轉發到下游某個服務的請求連續出現超時情況時，閘道器就會判斷是否達到閾值，如果是就觸發熔斷，在此期間的請求統一返回503，熔斷時間過了以後恢復正常。按上面配置來看：連續超時3次會觸發熔斷，熔斷持續10秒。我們仍然呼叫Timeout方法，連續3次以後：
沒有觸發熔斷時，只能等過5秒自動超時，很顯然現在已經觸發了超時，所以在200毫秒就直接返回了結果。熔斷期間訪問別的方法也會是503：
和開頭寫的一樣，熔斷和電路短路跳閘是思路是一樣的，就算家裡N條線只有1條漏電，那還是會跳閘整個屋子不能用電，這種做法最大程度上保證了程式安全。
限流
假設現在只能承載1萬併發，那麼過來5萬併發會怎麼樣？一般情況下，只要持續時間稍久一些，服務基本全都掛了。這種情況在生產環境難免會發生，畢竟業務量也無法測算那麼精準。所以為了提高可用性，瞬時請求超過最大閾值，其他的全都忽略才能保證服務安全可用。讓客戶等下一次請求，總好過服務掛了沒的請求。
限流也是配置就能實現，在路由中新增下面的節點：
"RateLimitOptions": {
"ClientWhitelist": [],
"EnableRateLimiting": true,
"Period": "1s",
"PeriodTimespan": 1,
"Limit": 1
}
ClientWhitelist：客戶端白名單，白名單不受限流規則限制。
EnableRateLimiting：是否啟用限流。
Period：週期，單位有s(秒)、m(分)、h(時)、d(天)，比如1h
PeriodTimespan：多少秒後重試。
Limit：週期內允許多少個請求。
想要更精細的控制，還可以在Global部分新增這些：
"RateLimitOptions": {
"DisableRateLimitHeaders": false,
"QuotaExceededMessage": "Customize Tips!",
"HttpStatusCode": 999,
"ClientIdHeader" : "Test"
}
DisableRateLimitHeaders：是否禁用X-Rate-Limit、Retry-After標頭。
QuotaExceededMessage：觸發限流時返回的訊息。
HttpStatusCode：觸發限流時返回的http狀態碼（一般會寫429）。
ClientIdHeader：用來識別客戶端的標頭。
tips：DisableRateLimitHeaders中提到的X-Rate-Limit、Retry-After：X-Rate-Limit——標準時間內允許多少個請求，Retry-After——觸發限流以後多久可以重試。
接下來修改我的配置：
"RateLimitOptions": {
"ClientWhitelist": [ "myclient" ],
"EnableRateLimiting": true,
"Period": "1s",
"PeriodTimespan": 10,
"Limit": 1
}
修改全域性配置：
"RateLimitOptions": {
"DisableRateLimitHeaders": false,
"QuotaExceededMessage": "123123",
"HttpStatusCode": 429,
"ClientIdHeader": "Test"
}
按配置來看，我設定1秒內最多允許1個請求，超過就觸發限流。之後的請求都會返回429和123123，持續10秒。來試試：
等待10秒後再次請求，恢復正常：
白名單
白名單裡的客戶端是不會受到限流限制的。按照配置新增請求頭，就可以被白名單識別：
請求時新增這個請求頭，無論怎麼刷都不會被限流。
超時、熔斷、限流的必要性和好處是不言而喻的，但是上生產一定要注意配置的合理性，充分綜合業務場景和需要才是王道，畢竟技術如果不解決問題那就毫無意義。