As for working with micro-service remote calls for executions in different software is the most common thing in an environment.
Probably these systems will be on different machines distributed over a network.
But what happens when a call to one of these systems fails or has an answer in an inappropriate time? The system may failures as a whole and the problem can be cascaded to other systems that depend on this request.
To avoid this kind of problem a software pattern called Circuit Breaker.
The idea is simple, exactly how a circuit breaker of a house.
You design a remote call for a circuit breaker object, which monitors failures.
When these failures arrive at a certain limit, the circuit breaker trips, and when he disarms can be put an action in case of failure or even a warning that the circuit breaker tripped.
The Netflix has created a tool that implements Circuit Breaker call Hystrix and Spring Cloud eased further to implement this standard.
I talk about eureka in these posts:
http://salerno-rafael.blogspot.com.br/2016/08/spring-cloud-netflix-how-works-service.html or https://dzone.com/articles/spring-cloud-netflix-how-works-service-registratio
In this post I will focus just in Hystrix and Turbine.
To configure the first component for this sample is eureka server.
And this component should be the first to run, when up this screen is available on http://localhost:8761
The second component is service with eureka client called recommend-service:
This service has two operations that provide book name, when buy another to recommend.
Available on http://localhost:8090
The third component is the Service with Hystrix/ Circuit Breaker.
This service is called read-service, in this service will be check if service dependency (recommended-service) is available, and check if circuit is Open or Close.
There are two operations: /to-read and /to-buy
This service has configuration to Hystrix Dashboard and eureka client as well.
Available on http://localhost:8080
In this picture the annotation @HystrixCommand is the configuration to circuit breaker, if something wrong happen the method reliable will be called, the same in the second @HystrixCommand, if something wrong happen the method realiableBuy will be called.
The services are called through Eureka Client, the concept is, ask for eureka server the address to recommend-service for example.
The last component is Turbine is a tool for aggregate events produced on Hystrix.
Lets imagine that we have a cluster with almost 10 read-service, each one with Hystrix, is difficult monitoring all circuits. In this moment Turbine works, to provide aggregation to circuits breakers.
Available on http://localhost:8989
In this picture the cluster config here mean the service that has @HystrixCommand, we should put the service name registered on Eureka = READ
After all this components started on Eureka server http://localhost:8761 is possible see 3 instances registered.
In this link http://localhost:8080/hystrix will be available the hyxtrix dashboard.
Inform the Single Hystrix http://localhost:8080/hystrix.stream
This screen below is waiting for request to build the circuit
Fist request: http://localhost:8080/to-read
Second request http://localhost:8080/to-buy
In this picture Circuit is closed.
To open Turbine is the same step that Hystrix, but should inform the Cluster via Turbine:http://localhost:8989//turbine.stream?cluster=READ
Will open the same screen that Hystrix, but if I have more service, will appear in aggregate way.
Now I switched off the recommend-service.
The default configuration is 20 request to consider circuit open, I did 20 time this request http://localhost:8080/to-buy