DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Software Design and Architecture
  3. Microservices
  4. How Netflix's Circuit Breaker Works

How Netflix's Circuit Breaker Works

See how Netflix's microservices-oriented circuit breaker works to prevent cascade failures and other problems.

Rafael Salerno user avatar by
Rafael Salerno
·
Sep. 07, 16 · Tutorial
Like (22)
Save
Tweet
Share
45.48K Views

Join the DZone community and get the full member experience.

Join For Free

When working with microservice remote calls, execution in different software is one of the most important and common aspects of an environment. These systems will probably be on different machines distributed over a network. But what happens when a call to one of these systems fails or doesn't respond appropriately? The system may fail as a whole, and the problem can cascade to other systems that depend on that request. 

To avoid this kind of problem, we can use a software pattern called Circuit Breaker. The idea is simple — exactly how a circuit breaker works in a house. You design a remote call for a circuit breaker object, which monitors failures. When these failures reach a certain limit, the circuit breaker trips, and when that happens, your system can disarm the service and provide a warning that the circuit breaker has been tripped.

Netflix has created a tool that implements Circuit Breaker called Hystrix — and Spring Cloud helped ease this standard into place.

The first component to this sample is eureka, though I talk about eureka in these posts. In this post, I will focus on Hystrix and Turbine. Just for information, here's the component code for setting up the eureka server.

And this component should be the first to run. When it's up, you should see this screen on http://localhost:8761:

The second component is a service with the eureka client called recommend-service.

This service has two operations — buying and recommending books. You can see it 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

Third component code:

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, which is a tool for aggregating events produced on Hystrix.

Let's imagine that we have a cluster with almost 10 read-services, each one with Hystrix. It's difficult monitoring all the circuits. That's where Turbine comes in, providing aggregation for the circuit breakers. It is available on http://localhost:8989.

In this picture, the cluster config means the service that has @HystrixCommand should have the service name registered on Eureka as READ.

After all these components start on the eureka server, http://localhost:8761, it's possible to see three instances registered.

Through the link http://localhost:8080/hystrix, we can see the Hystrix dashboard. Inform the Single Hystrix with http://localhost:8080/hystrix.stream.

This screen below is waiting for a request to build the circuit.

Fist request: http://localhost:8080/to-read.
Second request: http://localhost:8080/to-buy.

In the above picture, the circuit is closed.

To open Turbine, it's the same steps as Hystrix, but you should inform the cluster via Turbine: http://localhost:8989//turbine.stream?cluster=READ.

That will open the same screen that Hystrix, but if I have more services, they will appear in an aggregate way.

Now I switched off recommend-service. The default configuration is 20 requests to consider the circuit open. I made 20 to-buy requests, http://localhost:8080/to-buy, and here was the result:

All my project samples are on GitHub.

Circuit Breaker Pattern microservice workplace Spring Cloud Requests cluster IT Inform

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Fixing Bottlenecks in Your Microservices App Flows
  • Running Databases on Kubernetes
  • Seamless Integration of Azure Functions With SQL Server: A Developer's Perspective
  • 10 Most Popular Frameworks for Building RESTful APIs

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: