In this tutorial, we’ll cover the Spring Cloud Netflix Hystrix – the fault tolerance library. We’ll use the library and implement the Circuit Breaker enterprise pattern, which is describing a strategy against failure cascading at different levels in an application.
The principle is analogous to electronics: Hystrix is watching methods for failing calls to related services. If there is such a failure, it will open the circuit and forward the call to a fallback method.
The library will tolerate failures up to a threshold. Beyond that, it leaves the circuit open. Which means, it will forward all subsequent calls to the fallback method, to prevent future failures. This creates a time buffer for the related service to recover from its failing state.
2. REST Producer
To create a scenario, which demonstrates the Circuit Breaker pattern, we need a service first. We’ll name it ‘REST Producer’, because it provides data for the Hystrix-enabled ‘REST Consumer’ – which we’ll create in the next step.
The project itself is intentionally kept simple. It consists of a controller interface with one @RequestMapping annotated GET method returning simply a String, a @RestController implementing this interface and a @SpringBootApplication.
To complete this section, the only thing left to do is to configure an application-port on which we’ll be listening. We won’t use the default port 8080 because the port should remain reserved for the application described in the next step.
Furthermore, we’re defining an application name to be able to look-up our ‘REST Producer’ from the client application that we’ll introduce, later. Let’s create an application.properties with the following content:
Now we’re able to test our ‘REST Producer’ using curl:
$> curl http://localhost:9090/greeting/Cid
3. REST Consumer with Hystrix
For our demonstration scenario, we’ll be implementing a web-application, which is consuming the REST service from the previous step using RestTemplate and Hystrix. For the sake of simplicity, we’ll call it the ‘REST Consumer’.
To ensure that the application is listening on a defined port, we put the following in an application.properties file:
To see a Hystix circuit breaker in action, we’re starting our ‘REST Consumer’ and pointing our browser to http://localhost:8080/get-greeting/Cid. Under normal circumstances, the following will be shown:
To simulate a failure of our ‘REST Producer’, we’ll simply stop it, and after we finished refreshing the browser we should see a generic message, returned from the fallback method in our @Service:
4. REST Consumer with Hystrix and Feign
Now, we’re going to modify the project from the previous step to use Spring Netflix Feign as declarative REST client, instead of Spring RestTemplate.
The advantage is that we’re later able to easily refactor our Feign Client interface to use Spring Netflix Eureka for service discovery.
To start the new project, we’ll make a copy of our ‘REST Consumer’, and add the ‘REST Producer’ and spring-cloud-starter-feign as dependencies:
Now, we’re able to use our GreetingController to extend a Feign Client. We’ll implement Hystrix fallback as a static inner class annotated with @Component.
Alternatively, we could define a @Bean annotated method returning an instance of this fallback class.
The name property of the @FeignClient is mandatory. It is used, to look-up the application either by service discovery via a Eureka Client or via URL, if this property is given. For more on using Spring Netflix Eureka for service discovery have a look at this article:
Now, we are going to add Hystrix to our Spring Cloud project. In this cloud project, we have a rating service that talks to the database and gets ratings of books.
Let’s assume that our database is a resource under demand, and its response latency might vary in time or might not be available in times. We’ll handle this scenario with the HystrixCircuit-Breaker falling back to a cache for the data.
Note that the fallback method should have the same signature of a wrapped method and must reside in the same class. Now when the findRatingById fails or gets delayed more than a given threshold, Hystrix fallbacks to findCachedRatingById.
As the Hystrix capabilities are transparently injected as AOP advice, we have to adjust the order in which the advice is stacked, in case if we have other advice like Spring’s transactional advice. Here we have adjusted the Spring’s transaction AOP advice to have lower precedence than Hystrix AOP advice: