Following on from the previous post dedicated to the new microservices that also work in Netflix’s filter bubbles, we will conclude this who is who with these new players in town.


What is it? Hystrix is a library that implements the CicuitBreaker pattern. Hystrix lets us manage the interactions between services in distributed systems adding latent logic and fault tolerance. Its purpose is to improve the global reliability of the system, to achieve this Hystrix isolates the access points of the microservices, therefore impeding failures in waterfall through the applications different components, providing an alternative ’’fall back’’, managing timeouts, thread pools…

How does it work? Hystrix encapsulates the requests made to “external” systems in order to manage different aspects of these, such as: timeouts, success and failure statistics, traffic lights, error management logic, spread of errors in waterfall…

So for example if a request to a service reaches a certain level (20 failures in 5 seconds by default), Hystrix will open the circuit so that more requests won’t be sent to the previously mentioned service, which will impede the spread of errors in waterfall.

What does it provide?


What is it? Ribbon is a library, designed for communication between processes in the Cloud, that carries out loading balance on the client's side. Each one of the balancers is part of a set of components that work together in order to communicate with a remote server on demand. One of Ribbon’s key points is the possibility of integrating it with Eureka in order to discover the different instances a microservice has. Although Ribbon can work by itself, in this article we focus on its integration with Eureka.

How does it work? When we need to call upon a microservice, firstly we will define our request to the previously mentioned microservice, identifying it by the name it has been registered with in Eureka. It will not be necessary to identify a certain instance of the microservice, nor the machine in which it’s found, its IP or port.

Ribbon will use the microservice’s name that we have indicated, and check Eureka’s register in order to recover the number of instances from that microservice and what machines they are in. With that information, Ribbon will run the loading balance algorithm that is set (Round Robin by default), in order to determine which instance of the microservice to call upon. Once the instance has been decided, Ribbon will encapsulate the request inside a “Hystrix Command” and carry it out. The request management will then be done by Hystrix.

What does it provide?


What is Zuul? Zuul is an “edge service” that allows dynamic routing, load balancing, monitoring, and request security. In a practical sense, Zuul is a server made up of filters, each of which is oriented to a functionality such as the previously mentioned.

How does it work? In a microservices arquitecture Zuul will normally be configured as the entry point to the ecosystem and will be in charge of routing, balancing, securing… the requests that the microservices receive.

Every request sent to Zuul will go through the filters that make it up and which, depending on the request’s characteristics, can for example reject it for security issues, register it with the purpose of monitoring, and redirect it to a specific microservice instance… according to the configured filters or those which we have implemented.

Zuul uses Ribbon by default in order to locate, through Eureka, the microservice instances to which it will redirect the requests it will run inside a “Hystrix Command”, integrating all the architecture’s components and making the most of all the advantages the springcloud ecosystem provides.

Zuul also allows us to configure routing to microservices through properties, so that a microservice doesn’t have to be necessarily called on by the name it has been registered with in Eureka. However, this routing functionality doesn’t use the other elements of the architecture like Ribbon and Hystrix.

What does it provide?

There are other key elements of this new type of architectures left such as logs management, deployment management, monitoring, containers… but we will leave those for another time.

In conclusion

As we have seen, all of these components are designed to integrate with each other, making up a new high availability, fault tolerant architecture… which has been tested in a highly complex and demanding environment such as the one Netflix faces every day, with thousands of millions of requests. An architecture that fully integrates Cloud Computing’s concepts and philosophy.

An architecture that Pivotal has decided to include in Spring. Without a doubt this has favored it, allowing it be become a reference point, at the cutting edge of the new technology wave cloud brings. So don’t lose sight of it, because we are going to be hearing a lot about microservices and Spring Cloud.


Tell us what you think.


Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.