Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what is the concept of .net Core Ocelot timeout, circuit breaker and current limit". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Basic concept

Timeout, circuit breaker and current restriction may sound like a long way, but they are actually used in every aspect. Many people may not understand what a circuit breaker is. In fact, a circuit breaker can be understood as a protective measure. Let's assume that under the micro-service system, the response of a downstream service is very slow, and then over time, more and more requests will accumulate, which will lead to a variety of serious consequences. It is fatal for connection pools to be heavily occupied. Not to mention the services have to call each other, you wait for me 10 seconds, I wait for you 5 seconds, not only no sense of experience, high availability will become empty talk. Let's put it another way: instead of waiting 10 seconds to return a request that fails, it is better to return the request failure immediately. As a result, requests cannot be piled up, and resources have time to be released or restored. This action is called a fuse, or a short circuit. A bit like a household circuit, once there is leakage directly tripping, the maximum protection of safety.

The concept of circuit breaker is basically there, and then integrate it to the gateway. A library called polly is needed here.

To put it briefly: polly is implemented by. Net, is a very excellent library, mainly provides retry, circuit breaker, timeout, restore and other functions, of course, today's protagonist is not it, want to study can go to the official look: https://github.com/App-vNext/Polly

Next, the integration begins. First add the nuget package:

Then register for the relevant services:

Public void ConfigureServices (IServiceCollection services) {services.AddOcelot () .AddPolly () .AddConsul () .AddConfigStoredInConsul ();}

Next, add nodes to the configuration file:

"QoSOptions": {"ExceptionsAllowedBeforeBreaking": 3, "DurationOfBreak": 10000, "TimeoutValue": 5000}

ExceptionsAllowedBeforeBreaking: threshold. A circuit breaker will be triggered when the number of consecutive exceptions of the service forwarded to the downstream reaches the threshold. Must be set up with DurationOfBreak.

DurationOfBreak: duration of fuse (in milliseconds). Must be set up with ExceptionsAllowedBeforeBreaking.

TimeoutValue: requests that are not answered within the specified time have timed out directly (in milliseconds). Can be set separately

The default timeout for tips:ocelot is 90 seconds, 90 seconds.

Then write a method that sleeps for 10 seconds:

[HttpGet] public IActionResult TimeOut () {System.Threading.Thread.Sleep (10000); return Ok ();} timeout

Now that the preparation is done, call the timeout method:

The method is to hibernate for 10 seconds, but wait about 5 seconds before actively returning 503, indicating that the timeout setting has taken effect.

Fuse break

When there is a continuous timeout of requests forwarded to a service downstream, the gateway will determine whether the threshold has been reached. If so, the circuit breaker is triggered. During this period, the requests are uniformly returned to 503, and the circuit breaker returns to normal after the circuit break time has passed. According to the above configuration: three consecutive timeouts will trigger the fuse, which lasts for 10 seconds. We still call the Timeout method three times in a row:

When the circuit breaker is not triggered, you can only wait 5 seconds for the automatic timeout, which is obviously triggered now, so the result is returned directly in 200 milliseconds. Access to other methods during the circuit breaker will also be 503:

As written at the beginning, the idea of circuit breaker and circuit short-circuit tripping is the same, even if there is only one leakage of N lines in the house, it will still trip the whole house without electricity, which ensures the program security to the greatest extent.

Current limit

Assuming that you can only hold 10,000 concurrency now, what will happen to the past 50,000 concurrency? In general, as long as it lasts a little longer, the service is basically dead. This situation will inevitably happen in the production environment, after all, the volume of business can not be measured so accurately. Therefore, in order to improve availability, the instantaneous request exceeds the maximum threshold, and all others are ignored to ensure the safe availability of the service. It is better to ask the customer to wait for the next request than if the service is dead.

Current restriction can also be achieved by configuration. The following nodes are added to the route:

"RateLimitOptions": {"ClientWhitelist": [], "EnableRateLimiting": true, "Period": "1s", "PeriodTimespan": 1, "Limit": 1}

ClientWhitelist: client whitelist, whitelist is not subject to current restrictions.

EnableRateLimiting: whether to enable current restriction.

Period: period, in s (seconds), m (minutes), h (hours), d (days), such as 1h

PeriodTimespan: try again after how many seconds.

Limit: how many requests are allowed in the cycle.

For finer control, you can also add these to the Global section:

"RateLimitOptions": {"DisableRateLimitHeaders": false, "QuotaExceededMessage": "Customize Tips!", "HttpStatusCode": 999, "ClientIdHeader": "Test"}

DisableRateLimitHeaders: whether to disable X-Rate-Limit and Retry-After headers.

QuotaExceededMessage: the message returned when the current limit is triggered.

HttpStatusCode: the http status code returned when the current limit is triggered (usually 429).

ClientIdHeader: the header used to identify the client.

How many requests are allowed within the X-Rate-Limit and Retry-After:X-Rate-Limit-- standard time mentioned in tips:DisableRateLimitHeaders, and how long can you retry after Retry-After-- triggers the current limit?

Next, modify my configuration:

"RateLimitOptions": {"ClientWhitelist": ["myclient"], "EnableRateLimiting": true, "Period": "1s", "PeriodTimespan": 10, "Limit": 1}

Modify the global configuration:

"RateLimitOptions": {"DisableRateLimitHeaders": false, "QuotaExceededMessage": "123123", "HttpStatusCode": 429, "ClientIdHeader": "Test"}

According to the configuration, I set a maximum of 1 request within 1 second. If the request is exceeded, the current limit will be triggered. Subsequent requests will return 429 and 123123 for 10 seconds. Let's try this:

Wait 10 seconds and then request again to return to normal:

White list

Clients on the whitelist will not be subject to current restrictions. If the request header is added according to the configuration, it can be identified by whitelist:

Add this request header when the request is made, no matter how you brush it, it will not be restricted.

The necessity and benefits of timeout, circuit breaker and current restriction are self-evident, but the rationality of configuration must be paid attention to in production, and full integration of business scenarios and needs is king. After all, technology is meaningless if it does not solve the problem.

This is the end of the introduction of "what is the concept of .net Core Ocelot timeout, circuit breaker and current limit". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.