ocelot快取
閘道器除了可以做請求**外，還可以做快取功能。
在閘道器服務的自定配置檔案configuration.json中新增快取配置節點，就可以實現將相同請求在一定時間內返回同一內容，閘道器直接將後面的請求攔截並處理，請求不會被**到consul。
""filecacheoptions":filecacheoptions
":
在10秒鐘之內請求閘道器位址，返回的是同乙個內容：
ocelot限流
限制請求在1分鐘只能最多請求5次，超過5次則不可請求。5秒鐘過後可繼續請求。要完成這樣乙個需求，需要用到閘道器的限流機制。
配置檔案configuration.json中新增限流配置節點：
限流:限制單位時間內請求數量(防爬蟲,防ddos等)
"ratelimitoptions
":
"//限流:限制單位時間內請求數量(防爬蟲,防ddos等)globalconfiguration":
}
"ratelimitoptions":
"globalconfiguration":
}ratelimitoptions配置項對請求的次數和時長做具體限制。
ratelimitoptions配置項對限流後返回內容做設定，比如自定義狀態碼，用999來表示已超過最大訪問限流值。
一分鐘之內請求超過5次，會返回如下資訊：
ocelot熔斷
請求在5秒鐘之內沒有返回內容，那麼本次請求就算超時。要完成這樣乙個需求，需要用到閘道器的熔斷機制。
使用nuget在閘道器專案中引用程式集：ocelot.provider.polly
配置檔案configuration.json中新增熔斷配置節點：
熔斷:達成某些條件後,介面暫不提供服務
"qosoptions
": //熔斷:達成某些條件後,介面暫不提供服務
"qosoptions":
用一句話描述上述配置：對http://localhost:9526/apiservice/values/timeout請求超過1s將會超時，發生三次超時後保持60s熔斷。
要檢查熔斷機制有沒有生效，在webapi的控制器中加乙個方法：
讓執行緒休息6秒鐘。以達到超過配置項中1秒超時的目的。
從瀏覽器看這個請求返回503，代表請求被伺服器拒絕訪問。實際已經執行了，從log可以看出：
因為配置了熔斷策略，所以這個超過1秒鐘的請求被閘道器認為是超時請求。
可以看到在前4次請求，time在1000ms之後返回503，在第四次以後發生熔斷，請求後立即（time在100ms左右）返回503。
參考文章：
微服務熔斷原理
一 問題的產生 為什麼要引入熔斷 微服務架構的應用系統通常包含多個服務層。微服務之間通過網路進行通訊，從而支撐起整個應用系統，因此，微服務之間難免存在依賴關係。我們知道，任何微服務都並非100 可用，網路往往也很脆弱，因此難免有些請求會失敗。我們常把 基礎服務故障 導致 級聯故障 的現象稱為雪崩效應...
c 微服務Ocelot閘道器服務發現
前面提到微服務方案，介紹了該東西，推薦一篇介紹博文 我要說的是ocelot服務發現方案，其自身已經整合了consul，eureka服務發現，其專案名稱分別是ocelot.provider.consul，ocelot.provider.eureka。配置使用方法 globalconfiguration...
微服務之熔斷器
熔斷器模式可以防止應用程式不斷地嘗試執行可能會失敗的操作，使得應用程式繼續執行而不用等待修正錯誤，或者浪費cpu時間去等到長時間的超時產生。熔斷器模式也可以使應用程式能夠診斷錯誤是否已經修正，如果已經修正，應用程式會再次嘗試呼叫操作。假設我們有兩個服務servicea serviceb，servic...