Microservice resilience - Auto retries with Polly in .Net Core

hello everyone and welcome back to dotnet core central today I'm going to discuss about one of the very important topic when it comes to distributed programming so when we are building distributed system and micro services in most of the case what happens is one service which is a single responsibility service talks to a bunch of other services which interns are single responsibilities so they do one and only one thing and do it well now in this kind of scenario what happens is your services are distributed across the network and sometimes we might be using external services also like Google service or you know Facebook service and things of that nature and when you are dealing with services from different different sources and different network network issues are bound to happen which means the services are bound to timeout the bound to have issues and you will have HTTP exception but a question is how do we deal with this exception right because sometimes some of these exception can self heal which means if you try couple of times it might just work in other cases they might just continue to fail right so usually when we deal with this kind of system we have to build in logic for retries and things like circuit breaker in our application litora is essentially you know you continuously try two or three times until it works and then you just give up and you know handle the exception and manage it so that your application is not broken and you send back an empty result or you know some sort of half-baked result back to the client based on your requirement the circuit breaker on the other hand is if the same situation keeps on happening again and again you just don't want to call the external service anymore because you know it is down and instead of trying every five or six second you basically take a break for let's say 30 second or like you know five minutes or ten minutes until you make the calling so essentially which circuit breaker what happens is that if the web service call you try two or three times basically you to try but even after if try it doesn't work the circuit is in chili trips and then it sleeps for a certain configured amount of time so that might be thirty second or two minutes or five minutes depending on what you want to configure and after that after that timeout it essentially goes into or after the slip time it goes into a semi-open state where what it tries to do is it tries to call and see if it is still failing if it's still failing it just does a sliding it keeps the circuit basically broken at the phone in time but if it's exceeded it will you know remove remove the serviette circuit and open it so that the next call onwards will start going back to the active service to show that I'm going to have a couple of videos I think if I try to do it in one video I'm not going to do the justice so in the first video I'm just going to show how we can use retries now initially I will write service which will just throw exception that's all and then I'll go and create another service which will implement that retry manually and then I'm going to use dotnet core or dotnet NuGet package called poly which helps doing the deter eyes and circuit breakers and everything out of box so I'm going to show how easy its it is to configure poly for tree tries so that's what we will do today and in the next video I'm going to cover circuit breaker and some other features of poly so far using poly I find it extremely helpful especially when you are when you have to deal with circuit breaker retries and all these things which are essentially the plate cold and you don't want to you know rewrite everywhere and Polly does an awesome job of doing all those so let me first start writing a spirited core web api which will essentially just throw an exception that that's all it's going to do it's never going to succeed so I'm going to name it as error API solid ease and then I'm going to create a just a empty API I don't need to configure HTTP right now just maybe not local right now I'll just create a simple API okay and in the API in the value controller I'm going to go in to get and I'm just going to throw exception so essentially every time the service is called the API slash values it's just going to throw an error that's all it's going to do so I'm going to quickly run and see the response and then I'm going to build a client API which is going to in the first attempt I'm just going to create a for loop and implement the retry there and then I'm going to just configure poly and work with poly and we can see it's coming in the error block just going to continue and then I'm getting the exception which is expected so I'm going to stop this guy and I'm just going to instead of debug I'm just going to start without debugging so that running in the background and so this is up and running yeah so I'm going to go ahead and create a new project which is also going to be web bi and there I'm going to create the calling application I'm going to name it as poly dot demo and I'm going to create a simple API okay so I can see this is configured and I have a value controller here similar to the other one I'm going to go to startup now here what we can do is we can create HTTP web client or we can have is UDP client a plan Factory and I'm going to go that route because that is going to help us later in the development so I'm just going to go into startup so here what I'm going to do is I'm going to add the HTTP client so services dot and HTTP client and I'm going to have a name and I'm going to call it as a error API client and then I can set up the base URI here so I can survey the reticle to new off URI and I can keep the base address right here and I'm going to give the base address here which is I'm going to keep till here that's the base address so once I do that once I configure this what I can do is I can go back to my value controller and now since I have configured the HTTP client I can take in the constructor I can't take the HTTP client factory and then get the client that I configured with the name and use that and now I'm going to go here and then I'm going to put a try-catch block because I know it's going to fail so and here I'm going to say the HTTP client Factory dot create client and I'm going to give the same name that I've given defining this which is error API client and then I'm just going to call this client and now this is going to throw an error the get values and then when the error comes what I can do is I can I can put so it becomes little so here you can just do return so that I don't get red squiggly okay I can just okay so for simplicity I'm just going to do that what is wrong okay so they should do it this is obviously the simplest way but not not the best way so let me just do this so this is going to throw an exception and then now what we want to do here is for three times we want to catch the exception and retry and after the third time we just want to give up so this makes things really complex now so now what we have to do is create a private method and here I can have this car and what I can do is I can get rid of the okay now let's keep it here like this way so now what's going to happen is first time it'll come throw an error so it'll go here so it has to maintain some sort of count creates a you know to someone its first time it happened and just do this no count less than three count plus plus so you want to retry three times so it'll start from one two and then three so three times what we'll do is we'll part two let's leave for let's say a second let's do this let's make count this one less than equal to three so then we can do so first time we slip for a second second time for two second third time three seconds right so asleep and then again we try to get values and here we put a try-catch block and just don't do anything essentially right it's not the best way to do it but yeah this does the job and we can use this exception to you know put it into log and things like that I'm not going there right now for this specific example and so obviously for all practical purposes we can just delete it what I want to keep it here so that we can debug through it and see what the exception is coming back so we do that so this will what this will do is it will retry for three times after the first failure and then if third time it fails it will just keep up and written off and call it in a write in a real life program you might be already making like two or three services call so you might have partial data you might decide to send partial data back or you might decide not to do anything but anyway for this one let's do this so I'm just going to put a breakpoint start okay so we get the HTTP client that we created try to get the value the response comes as four four four not fun or / API slash well okay I have to say that's wrong again so we got an error 500 in terms of that's what we expected right so fail this failing because you know it's not able to utilize the data so let's start our sleeping for a second we try sleeping for two seconds this time retry and then sleeping for three seconds yeah and then we are going to give up and we're going to return now so that's what we are going to do so we Detroit three times and after three times we gave up now everywhere we call an external service we have to do this and it's a little bit painful you know in this kind of code I mean you can create a separate function and have a action or func going into it so that you can call back into your actual function this way you can reuse the code but you know why do it if poly just helps us do that so I'm going to do the same thing but this time I'm going to use poly so what I'm going to do is I'm going to go into manage NuGet package and I'm going to search for poly and I'm going to install the microsoft word extension or HTTP poly was it automatically installs the poly aids of the reason I'm going to do this because this gives an option of configuring the poly in the start up here with an extension method without us doing a lot of thing so I'm going to go ahead and I'm going to install these so let's install this so installing because I have a conflict wait something what is that so not head core to be clear then to point one point one less than two point two what do I have so I have two point one okay so I'm going to install the older version of poly so if I now let's try one level two let's try this yeah this seems to work yeah okay so now what's going to happen is now we installed the extension for Polly and now here we are going to go and add the polyfill configuration for retries so that's what we're going to do so here now what I'm going to do is I'm going to add here add transient HTTP error policy and here I'm going to say you know use the poly retry policy so I'm going to say wait and retry policy so I tend to try to sync and I'm going to do okay so what's going on here is I'm saying that try the wait and retry a sync policy and based on the number of array I'm going to give it's going to retry that many time with whatever time span I specified so I'm saying you know try it for a second to second and three seconds so once I do that now I'm going to go back to my fellow controller and I'm going to get rid of this and this so much cleaner and I'm gonna do again try the same function so now you can see the call came in it will go inside the HTTP client it got the HTTP client is going to call the gate async method and it's going to retry three times so you can see it tried three times because it waited at least like six seconds inside of this and then now it'll give up now if I go back and instead of this if I say here if I say five and if I say 15 you can see it's going to take significant amount of time in the getting method result because internally it is retrying since this is the end at transient error policy is bound with the they should EP client factory itself the entire poly implementation of retry is handled inside of the get matter itself and it does not even come outside which is which is essentially the beauty of using poly that the code looks exactly same as you would write a normal key racing method without any de try so that that's the beauty of it so I'm going to run again and we'll see that the get async will take close to sixteen seventeen seconds to finish whereas when first time we were trying it was coming back almost immediately with an error when we were doing for each and retry because we were taking the sleep outside of this call so now go here and we'll see that take place like sixteen seventeen second so you can see it took around 17 second to come back and then it'll fail at this point so that's that's the beauty of poly integration and that is what I wanted to show you today I think it's really really awesome to be able to completely delegate the work during the service configuration itself in the ioc container configuration itself and let the application be completely transparent off the retry happening and the fact that they should have a client itself encapsulate the retry instead of cat and post and all this method it's really really cool so that's it that's I had for today in my next video I am going to continue using poly with some other feature like circuit breakers and explore some of the features which are really helpful when you are building a distributed system or with lot of single responsibility services which are talking to each other thanks for watching this video if you like this video please give me a thumbs up and if you want me to do something else with respect to the video if you have any suggestion in the sound quality or the font or anything that I'm doing here please leave me a comment so that I can make it better next time thank you so much for watching

Channel: DotNet Core Central

Views: 2,298

Keywords: microservices, autoretry, polly, aspnetcore, dotnetcore, c#, .net core, .net core 2.0, .net, .net framework, micro-service, micro-services, microservice, micro-service resilience, microservice resilience, the project polly

Id: oitGaSxIRVY

Length: 28min 35sec (1715 seconds)

Published: Mon Oct 07 2019