相關文章
Consul+Ocelot+Polly在.NetCore中使用(.NET5)-Consul服務注冊，服務發現
Consul+Ocelot+Polly在.NetCore中使用(.NET5)-網關Ocelot+Consul
Consul+Ocelot+Polly在.NetCore中使用(.NET5)-Ocelot+Polly緩存、限流、熔斷、降級
微服務網關Ocelot加入IdentityServer4鑒權-.NetCore(.NET5)中使用
環境Ocelot包版本17.0.0
一、簡介
Polly 是一個 .NET 彈性和瞬態故障處理庫，允許開發人員以線程安全的方式來實現重試、斷路、超時、隔離和回退策略。
瞬態故障就是可能會出現的，比喻網絡不穩定或無法訪問，或服務宕機。
二、Ocelot各種策略使用和解釋
下面各種策略都是基於前一篇Ocelot+Consul的配置基礎上修改。
2.1Ocelot緩存
緩存能有效提升程序性能
在ocelot.json中增加緩存配置
{ "Routes": [ { //轉發到下游服務地址--url變量 "DownstreamPathTemplate": "/api/{url}", //下游http協議 "DownstreamScheme": "http", //負載方式， "LoadBalancerOptions": { "Type": "RoundRobin" // 輪詢 }, //上游地址 "UpstreamPathTemplate": "/T1/{url}", //網關地址--url變量 //沖突的還可以加權重Priority "UpstreamHttpMethod": [ "GET", "POST", "DELETE", "PUT" ], "UseServiceDisConvery": true, //使用服務發現 "ServiceName": "api", //Consul服務名稱 //緩存設置 "FileCacheOptions": { "TtlSeconds": 10, //緩存10s（同一個地址請求就返回緩存結果) "Region": ""//緩存region } } ], "GlobalConfiguration": { //Ocelot應用地址 "BaseUrl": "http://172.16.2.9:5200", "ServiceDiscoveryProvider": { //Consul地址 "Host": "172.16.2.84", //Consul端口 "Port": 8500, "Type": "Consul"//由Consul提供服務發現，每次請求Consul } } }
緩存是針對下游地址緩存的，同一個地址請求返回相同數據，所以針對一些不變的數據才能做緩存，根據用戶登錄信息不同返回不同數據的就不能做了。
測試：訪問 http://172.16.2.9:5200/T1/Test/GetName
刷新后還是5201端口數據，說明是從緩存取的
10s后刷新端口變成5202
2.2Ocelot限流
為什么要限流呢，防止請求過多把程序搞宕機了，也可以有效防止爬蟲和ddos攻擊，預估出服務的處理能力，然后設置限流，可以限制單位時間內的訪問量（失敗一部分請求比整個服務掛掉強）。
ocelot.json文件增加限流配置
{ "Routes": [ { //轉發到下游服務地址--url變量 "DownstreamPathTemplate": "/api/{url}", //下游http協議 "DownstreamScheme": "http", //負載方式， "LoadBalancerOptions": { "Type": "RoundRobin" // 輪詢 }, //上游地址 "UpstreamPathTemplate": "/T1/{url}", //網關地址--url變量 //沖突的還可以加權重Priority "UpstreamHttpMethod": [ "GET", "POST", "DELETE", "PUT" ], "UseServiceDisConvery": true, //使用服務發現 "ServiceName": "api", //Consul服務名稱 //限流配置 "RateLimitOptions": { "ClientWhitelist": [ "admin" ], // 白名單 "EnableRateLimiting": true, // 是否啟用限流 "Period": "10s", // 統計時間段：1s, 5m, 1h, 1d "PeriodTimespan": 10, // 多少秒之后客戶端可以重試 "Limit": 5 // 在統計時間段內允許的最大請求數量 } } ], "GlobalConfiguration": { //Ocelot應用地址 "BaseUrl": "http://172.16.2.9:5200", "ServiceDiscoveryProvider": { //Consul地址 "Host": "172.16.2.84", //Consul端口 "Port": 8500, "Type": "Consul" //由Consul提供服務發現，每次請求Consul }, //限流 "RateLimitOptions": { "QuotaExceededMessage": "errr:request fast!", //限流后響應內容 "HttpStatusCode": 666, //http狀態碼可以自定義
"ClientIdHeader": "client_id" // 用來識別客戶端的請求頭，默認是 ClientId
} } }
這里用Postman來演示比較直觀。
可以看到，在10s內請求了5次之后的請求就失敗了，返回的狀態碼是自定義的666，然后等10s過后又恢復訪問，上面設置的白名單在Headers加上就可以
不受限流影響，可以無限訪問。
2.3Ocelot+Polly的熔斷
安裝NuGet包 Ocelot.Provider.Polly。
Startup.cs增加 .AddPolly()
public void ConfigureServices(IServiceCollection services) { services.AddOcelot() .AddConsul() .AddPolly(); }
Ocelot.Provider.Polly的熔斷機制是一個超時和熔斷的組合，（Polly有超時策略，熔斷策略，這里是2個策略的結合使用，下面Polly策略會說到)，所以如果是單單是服務報500異常是觸發不了的。
接口超過多長時間進入半熔斷狀態，返回服務不可用， 連續超過多少次進入熔斷狀態就直接停掉該請求返回，多長時間再恢復。
修改ocelot.json配置
//*****************************單地址******************************** { "Routes": [ { //轉發到下游服務地址--url變量 "DownstreamPathTemplate": "/api/{url}", //下游http協議 "DownstreamScheme": "http", //負載方式， "LoadBalancerOptions": { "Type": "RoundRobin" // 輪詢 }, //上游地址 "UpstreamPathTemplate": "/T1/{url}", //網關地址--url變量 //沖突的還可以加權重Priority "UpstreamHttpMethod": [ "GET", "POST", "DELETE", "PUT" ], "UseServiceDisConvery": true, //使用服務發現 "ServiceName": "api", //Consul服務名稱 //熔斷設置 "QoSOptions": { "ExceptionsAllowedBeforeBreaking": 3, //允許多少個異常請求 "DurationOfBreak": 5000, // 熔斷的時間5s，單位為ms "TimeoutValue": 5000 //單位ms,如果下游請求的處理時間超過多少則自如將請求設置為超時 默認90秒 } } ], "GlobalConfiguration": { //Ocelot應用對外地址 "BaseUrl": "http://172.16.2.9:5200", "ServiceDiscoveryProvider": { //Consul地址 "Host": "172.16.2.84", //Consul端口 "Port": 8500, "Type": "Consul" //由Consul提供服務發現，每次請求Consul } } }
在之前啟動的3個服務增加一個拋異常的接口和一個睡眠接口。
[Route("api/[controller]/[action]")] public class TestController : Controller { private IConfiguration _configuration; public TestController(IConfiguration configuration) { _configuration = configuration; } public IActionResult GetName() { string port = _configuration["port"]; return Json($"端口:{port}，姓名:張三"); }public IActionResult GetSleep() { string port = _configuration["port"]; //線程睡眠6s Thread.Sleep(6000); return Json($"端口:{port}，睡眠6s后返回"); } }
訪問GetSleep()接口，前三次等待6s返回503，后面訪問什么接口都是快速返回503，服務熔斷。
三、Polly各種策略使用和解釋
上面網關處做了Ocelot+Polly的熔斷策略，然后服務鏈上也是需要做一些策略，這里介紹的是在服務里用Polly做各種常用的策略。
3.1Polly降級
降級就是當我們指定的代碼處理失敗時就執行我們備用的代碼。
現在在之前的三個服務中加入Polly降級策略
安裝NuGet包 --Polly
新建一個OrderController.cs
[Route("api/[controller]/[action]")] public class OrderController : Controller { private readonly OrderService _orderService; public OrderController(OrderService orderService) { _orderService = orderService; } public IActionResult CreateOrder() { string result = _orderService.CreateOrder(); return Content(result); } }
新建一個OrderService.cs
public class OrderService { private Policy<string> _policy; public OrderService() { //降級 _policy = Policy<string> .Handle<Exception>() //異常故障 .Fallback(() => { //降級回調 todo降級后邏輯 return "降級后的值"; }); } public string CreateOrder() { //用polly執行 return _policy.Execute(() => { //業務邏輯 todo Console.WriteLine($"{DateTime.Now},開始處理業務"); throw new Exception("233出錯啦"); Console.WriteLine("處理完成"); return "成功啦"; }); } }
把OrderService注入IOC容器，注意，使用Polly時，實例一定要以單例模式注入，因為如果是每次都執行構造函數給_policy賦一次值，那_policy每次都是全新的，下面的熔斷策畋會不生效。
Startup.cs中的ConfigureServices()加上
public void ConfigureServices(IServiceCollection services) { services.AddControllersWithViews(); services.AddControllers().AddJsonOptions(cfg => { services.AddSingleton<OrderService>(); }
測試，訪問http://ip:端口/api/Order/CreateOrder
可以看到返回的是降級后處理的值。
3.2Polly熔斷
熔斷就是當一處代碼報錯超過多少次，就讓它熔斷多長時間再恢復，熔斷時Polly會截斷請求，不會再進入到具體業務，這能有效減少沒必要的業務性能損耗。
把OrderService構建函數處改成
public OrderService() { //熔斷 _policy = Policy<string>.Handle<Exception>() .CircuitBreaker(5, TimeSpan.FromSeconds(10));//連續出錯5次后熔斷10秒，不會在進到業務代碼 }
測試結果：
5次前的返回：
熔斷后返回：
3.3Polly重試
把OrderService的構造函數處修改為：
public OrderService() { //重試 //RetryForever()是一直重試直到成功 //Retry()是重試最多一次； //Retry(n) 是重試最多n次； //WaitAndRetry()可以實現“如果出錯等待100ms再試還不行再等150ms秒。 _policy = Policy<string>.Handle<Exception>() .WaitAndRetry(new TimeSpan[] { TimeSpan.FromSeconds(5), TimeSpan.FromSeconds(10), TimeSpan.FromSeconds(15) }); }
這里是業務處理失敗時,重試3次，分別隔5s,10s,15s。
測試結果：
可以看到，第一次執行因為有異常，然后分別隔5s,10s,15s重試，最后才拋出了異常。
3.4Polly超時
所謂超時，就是我們指定一段代碼的最大運行時間，如果超過這段時間還沒有完成，就直接拋出異常。
這里判斷超時有兩種策略：一個是悲觀策略（Pessimistic），一個是樂觀策略（Optimistic）。一般我們用悲觀策略。需要注意的是，雖然超時拋除了異常，但這段代碼的運行並沒有停止！
把OrderService構建函數處改成
public OrderService() { //超時,業務處理超過3秒就直接返回異常 _policy = Policy.Timeout<string>(3, Polly.Timeout.TimeoutStrategy.Pessimistic); }
把OrderService.cs的CreateOrder()方法讓線程睡眠10s
public string CreateOrder() { //用polly執行 return _policy.Execute(() => { //業務邏輯 todo Console.WriteLine($"{DateTime.Now},開始處理業務"); Thread.Sleep(10000); //睡眠10s Console.WriteLine("處理完成"); return "成功啦"; }); }
執行查看結果：
可以看到，在3s的時候報了polly的超時異常。
3.5Polly組合策略
上面說的都是單個策略的，其實這些策略是可以組合一起使用的，下面來演示一下。
把OrderService的構造函數修改為：
public OrderService() { //重試 Policy<string> retry = Policy<string>.Handle<Exception>() .WaitAndRetry(new TimeSpan[] { TimeSpan.FromSeconds(5), TimeSpan.FromSeconds(10), TimeSpan.FromSeconds(15) }); //降級 Policy<string> fallback = Policy<string> .Handle<Exception>() //異常故障 .Fallback(() => { //降級回調 return "降級后的值"; }); //Wrap：包裹。policyRetry在里面，policyFallback裹在外面。 //如果里面出現了故障，則把故障拋出來給外面 //_policy=Policy.Wrap(policy1, policy2, policy3, policy4, policy5);把更多一起封裝。 _policy = Policy.Wrap(fallback, retry); // fallback.Wrap<string>(retry); }
把CreateOrder()修改為
public string CreateOrder() { //用polly執行 return _policy.Execute(() => { //業務邏輯 todo Console.WriteLine($"{DateTime.Now},開始處理業務"); throw new Exception("233出錯啦"); Console.WriteLine("處理完成"); return "成功啦"; }); }
測試結果：
重試3次后，返回降級的結果。
上面的Ocelot+Polly的熔斷如果去查看Ocelot.Provider.Polly的源碼就會發現是超時和熔斷的組合實現。
需要注意的是，組合時Policy.Wrap(fallback, retry);里面的順序也要注意，測試結果是先執行后面的，再執行前面的，即前面的把后面的包在內層，內層執行完再拋出給外層處理。
上面介紹了最常用的策略，Polly也有異步的方法，把上面定義的private Policy<string> _policy; 改成 private AsyncPolicy<string> _policy; 即可。
源碼地址：https://github.com/weixiaolong325/Ocelot-Consul-Polly-Id4.Demo