A Discussion on Circuit Breaks in the Microservices Architecture: Policy Manager Implementation
This article is part of a series on Circuit Breaks, below you can find a list on all of them.
- A Discussion on Circuit Breaks in the Microservices Architecture
- A Discussion on Circuit Breaks in the Microservices Architecture: HttpClient Implementation.
- A Discussion on Circuit Breaks in the Microservices Architecture: Policy Manager Implementation. ⬅ You are here
Previously, on A Discussion on Circuit Breaks in the Microservices Architecture, we briefly talked about what are Circuit Breakers, how they work and why it can be a good tool in the Microservices Architecture.
A summary of a Circuit Breaker State Machine is shown in the picture below for revision.
We also talked about how to implement it with a HttpClient on A Discussion on Circuit Breaks in the Microservices Architecture: HttpClient Implementation.
Thus, on this final article we talk about how to implement Circuit Breakers using a Factory to manage the policies as envelops for our methods. After we pass through the implementation we discuss the challenges and advantages faced by this design.
Diving deeper into Polly policies and methods
As said on the previous articles, Polly is composed by policy objects that enables us to execute our code within the chosen/desired policy [2]. If we abstract even further this concept of using an ‘envelope’ to execute an action we reach the idea bellow:
“A policy is the execution of a function (our code) wrapped into another function (policy).”
In many languages (such as javascript and C#) we have functions (methods) which are treated as first-class citizens [3]. This means that we can call functions by name and also store them on memory addresses (variables). Thus, enabling us to pass a function as a parameter to other function. This is a fundamental functional programming paradigm, called function composition.
And now you are saying…“Yeah…so what?”
So this is the fundamental concept for us to create a Policy Manager Implementation. Using this concept we can store the Circuit Break Policies (that in Polly case are objects) [4] and call them to execute our code using the composing function concept.
Policy Manager Implementation
The Policy Manager designed for this article and shown below works as a simplified Abstract Factory which we inject through dependency injection on our service classes (however this is only one way of doing it).
From the code above the most interesting method is the CreateDefaultCircuitBreakPolicy. This method creates a Circuit Break Policy that after two unsuccessful tries (and by unsuccessful we mean exceptions) it opens the circuit by one minute.
To make use of this factory one should call the GetCircuitBreaker method. This one receives a name that if not found on our dictionary (defined on line 19) allows our manager to create a Circuit Break Policy and return it, otherwise it returns the already created policy stored on the same dictionary.
The code below demonstrates how to use the GetCircuitBreaker method offered by the policy manager to encapsulate your function given a created Circuit Break Policy.
Basically, on line 49 we call our manager to retrieve the desired Circuit Break Policy (which gets created if it does not exists). Then, with the policy object at hand we call an execution method (ExecuteAndCaptureAsync in this example) and pass to it our function that is to be executed wrapped by the policy (composing function at work here!).
Summarizing, in this design when we try to call our manager to get a policy by its name it gives back to us the existing policy or a newly created policy. This is important because our circuit break event is determined by the policy configuration. So, we should call the same policy for the same block if we want it to function properly.
**Don’t forget to registry the PolicyManager as a Singleton Service on the Startup.cs file. Only if it is properly registered the Dependency Injection Container is able to finding our manager and inject it on our service.
**The complete source code for this article can be found on: https://github.com/ericbarroca/circuitbreak.
Implementation Benefits and Challenges
Maybe now you are feeling what this implementation brings to the table…(even more if you read about the HttpClient implementation from the previous article). But no worries, we are now going to discuss the benefits and challenges of this implementation. Starting by the benefits.
First, with a factory/manager as simple as the one assembled one can use policies for any function that they have and not only for requests that use the HttpClient. This means that you could wrap databases requests or any call to any external system using any protocol.
Second we have more control over the policies and when to execute them, we could wrap a computational intensive block of code needed prior to a request with the policy and save our users a lot of time if this Circuit Break happens to be at open state for example.
However, not everything is perfect, and this simple implementation does offer us some challenge. The developers need to keep track of policy names on their minds and maybe they will get confused some times and call the wrong policy or will end up creating a new policy for some block that already have a policy designated. Fortunately, this can be improved with a more complex implementation or using the PolicyRegistry available on the Polly framework for more rigid scenarios (which unfortunately is out of the context of this article).
Finally, we reach the end of this series on Circuit Breaks. Hope you guys enjoyed it, and hopefully, see you soon on some new topic =)
References
- [1] Martin Fowler. (6 March 2014). CircuitBreaker: https://martinfowler.com/bliki/CircuitBreaker.html
- [2] Polly. Polly: https://github.com/App-vNext/Polly
- [3] Wikipidia. Functional programming: https://en.wikipedia.org/wiki/Functional_programming
- [4] App vNext. Circuit Breaker: https://github.com/App-vNext/Polly/wiki/Circuit-Breaker
