Talk about my understanding of service fusing and service demotion

With the micro-service architecture being advertised in full swing, some concepts have been pushed in front of us (accept it or not), in fact most of the concepts have been there before, but rarely mentioned so often (now seem to be embarrassed to communicate without mentioning it). Think of someone summed up a word, the characteristics of micro-service architecture is: "An explanation to understand, a question is not known, a discussion on the quarrel."

In fact, the ability to summarize the foreigner has been a special worship, Kevin Kelly, Martin Fowler, Werner Vogels ..., are well-known "speakers." Just this period of time to see a little service, containers of relevant information, but also in our next generation of products in some of the practice, back to, and then to talk about the understanding of some concepts.

Today, we'll say " service fusing " and " Service demotion ". Why to say this, because I have for a long time to the two concepts of homogenization, do not know how these two words how to understand, a meaning or different. Now I look at it this way:

In the stock market, the word "fuse" is not unfamiliar, refers to when the stock index amplitude reached a point, the exchange to control the risk of the suspension of trading measures. Accordingly, the service fuses generally refers to in the software system, because some reasons causes the service to overload the phenomenon, in order to prevent the entire system fault, thus adopts one kind of protection measure, therefore many places fuses also is called the overload protection. We have seen girls travel, the large suitcase is necessary, usually walk near more than enough, but once a trip, and then big Box are in vain, how to do it. The common scenario is to take out the items in a heap, compared to, and finally some non-essential on the pain down, wait until the next box enough, and then with a use. and service demotion, that is, this is the case, the overall resources are fast enough, the pain will be some services first off, to tide over the difficulties, and then open back.

Therefore, from the above analysis, the two are in fact from some point of view there is a certain degree of similarity:

The purpose is consistent ., are from the reliability of usability, in order to prevent the whole system slow or even crash, the use of technical means; end up behaving like, for both, the ultimate user experience is that some features are temporarily unreachable or unavailable; granularity is generally service level, of course, the industry also has a lot of finer-grained practices, such as the data persistence layer (allow inquiries, not allow additions and deletions to change); high degree of autonomy required, the fuse mode is generally a service based on the automatic trigger of the policy, although the demotion can be manually intervened, but in the micro-service architecture, completely rely on people is obviously impossible, switch preset, configuration center are necessary means;

And the difference is obvious:

The triggering reason is not quite the same, the service fuse is usually a service (downstream service) fault caused, and service demotion is generally considered from the overall load; the level of management goals is not quite the same, the fuse is actually a framework-level processing, each micro-service needs (no level), while the downgrade generally requires a hierarchy of business (for example, the downgrade is usually started from the outermost service) not quite the same way to implement, this distinction will be followed separately;

Of course, this is only my personal understanding of both, the outside of the two are completely consistent also a few, or the fusing mechanism as a way to deal with the goal of a reduction of the past also said, may be "a discussion on the quarrel" is the reason it. The
concept is finished, to avoid empty talk, I then summed up the common realization of the method of understanding. For these two concepts, the so-called support framework can be a lot of hystrix as one of the best.
first of all, the most bare fuse design ideas, the following this figure should be no stranger (I just refer to the painting), concise to give a good fuse implementation of the three state machine:

Closed: Fuse off the state, the number of calls failed to accumulate, to the threshold (or a certain proportion) to start the fuse mechanism; open: The Fuse on the state, at this time the downstream calls are internally directly returned to the error, do not go to the network, but designed a clock option, The default clock reaches a certain time (this time is generally set to average fault handling time, that is mttr), to this time, into the half fuse state; Half-open: Semi-fuse state, allow quantitative service requests, if the call is successful (or a certain proportion) is considered to be restored, close the fuse, Otherwise think not good, and back to the fuse open state;

That Hystrix, as one of the most popular components in the Netflix open source framework, is how to deal with dependency isolation, to achieve the fusing mechanism, his processing is much more complicated than the implementation mechanism I mentioned above, let's take a look at the core code, I just keep the key parts of the code fragment:

Public abstract class Hystrixcommand<r> extends abstractcommand<r> implements Hystrixexecutable<r>,

    Hystrixinvokableinfo<r&gt, hystrixobservable<r> {protected abstract R run () throws Exception;
    Protected R Getfallback () {throw new Unsupportedoperationexception ("No fallback available."); } @Override Final protected observable<r> getexecutionobservable () {return Observable.defer (new Fu Nc0<observable<r>> () {@Override public observable<r> call () {T
                ry {return observable.just (run ());
                catch (Throwable ex) {return observable.error (ex);
    }
            }
        }); } @Override Final protected observable<r> getfallbackobservable () {return Observable.defer (new Fun C0<observable<r>> () {@Override Public observable<r> call ({try {return Observable.just (Getfallback ());
                catch (Throwable ex) {return observable.error (ex);
    }
            }
        });
        Public R Execute () {try {return queue ().
        catch (Exception e) {throw decomposeexception (e); }
    }

Hystrixcommand is heavy, in the entire mechanism of hystrix, involves the boundary of the place, is called through this command pattern, obviously, this command is responsible for the core of the service fuse and degraded processing, subclasses to implement two main methods:

Run method: To implement the logic of the dependency, or to implement the call between the micro-services; Getfallback method: The implementation of service degradation processing logic, only to do the fusing process is not implemented, when used, can refer to the following ways:

public class Testcommand extends hystrixcommand<string> {

	protected Testcommand (Hystrixcommandgroupkey Group) {
		Super (group);
	}

	@Override
	protected String Run () throws Exception {
		//Here you need to do the actual calling logic return
		"Hello";
	}
	
	public static void Main (string[] args) throws Interruptedexception, Executionexception, timeoutexception {
		Testcommand command = new Testcommand (HystrixCommandGroupKey.Factory.asKey ("Testgroup"));
		
		1. This is synchronous call
		Command.Execute ();
		
		2. This is an asynchronous call
		to Command.queue (). get (timeunit.milliseconds);
		
		3. Asynchronous callback
		Command.observe (). Subscribe (New action1<string> () {public
			void call (String arg0) {
				
			}
		});
	}
}

Careful students must find the command mechanism in a large number of use of observable-related APIs, this is what it is. Originally its subordinate to Rxjava, this framework does not introduce the---response type development, is also one of Netflix's works, specific everybody can refer to this series of blogs, I think the author writes very popular: http://blog.csdn.net/lzyzsd/article/ details/41833541/

Then, we will certainly ask, that before the fuse threshold settings, and so on, in which pieces do it. Let's look at another piece of core code:

Public abstract class Hystrixpropertiesstrategy {public

    hystrixcommandproperties getcommandproperties ( Hystrixcommandkey Commandkey, Hystrixcommandproperties.setter builder) {return
        new Hystrixpropertiescommanddefault (Commandkey, builder);
    }

    ......
}

This class, as a policy class, returns the associated attribute configuration and can be implemented again. And in the specific strategy, mainly includes the following several policy attribute configuration:

Circuitbreakerenabled: Whether to allow the fuse, the default allowed; Circuitbreakerrequestvolumethreshold: Whether the fuse opened the valve value, that is, the unit time exceeded the threshold number of requests, the fuse is open; Circuitbreakersleepwindowinmilliseconds: Fuse default working time, more than this time will enter the half open state, that is, allow traffic to do the attempt; Circuitbreakererrorthresholdpercentage: Wrong proportions trigger the fuse;

A lot of properties, here is not one by one, you can refer to the Hystrixcommandproperties class in the detailed definition. It is also important to note that in the design of the fuse, the isolation takes the form of a thread (which is said to have a signal, which I have not yet understood) to handle dependency concurrency and blocking extensions as follows:

As shown above, the benefits are also obvious, for each dependency has a separate controllable thread pool, of course, high concurrency, CPU switching more, have a certain impact.

A lot of long-winded, finally summed up, I think the service fuse and service demotion are different, at the same time through the simple learning of hystrix, understand its implementation mechanism, will gradually be introduced into our product development. Of course there are many concepts: service limit flow, streaming, request and dependency separation, and then have time to share one by one.