•
Polly and IHttpClientFactory https://github.com/App-vNext/Polly/wiki/Polly-and-HttpClientFactory
•
Polly (.NET resilience and transient-fault-handling library) https://github.com/App-vNext/Polly
•
Polly: Retry with Jitter https://github.com/App-vNext/Polly/wiki/Retry-with-jitter
•
Marc Brooker. Jitter: Making Things Better With Randomness https://brooker.co.za/blog/2015/03/21/backoff.html
Implement the Circuit Breaker pattern
As noted earlier, you should handle faults that might take a variable amount of time to recover from,
as might happen when you try to connect to a remote service or resource. Handling this type of fault
can improve the stability and resiliency of an application.
In a distributed environment, calls to remote resources and services can fail due to transient faults,
such as slow network connections and timeouts, or if resources are responding slowly or are
temporarily unavailable. These faults typically correct themselves after a short time, and a robust cloud
application should be prepared to handle them by using a strategy like the “Retry pattern”.
However, there can also be situations where faults are due to unanticipated events that might take
much longer to fix. These faults can range in severity from a partial loss of connectivity to the
complete failure of a service. In these situations, it might be pointless for an application to continually
retry an operation that’s unlikely to succeed.
Instead, the application should be coded to accept that the operation has failed and handle the failure
accordingly.
Using Http retries carelessly could result in creating a Denial of Service (
DoS
) attack within your own
software. As a microservice fails or performs slowly, multiple clients might repeatedly retry failed
requests. That creates a dangerous risk of exponentially increasing traffic targeted at the failing
service.
Therefore, you need some kind of defense barrier so that excessive requests stop when it isn’t worth
to keep trying. That defense barrier is precisely the circuit breaker.
The Circuit Breaker pattern has a different purpose than the “Retry pattern”. The “Retry pattern”
enables an application to retry an operation in the expectation that the operation will eventually
succeed. The Circuit Breaker pa
ttern prevents an application from performing an operation that’s
likely to fail. An application can combine these two patterns. However, the retry logic should be
sensitive to any exception returned by the circuit breaker, and it should abandon retry attempts if the
circuit breaker indicates that a fault is not transient.