Research on "hystrix" practice and source code of distributed Service Elastic Framework (I.)

article intention

In order to cope with the exponential growth of future online (especially wireless) traffic, the level of backend services needs to be increased, the latency and fault-tolerant management of services will face greater challenges, and the company framework and open source teams choose to promote Netflix's hystrix internally. The first is to promote the coverage of service usage in various departments, and to increase the participation of the C Sharp language version (at present, at least 30% of the services are written by. net). This blog post belongs to individual Hystrix research and practical experience.

What is Hystrix?

Hystrix is the world's largest online film rental service, Netflix open source, for distributed system latency and fault-tolerant libraries. The library was written in Java and originated in the Flex project launched by the Netflix API team in 2011. The project on GitHub has been released so far, there are nearly 3,000 stars, only a few excellent open source projects to enjoy the thousand-star treatment, Hystrix success can be seen.

Why use Hystrix?

In large and medium-sized distributed systems, often the system relies on a lot (Http,hession,netty,dubbo, etc.), such as:

Under high concurrent access, the stability of these dependencies is significant for the system, but relies on a number of uncontrolled issues: such as slow network connectivity, busy resources, temporary unavailability, and offline services.

For example, the dependency I for QPS 50 is unavailable, but other dependencies are still available.

When the dependency I block occurs, the thread pool of most servers is blocked (block), which affects the stability of the entire online service. For example:

Applications with complex distributed architectures have a lot of dependencies and will inevitably fail at some point. When high concurrency dependencies fail, the current application service is at risk of being dragged down if there are no isolation measures.

For example: A system that relies on 30 SOA services is available for each service 99.99%. 99.99% of the 30-square ≈99.7%0.3% means that 100 million requests will have 3,000, 00 failures converted into time about 2 hours a month service instability. As the number of service dependencies increases, the probability of service instability becomes exponentially higher.
Solution Solution: To isolate dependencies, Hystrix is to handle the framework of dependency isolation and also to help us manage and monitor dependent services.

what can be done?

1) hystrix uses command mode Hystrixcommand to wrap dependent call logic, each command executed under a separate line approached/signal authorization

2) Provide fuse components that can be automatically run or manually called, stop the current dependency for a period of time (10 seconds), the fuse default error rate threshold is 50%, more than will automatically run.

3) Configurable dependency call timeout time, the time-out is generally set to be slightly higher than the average time of 99.5%. When the call times out, the fallback logic is returned or executed directly.

4) Provide a small thread pool (or signal) for each dependency, and if the thread pool is full The call will be immediately rejected, by default not queued. Accelerated failure determination time.

5) Dependent invocation Result: success, failure (throw exception), timeout, thread reject, short circuit. The fallback (downgrade) logic is executed when the request fails (exception, Deny, timeout, short-circuit).

　　

6) provide near real-time dependence of statistics and monitoring

7) supports asynchronous execution. Supports concurrent request caching. Automatic batch failed request.

Hystrix Design Concept

Want to know how to use, must first understand its core design concept, hystrix based on the command mode, through the UML diagram first intuitive understanding of this design pattern

As can be seen, command is the middle layer added between receiver and Invoker, and command implements the encapsulation of receiver. So how does the Hystrix application scenario correspond?

The API can be both Invoker and reciever, encapsulating these APIs by inheriting the Hystrix core class Hystrixcommand (for example, remote interface calls, database queries, and so on, which can cause delays). You can provide elastic protection for the API.

Hello World

The example of Hello World is designed to show how the low-intrusive transformation of the project puts the API under Hystrix protection!

Introducing MAVEN Dependencies

