Dubbo principle Analysis-Cluster of cluster & fault tolerance

Dubbo as a distributed service governance framework, it provides cluster deployment, routing, soft load balancing and fault tolerant mechanism.

Describes the call relationships for clusters, loads, and so on during the Dubbo call.

Cluster

Disguise multiple Invoker in directory as a invoker, transparent to the upper layer, including the fault tolerant mechanism of the cluster

Cluster Interface Definition

@SPI (Failovercluster. NAME)

Public interface Cluster {

@Adaptive

<T> Invoker<t>join (directory<t> Directory) throws rpcexception;

}

Cluster can be seen as a factory class, merging invoker from directory directories into a unified invoker, creating different invoker based on cluster of different cluster strategies

Let's take a look at the default failover, and when there is a failure to retry another service's policy, the cluster implementation is simple to create a Failovercluseterinvoker object

Public class Failovercluster implements Cluster {

Public final static String NAME ="Failover";

public <T> invoker<t> join (directory<t> Directory)throws rpcexception{

return new failoverclusterinvoker<t> (directory);

}

}

Shows all the cluster scenarios provided by Dubbo

1) Availablecluster: Gets the available calls. Traverse all invokers to Judge Invoker.isavalible, as long as a direct call to true returns, regardless of the success

2) Broadcastcluster: Broadcast call. Iterate through all invokers, call each call to catch the exception without affecting the other invoker calls

3) Failbackcluster: Failed auto-recovery, failed for Invoker call, background record failed request, task timed re-send, usually used to notify

4) Failfastcluster: Fast failure, only one call is initiated, failure is immediately error-guaranteed, usually for non-idempotent operation

5) Failovercluster: failover, when a failure occurs, retries other servers, usually for read operations, but retries lead to longer delays

(1) Directory service Directory.list (invocation) lists all callable services for the method

Get the number of retries, default retry two times

(2) Select a invoker based on the loadbalance load strategy

(3) Execute Invoker.invoke (invocation) call

(4) The call returned successfully

The call failed less than the number of retries, re-executed from 3) step to start execution

Number of calls greater than or equal to retry throws call failed exception

6) Failsafecluster: Fail safe, when an exception occurs, it is ignored, usually used to write an audit log and other operations.

7) Forkingcluster: Parallel invocation, as long as a successful return, usually for the real-time requirements of higher operations, but need to waste more service resources.

8) Mergeablecluster: Group aggregation, by combination and return results, such as menu service, interface, but there are many implementations, with group distinction, now the consumer needs to call from each group to return the results, merge results returned, so that the aggregation menu items can be implemented.

This is pretty interesting, and we're analyzing how it's achieved.

(1) Get parameter values from URL according to Merge_key

(2) No merge required for null, normal call

(3) Group calls by group to save the returned interface to the collection

(4) Get Merge_key If this is the default, get the default merge policy, which is determined primarily by the return type

(5) If not, get the custom merge policy

(6) Merge policy merging call result return

9) Mockclusterwrapper: With call to mock function is other cluster packaging

Gets the Mock_key property of the URL

(1) There is no direct call to other cluster

(2) Existence value StartsWith ("Force") forced mock call

(3) The presence value is not startswith ("force") is called normally, an exception occurs in the mock call

Configuration of cluster mode

<dubbo:service cluster= "failsafe"/> Service Provider

<dubbo:reference cluster= "failsafe"/> Service consumer

Dubbo principle Analysis-Cluster of cluster & fault tolerance