Service fusing hystrix

One 、 summary

1.1 The problem of Distributed Computing

Applications in complex distributed architectures have dozens of dependencies , Every dependency will inevitably fail at some point 、

Service avalanche
When calling between multiple microservices , Suppose microservices A Call microservices B Micro service C, Microservices B Micro service C Call other microservices , That's what's called “ Fan out ”. If the call response time of a microservice on the fan out link is too long or unavailable , On the service A More and more system resources will be occupied by the call of , And then cause the system to crash , This is called “ Avalanche effect ”.

For high traffic applications , A single back-end dependency can cause all resources on all servers to saturate in seconds . Worse than failure is , These applications can also lead to increased latency between services , Backup queues , Threads and other system resources are tight , Cause more cascading failures in the whole system . These indicate the need to isolate and manage failures and delays , To the failure of a single dependency , Will not affect the entire application or system . therefore , Usually when you find that an instance under a module fails , At this time, this module will still receive traffic , Then the problematic module calls other modules , So there's a cascading failure , Or an avalanche .

1.2 Hystrix

Hystrix Is an open source library for dealing with latency and fault tolerance in distributed systems , In distributed systems , Many dependencies inevitably fail , For example, timeout. 、 Abnormal etc. .Hystrix To ensure that in the case of a dependency problem , It doesn't cause the overall service to fail , Avoid cascading faults , To improve the flexibility of distributed systems .

“ Circuit breaker ” It's a switching device , When a service unit fails , Through the fault monitoring of the circuit breaker （ Similar to a blown fuse ）, Return an expected... To the caller 、 Alternative responses that can be handled （FallBack）, Instead of waiting for a long time or throwing an exception that the caller can't handle , This ensures that the threads of the service caller will not be held for a long time 、 Occupy unnecessarily , Thus, it can avoid the fault spreading in the distributed system , Even an avalanche .

1.3 Hystrix effect

• Package request ： Use HystrixCommand The calling logic since the package team , Each command is executed in a separate thread . The author used the “ Command mode ”.
• Trip mechanism ： When the error rate of a service exceeds a certain threshold ,Hystrix It can trip automatically or manually , Stop requesting the service for a period of time .
• Resource isolation ：Hystrix A small thread pool is maintained for each dependency （ Or semaphores ）. If the thread pool is full , The request sent to the dependency will be rejected immediately , Instead of waiting in line , So as to speed up the failure determination .
• monitor ：Hystrix It can monitor the changes of operation indicators and configurations in near real time , For example, success 、 Failure 、 Overtime , And rejected requests .
• Fallback mechanism ： When the request fails 、 Overtime 、 Be rejected , Or when the circuit breaker is on , Perform fallback logic . The fallback logic is provided by the developer , For example, return a default value .
• Self repair ： After the circuit breaker is opened for a period of time , Will automatically enter “ half ” state .

1.4 Hystrix Important concepts

1.4.1 Service isolation

It refers to dividing the system into several service modules according to certain principles , Each module is relatively independent , No strong dependence . When something goes wrong , Can isolate problems and impacts within a module , And the risk of non-proliferation , It does not affect other modules , Does not affect the overall system services .

1.4.2 Service failure

The concept of fusing comes from the circuit breaker in Electronic Engineering （Circuit Breaker）. In the Internet system , When downstream services respond slowly or fail due to heavy access pressure , Upstream services to protect the overall availability of the system , You can temporarily cut off calls to downstream services . The sacrifice is local , The measure to preserve the whole is called fusing .

1.4.3 service degradation

So called demotion , It's when a service melts , The server will no longer be called , At this point the client can prepare a local one itself fallback Callback , Returns a default value . It can also be understood as telling the truth .

What conditions trigger demotion ？

• The program runs abnormally
• Overtime
• Service fusions trigger service degradation
• Thread pool / If the semaphore is full, the service will be degraded

1.4.4 Service restriction

Flow restriction can be considered as a kind of service degradation , Current limiting is to limit the input and output flow of the system , To protect the system . Generally speaking , The throughput of the system can be measured , In order to ensure the stable operation of the system , Once you reach the threshold you need to limit , We need to limit the flow and take a small amount of measures to achieve the purpose of limiting the flow . example ： Put off solving 、 Refuse to resolve , Or partial refusal to solve, etc .