<!--dependent version-->
The following is a service with SayHello that is not protected with hystrix and its invocation
//API calls that may cause delays Public classHelloService { Public StaticString SayHello (FinalString name) {         returnString.Format ("Hello%s!", name); } }//The client calls the API directly Public classclient{ Public Static voidMain (string[] args) {System.out.println (Helloservice.sayhello ("World")); }  }    
Assuming that the string generation process is an operation that needs to be protected, we encapsulate it with hystrix.
It is important to note that while using the command pattern, we do not recommend overriding the Execute method here, but rather implementing the template method of run, where the implementation of most frameworks takes the template design pattern, and the template method is set to protected signature, the advantage is that Not only can the specific business to the business implementation, but also to add other functions, and the business implementation of the need to focus on their own business. For example, the Hystrixcommand.execute method here actually calls the Hystrixcommand.queue (). get (), and the queue method, in addition to the final call to run, also needs to provide protection for the Run method, such as timeouts and exceptions, The external cannot directly invoke the non-secure run method, which is a very worthwhile practice for us to learn.
OK, now we wrap the SayHello function by implementing the Run method, we use a private domain _name to pass the message through the constructor and get a copy of the construction parameters to maintain the invariance.
 Public classSayhellocommand extends Hystrixcommand<string> {    Privatefinal String _name;  PublicSayhellocommand (String name) {Super (HystrixCommandGroupKey.Factory.asKey ("HelloService")); _name=NewString (name);//unmutable} @OverrideprotectedString Run () {returnString.Format ("Hello%s!", _name); }}
The API is modified as follows, as a façade method it is best not to change the signature of the function (unless there is a change in the parameters and return types, because the cost of the client code churn is often huge), and also provides version sayhelloasync, which provides the asynchronous function
 Public classHelloService {//Public static string SayHello (final String name)//    {//return "Hello" + name + "!";//    }        /** * SayHello under protection of Hystrix * @param name * @return <code> "Hello" + name + "!" </code>*/     Public Staticstring SayHello (final String name) {return NewSayhellocommand (name). Execute (); }        /** * Call Async * @param name * @return*/     Public StaticFuture<string>Sayhelloasync (final String name) {return NewSayhellocommand (name). Queue (); }}
Let's take a look at how to use the fallback policy in a time-out-of-fuse scenario, which is useful in a project, such as accessing a data repository after a timeout, or directly returning a retry response
First, the Sayhellocommand constructor uses the Hystrix setter to set the time-out, which explains several of the best practices involved in setter this class
1.Setter using the builder mode, think of the constructor has a lot of parameters to set, as a construction parameter transfer will greatly reduce the readability, with the static factory method set up and can cause multiple threads concurrency inconsistency, and this bug is often very difficult to locate, So the builder model is a very good practice. The setter is passed as a constructor to the Hystrixcommand constructor, and there are many static methods in the setter, which can know the meaning of the element explicitly by means of the method name.
2.Setter is Hystrixcommand internal static class, Hystrix code a lot of use of internal static class, as the factory method of this class, or the constructor, I think this division makes the code responsibilities clearer, than the individual factory class easier to maintain.
3.Setter uses functional concatenation, and each static factory method returns a setter instance so that we can concatenate the construction process to make the code easier to read.
4.Setter is a immutable class, and each static factory method returns a new setter copy, so the setter is thread safe.
Ok,setter introduced here, here we continue to set the timeout time to 500
 Public Sayhellocommand (final  String name)    {        //builder for Hystrixcommand        Super (Setter.withgroupkey (HystrixCommandGroupKey.Factory.asKey ("Helloservicegroup"))                . Andcommandpropertiesdefaults (Hystrixcommandproperties.setter (). Withtimeoutinmilliseconds ());         New String (name);    
The Run method uses Thread.Sleep (600) to deliberately achieve the effect of a timeout, while implementing the Getfallback method, which runs immediately after the program times out fallback
    @Override    protected  String getfallback () {        return String.Format (" [FallBack] Hello%s! " , _name);    }    @Override    protectedthrows  Exception {        //TimeOut         Thread.Sleep (+);         return String.Format ("Hello%s!" , _name);    }
Final output:
[FallBack] Hello world!
Review Highlights
1.Hystrix provides resilient protection to distributed services
2.Hystrix through the command pattern encapsulation call, to achieve elastic protection, inherit Hystrixcommand and implement the Run method, the simplest package is completed.
3. The implementation of the Getfallback method can provide a fallback method for fusing or anomalies.
Best practices for setter classes in 4.HystrixCommand.
5. The template method in the framework of the practice.
Research on "hystrix" practice and source code of distributed Service Elastic Framework (I.)