Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Resilience Engineering with Hystrix and Spring

Resilience Engineering with Hystrix and Spring

Resilience Engineering with Hystrix and Spring

Eko Kurniawan Khannedy

February 21, 2018
Tweet

More Decks by Eko Kurniawan Khannedy

Other Decks in Technology

Transcript

  1. RESILIENCE ENGINEERING WITH HYSTRIX AND SPRING EKO KURNIAWAN KHANNEDY ▸

    Principal R&D Engineer at Blibli.com ▸ Part of R&D Team at Blibli.com ▸ [email protected] ▸ Spring Cloud Contributor
  2. RESILIENCE ENGINEERING WITH HYSTRIX AND SPRING AGENDA ▸ Intro ▸

    Hystrix ▸ How to use Hystrix ▸ Spring Cloud Hystrix ▸ Demo
  3. RESILIENCE ENGINEERING WITH HYSTRIX AND SPRING WE NEED TO WRITE

    APPLICATION THAT MANAGES ▸ Multi devices (web, mobile) ▸ Multicore architecture ▸ Cloud computing environtments
  4. RESILIENCE ENGINEERING WITH HYSTRIX AND SPRING DELIVER APPLICATION THAT ARE

    ▸ Interactive and real time ▸ Responsive ▸ Fast and consistent
  5. RESILIENCE ENGINEERING WITH HYSTRIX AND SPRING WE NEED TO BUILD

    SYSTEM THAT ▸ react to events - Event Driven ▸ react to load - Scalable ▸ react to failure - Resilient ▸ react to users - Responsive
  6. RESILIENCE ENGINEERING WITH HYSTRIX AND SPRING RESILIENT - THE HARD

    PART ▸ The system stays responsive in the face of failure. ▸ Any system that is not resilient will be unresponsive after a failure.
  7. RESILIENCE ENGINEERING WITH HYSTRIX AND SPRING WHAT IS HYSTRIX FOR?

    ▸ Give protection from and control over latency and failure from dependencies accessed (typically over the network) via third-party client libraries. ▸ Stop cascading failures in a complex distributed system. ▸ Fail fast and rapidly recover. ▸ Fallback and gracefully degrade when possible. ▸ Enable near real-time monitoring, alerting, and operational control.
  8. RESILIENCE ENGINEERING WITH HYSTRIX AND SPRING HOW DOES HYSTRIX ACCOMPLISH

    ITS GOALS? ▸ Wrapping all calls to external systems (or “dependencies”) in a HystrixCommand ▸ Timing-out calls that take longer than thresholds you define ▸ Maintaining a small thread-pool (or semaphore) for each dependency ▸ Tripping a circuit-breaker to stop all requests to a particular service for a period of time ▸ Performing fallback logic when a request fails