Clusters — The Beginning

Objective: To describe the following parts of the cluster, introduce the functions of Dubbo in the cluster, and introduce the interfaces related to each function under dubbo-Cluster

What is a cluster?

If distributed is dad living in Hangzhou and mom living in Shanghai, then cluster is two dads, one living in Hangzhou and one living in Shanghai. High throughput, high availability targets for distributed and clustered. In the case of distribution, each server deploys different service tasks, which may require the services on these servers to work together to complete the entire business process, with each service performing its own job. A cluster is a service that is deployed on multiple servers. Each server has the same task to reduce pressure concentration. However, problems such as load balancing and fault tolerance occur in a cluster.

Dubbo’s cluster involves the following parts:

  1. Directory: Directory can be thought of as a collection of invokers, but its value changes dynamically as services are pushed in the registry, so invokers and how they change dynamically are important content.
  2. Cluster fault tolerance: A Cluster masquerades multiple Invokers in a Directory as one Invoker, which is transparent to the upper layer. The masquerade process contains fault tolerance logic, and when the call fails, the other Invoker is retried.
  3. Routing: Dubbo routing rules, routing rules determine the target server of a Dubbo service invocation. There are two types of routing rules: conditional routing rules and scripted routing rules, and extensible.
  4. Load balancing policy: all load balancing policy algorithms supported by Dubbo.
  5. Configuration: Generates configuration information based on the url configuration rules
  6. Group aggregation: Merge returns results.
  7. Local masquerade: MORk is usually used for service degradation, and mocks are only performed when non-business exceptions (such as timeouts, network exceptions, etc.) occur

Dubbo, dubbo, dubbo, dubbo, dubbo,Dubbo,Dubbo,Dubbo,Dubbo I will use seven articles to explain the above seven parts, no matter how many, just to distinguish the corresponding content, so that readers can have a choice of reading.

There is an introduction on the official website which I think is very well written:

The Cluster work process can be divided into two phases. The first phase is during service consumer initialization when the Cluster Cluster implementation class creates a Cluster Invoker instance for the service consumer, the Merge operation shown in the figure above. The second stage is when the service consumer makes a remote invocation. Take FailoverClusterInvoker as an example. The ClusterInvoker will first call Directory’s list method to list the Invoker list (Invoker can be simply understood as a service provider). The purpose of Directory is to save Invoker, which can be easily likened to List< Invoker >. Its implementation class RegistryDirectory is a dynamic service directory that is aware of changes in the registry configuration and holds a list of Inovker that changes as the contents of the registry change. After each change, the RegistryDirectory dynamically adds and deletes Inovker and invokes the Route method of the Router to filter out invokers that do not meet the routing rules. When the FailoverClusterInvoker receives the Invoker list returned from Directory, it uses LoadBalance to select an Inovker from the Invoker list. Finally, FailoverClusterInvoker passes the parameters to the Invoker method of the Invoker instance selected by LoadBalance for a real remote call.

This article is just an overview of these sections and introduces the interfaces they cover. Hello,Dubbo, dubbo, dubbo,Dubbo,Dubbo,Dubbo,Dubbo Below we directly correspond to each part to introduce the corresponding interface source code.

directory

Dubbo: Dubbo: Dubbo: Dubbo: Dubbo: Dubbo: Dubbo: Dubbo: Dubbo: Dubbo

Source code analysis

(a) Cluster

@SPI(FailoverCluster.NAME)
public interface Cluster {

    /** * Merge the directory invokers to a virtual invoker. *@param <T>
     * @param directory
     * @return cluster invoker
     * @throws RpcException
     */
    @Adaptive
    <T> Invoker<T> join(Directory<T> directory) throws RpcException;

}
Copy the code

As you can see, FailoverCluster is an extensible interface. By default, FailoverCluster is implemented. Of course, there are other implementations of FailoverCluster, each of which represents a cluster fault tolerant approach. In this article, I just want to let the reader know the definition of the interface. It also defines a Join method, which turns the Directory object into an Invoker object for subsequent calls. The Invoker represents a cluster implementation. Vague understanding is enough, the concrete implementation will be more clear.

(2) the Configurator

public interface Configurator extends Comparable<Configurator> {

    /** * get the configurator url@return configurator url.
     */
    URL getUrl(a);

    /** * Configure the provider url@param url - old rovider url.
     * @return new provider url.
     */
    URL configure(URL url);

}
Copy the code

This interface is used to configure rules. It defines two methods: the first is to configure rules and generate urls; the second is to configure the configuration to the old URL.

(3) ConfiguratorFactory

@SPI
public interface ConfiguratorFactory {

    /** * Get the configurator instance@param url - configurator url.
     * @return configurator instance.
     */
    @Adaptive("protocol")
    Configurator getConfigurator(URL url);

}
Copy the code

This interface is the factory interface for Configurator. We define a getConfigurator method to get an instance of Configurator.

(4) Directory

public interface Directory<T> extends Node {

    /** * get service type@return service type.
     */
    Class<T> getInterface(a);

    /** * list invokers. * Get all service Invoker collections *@return invokers
     */
    List<Invoker<T>> list(Invocation invocation) throws RpcException;

}
Copy the code

This interface is the Directory interface, where Directory represents multiple Invokers and its value changes as the registry pushes service changes. A service type corresponds to a Directory. The two methods defined are also easier to understand.

(5) LoadBalance

@SPI(RandomLoadBalance.NAME)
public interface LoadBalance {

    /** * select one invoker in list. * select an appropriate call and return *@param invokers   invokers.
     * @param url        refer url
     * @param invocation invocation.
     * @return selected invoker.
     */
    @Adaptive("loadbalance")
    <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;

}
Copy the code

This interface is a load balancing interface. Dubbo also provides four load balancing strategies, which are also described in the following article.

(6) of the Merger

@SPI
public interface Merger<T> {

    /** * merge T array, return merged T object *@param items
     * @return* /
    T merge(T... items);

}
Copy the code

This interface is a grouping aggregation that merges an array of objects into a single object.

(7) the Router

public interface Router extends Comparable<Router> {

    /** * get the router url@return url
     */
    URL getUrl(a);

    /** * route. * Filter out the Invoker set that matches the rule@param invokers
     * @param url        refer url
     * @param invocation
     * @return routed invokers
     * @throws RpcException
     */
    <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;

}
Copy the code

This interface is the interface of the routing rule. It defines two methods. The first method is to obtain the URL of the routing rule, and the second method is to screen out the Invoker set matching the rule.

RouterFactory (eight)

@SPI
public interface RouterFactory {

    /** * Create router@param url
     * @return router
     */
    @Adaptive("protocol")
    Router getRouter(URL url);

}
Copy the code

This interface is the route factory interface and defines the method to get the route instance.

Afterword.

The source code for this section is github.com/CrazyHZM/in…

This article gives an overview of the cluster module in Dubbo and explains the design of the interface. Next, I will start to explain the source code of the cluster fault tolerance part of the cluster module, namely support.