Hystrix design principles
1. To prevent the failure of a single service, the depletion of the entire container system services (such as tomcat) thread resources, to avoid a large number of cascading failure in a distributed environment. A rollback logic access (usually through networks) depend on service failure occurred, refused, timeout or short-circuited by a third-party client
2. Quick failure instead of queuing (dependent on each service maintains a small pool of threads or semaphore, the thread pool is full or when the semaphore is full, denial of service immediately without waiting in line) and an elegant service degradation; when the dependent services returned to normal after the failure, rapid recovery
4. All requests external systems (or dependent service request) or encapsulated into HystrixCommand HystrixObservableCommand object, then the requests are in a separate thread. The use of isolation techniques to limit the impact of any failure of a reliance on the system. Each service maintains depend on a small thread pool (or semaphore), when the thread pool is full or semaphore full, denial of service immediately without waiting
Hystrix properties
1. Request blown: When the backend service Hystrix Command requests the number of failures exceeds a certain percentage (default 50%), the circuit breaker will switch to an open state (the Open) when all requests are not sent directly to the failure of the backend service. holding the circuit breaker open state after a period of time (5 seconds by default), semi-automatically switches to an open state (hALF-oPEN).
Then will return to judge the next request, if the request is successful, the breaker switch back to the closed state (CLOSED), or switch back to the open state (OPEN). Hystrix circuit breaker is like our family in the fuse, once the end of service is not available, the circuit breaker will directly link disconnection request, an invalid request to avoid overwhelming impact system throughput, and the ability to self-testing circuit breaker and recovery.
2. Service downgraded: Fallback equivalent downgrade for query operation, we can achieve a fallback method, when the back-end service request an exception, you can use the value fallback method returns the return value is the default setting of general fallback method. values or from the cache. inform the latter requested service is not available, do not come again.
3. rely isolation (using bulkhead mode, Docker is a kind of bulkhead mode): In Hystrix, the main resource isolation is achieved by using a thread pool is usually when we will be divided into multiple threads based on remote service calls. pool. For example, a service call two outside the two services, if you call the two services are using a thread pool, so if a service card where the resource is not being released
Behind the request again, leading to the back of the card where requests are waiting, cause you to rely on your card A service where the depletion of resources, but also led you to another B service is not available. Then if dependent on isolation, one service call AB two services, then if I have a 100 thread is available, I'll give A service distribution 50, 50 assigned to B service, so even if A service hung up,
My B services still can be used.
4. request cache: for example, a request over the request I userId = 1 data, you come back request also request the same data, then I will not continue to take the original request to link the piece, but the first time after a cache request, the first request returns the result to subsequent requests.
5. Merge request: I rely on a certain service, I want to call N times, for example, check the database when I made a request made by the N N pieces of SQL and then get a bunch of results, this time we can put more requests into one request, send a SQL query of multiple data requests, we only need to query a database to improve efficiency.
Hystrixl flowchart as follows:
Hystrix Process Description:
1: each call to create a new HystrixCommand, encapsulated in the dependent call run () method. 2: execute execute () / queue done synchronous or asynchronous invocation. 4: Analyzing fuse (circuit-breaker) is open, if open jumps to step 8, downgrade strategy, if turn off to step 5. 5: Analyzing the thread pool / queue / run over whether the semaphore, if run over in degraded step 8, otherwise continue subsequent step 6. 6: calling the run HystrixCommand a method of operational dependency logic 6a: call timed dependent logic proceeds step 8. 7: determining whether the call was successful logic 7a: successful call returns a result 7B: error call proceeds step 8. 8: calculation fuse state, all the operating states ( success, failure, rejection, timeout) reported to the fuses, used to determine statistical fuse state. 9:. getFallback () downgraded logic following four cases will trigger getFallback call: (1): RUN () method throws non HystrixBadRequestException exception. (2): run () method call times out (3): Open intercept calls fuse (4): the thread pool / queue / run over whether the semaphore 9a: Command getFallback will not implement directly thrown 9b: fallback logic downgrade call successfully returned directly 9c: downgraded logical call fails throwing an exception 10: Back to the successful implementation of the results
Ribbon be followed here in front of Hystrix integration. Plainly you want to a request fuse, must not allow customers to directly to calls that request, you are bound to be on someone else's request packed layer and intercept, to do hands and feet, for example, it is blown, so that to be on the Ribbon hands and feet. Because it is a request to initiate place.
We have just started a service request, for load balancing was intercepted once, and now we want to fuse, it must be integrated with Ribbon once, and then intercept the request to blow.
Above with reference to some of the specific configuration, except for a number of the following:
-
order-service
-
application.yml
. 1 Server: 2 Port: 8781 . 3 . 4 . 5 # specified address registry . 6 Eureka: . 7 Client: . 8 the serviceUrl: . 9 defaultzone: HTTP: // localhost: 8761 / Eureka / 10 . 11 # Name service 12 is Spring: 13 is file application: 14 name: order- -Service 15 16 ### configuration request timeout . 17 Hystrix: 18 is Command: . 19 default : 20 is Execution: 21 is Isolation: 22 is Thread: 23 is timeoutInMilliseconds: 7000 24 Ribbon: 25 ## refers to the connection time used for the case of normal network conditions, both ends of the connection time spent. 26 is ReadTimeout: 2000 27 ## refers to a connection is established from the server to read the available resources with time. 28 the ConnectTimeout: 3000 29 Feign: 30 Hystrix: 31 is Enabled: to true 32 33 is # custom load balancing policy 34 is # product- -Service: 35 # Ribbon: 36 # NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
-
Add a callback class
1 /** 2 * @author WGR 3 * @create 2019/10/19 -- 19:36 4 */ 5 @Component 6 public class ProductClientFallback implements ProductClient { 7 8 @Override 9 public String findById(int id) { 10 11 System.out.println("feign 调用product-service findbyid 异常"); 12 13 return "123"; 14 } 15 16 17 18 } 19
-
Modify comment
@FeignClient(name = "product-service", fallback = ProductClientFallback.class) public interface ProductClient { @GetMapping("/api/v1/product/find") String findById(@RequestParam(value = "id") int id); }
test:
First console will print: Feign call product-service findbyid abnormalities, indicating that the first call to this method.
-