Summary of Dubbo’s overall architecture

Time:2020-4-5

Dubbo

Origin of RPC

During school, we have written many programs, such as writing a hello world service class, and then calling it locally, as shown below. The characteristics of these programs are that the service consumer and service provider are local call relationships.

Once you step into the company, especially the large Internet companies, you will find that the company’s systems are composed of thousands of services, large and small. Each service is deployed on different machines, and different teams are responsible for it. There are two problems:

(1) To build a new service, it is necessary to rely on other people’s services. Now, other people’s services are far away, how to call them?

(2) Other teams want to use our services. How should our services be published for others to call?

The brief process is as follows:

– the service consumer converts the call information into binary and transmits it to the service provider for remote call.

– the service provider executes the function, obtains the result, serializes the result into binary, and transmits it to the service consumer

Summary of Dubbo's overall architecture

Because each service is deployed on different machines, the call between services can not avoid the process of network communication. The service consumer has to write a bunch of network communication related codes (such as client stub and server stub in the figure), which is not only complex but also prone to errors.

If there’s a wayEnables us to call remote services just as we call local servicesFor example, when the service consumer executes helloworldservice.sayhello (“test”), it essentially calls the remote service.

In fact, this way isRPC(remote procedure call protocol) is widely used in various Internet companies, such as Alibaba’s HSF, Dubbo (open source), Facebook’s thrift (open source), Google grpc (open source).

Basic concepts

Dubbo is an open-source distributed service framework of Alibaba. Its biggest feature is that it is structured in a hierarchical way. Using this way, it can decouple the layers (or loosen the coupling to the maximum extent). For example, the presentation layer and the business layer need to decouple.

From the service-oriented point of view, Dubbo adopts a very simple model, either the provider provides services or the consumer consumes services, so based on this point, we can abstract the two roles of service provider and service consumer.

In addition to these two roles, it has a registry and a monitoring center. It can register and subscribe to services through the registration center; it can monitor services through the monitoring center, so that it can know which services are highly used and which are low. Increase machines for services with high utilization rate and reduce machines for services with low utilization rate, so as to achieve the purpose of reasonable allocation of resources.

Dubbo is the core framework of SOA Service governance solution. For distributed calls, the focus is on distributed governance.

Overall framework

Summary of Dubbo's overall architecture

Node role description

node Role description
Provider Exposed service provider
Consumer Service consumer calling remote service
Registry Service registration and discovery registry
Monitor Monitoring Center for statistics of service call times and call times
Container Service running container

Call relationship description

  1. The service container is responsible for starting, loading, and running the service provider.
  2. When the service provider starts, it registers its services with the registry.
  3. At startup, service consumers subscribe to the registry for services they need.
  4. The registration center returns the service provider address list to the consumer. If there is any change, the registration center will push the change data to the consumer based on the long connection.
  5. Service consumer, from the provider address list, based on the soft load balancing algorithm, selects one provider to call, and selects another to call if the call fails.
  6. Service consumers and providers,Cumulative number of calls and call time in memorySend statistical data to the monitoring center every minute.

Characteristic

Dubbo architecture has the following characteristics: connectivity, robustness, scalability, and upgrading to the future architecture.

Connectivity

  • The registration center is responsible for the registration and search of service address, which is equivalent to directory service. Service providers and consumers only interact with the registration center at startup, and the registration center does not forward requests, so the pressure is low
  • The monitoring center is responsible for counting the number and time of service calls. The statistics are first summarized in memory and then sent to the monitoring center server once a minute, and displayed in a report
  • The service provider registers the services it provides with the registry and reports the call time to the monitoring center, which does not include network overhead
  • The service consumer obtains the address list of the service provider from the registration center, calls the provider directly according to the load algorithm, and reports the call time to the monitoring center, which includes the network cost
  • The registration center, service provider and service consumer are all long-term connections, except for the monitoring center
  • The registry senses the existence of the service provider through a long connection. If the service provider goes down, the registry will immediately push the event to inform the consumer
  • The registration center and monitoring center are all down, which does not affect the running providers and consumers. The consumers cache the list of providers locally
  • Registration center and monitoring center are optional, and service consumers can directly connect with service providers

Robustness

  • The use of the monitoring center will not be affected if it is down, but part of the sampling data will be lost
  • After the database goes down, the registry can still provide service list query through cache, but cannot register new service
  • The peer cluster in the registration center will automatically switch to another one after any one is down
  • After the registry is down, the service provider and service consumer can still communicate through the local cache
  • The service provider is stateless, and any downtime will not affect the usage
  • After all the service providers are down, the service consumer application will not be able to use, and will be reconnected indefinitely waiting for the service provider to recover

Scalability

  • The registry is a peer-to-peer cluster, which can dynamically add machine deployment instances, and all clients will automatically discover new registries
  • The service provider is stateless, and the machine deployment instance can be added dynamically. The registry will push the new service provider information to the consumer

Upgrading

When the scale of service cluster is further expanded and it governance structure is further upgraded, dynamic deployment and flow calculation are needed, and the existing distributed service architecture will not bring resistance. The following is a possible future architecture:

Summary of Dubbo's overall architecture

Node role description
node Role description
Deployer Auto deploy local agent for service
Repository Warehouse is used to store service application publishing package
Scheduler Dispatching center automatically increases or decreases service providers based on access pressure
Admin Unified management console
Registry Service registration and discovery registry
Monitor Monitoring Center for statistics of service call times and call times

Dubbo core functions

Telematics:

Remote communication provides Abstract encapsulation of various NiO frameworks, including “synchronous to asynchronous” and “request response” mode of information exchange.

Cluster fault tolerance:

The service framework provides transparent remote procedure call based on interface method, including multi protocol support, soft load balancing, fault tolerance, address routing, dynamic configuration and other cluster support.

Service registration:

Service registration, based on the directory service of the registration center, enables the service consumer to dynamically find the service provider, makes the address transparent, and enables the service provider to smoothly increase or reduce the number of machines.

framework design

Integral design

Summary of Dubbo's overall architecture

Legend:

  • In the figure, the interface used by the service consumer is on the left light blue background, the interface used by the service provider is on the right light green background, and the interface used by both parties is on the central axis.
  • In the figure, it is divided intoThe ten level, each layer is unidirectional dependency, and the black arrow on the right represents the dependency between layers. Each layer can split the upper layer and be reused. Among them, the service and config layers are API, and other layers are SPI.
  • In the figure, the green block is the extension interface, and the blue block is the implementation class. In the figure, only the implementation classes used to associate each layer are shown.
  • In the figure, the blue dotted line is the initialization process, that is, the assembly chain at startup, the red solid line is the method calling process, that is, the runtime timing chain, and the purple triangle arrow is the inheritance. The subclass can be regarded as the same node of the parent class, and the text on the line is the calling method.

Instructions for all levels

  • Service level: the interface used by consumers. In the code, we directly use this
  • Config configuration layer: configure the interface externally toServiceConfig, ReferenceConfigAs the center, you can initialize the configuration class directly or generate the configuration class through spring parsing configuration
  • Proxy service proxy layer: transparent agent of service interface, generating client stub and server skeleton of the service toServiceProxyAs the center, the extension interface isProxyFactory
  • Registry registry layer: encapsulates the registration and discovery of service addresses, with the service URL as the center and the extension interface asRegistryFactory, Registry, RegistryService
  • Cluster routing layer: encapsulates the routing and load balancing of multiple providers, and bridges the registry toInvokerAs the center, the extension interface isCluster, Directory, Router, LoadBalance
  • Monitor monitoring layer: RPC call count and call time monitoring toStatisticsAs the center, the extension interface isMonitorFactory, Monitor, MonitorService
  • Protocol remote call layer: encapsulates RPC calls toInvocation, ResultAs the center, the extension interface isProtocol, Invoker, Exporter
  • Exchange information exchange layerEncapsulate request response mode, synchronous to asynchronousIn order toRequest, ResponseAs the center, the extension interface isExchanger, ExchangeChannel, ExchangeClient, ExchangeServer
  • Transport network transport layer: Abstract Mina and netty as a unified interface toMessageAs the center, the extension interface isChannel, Transporter, Client, Server, Codec
  • Serialize data serialization layer: some reusable tools, the extension interface isSerialization, ObjectInput, ObjectOutput, ThreadPool

Relationship specification

  • In RPC, protocol is the core layer, that is, as long as there is protocol + invoker + exporter, you can complete non transparent RPC calls, and then filter intercept points in the main procedure of invoker.
  • The consumer and provider in the figure are abstract concepts. They just want the viewer to know more intuitively which classes belong to the client and server. The reason why the client and server are not used is that Dubbo uses provider, consumer, registry and monitor in many scenarios to divide logical extension nodes and maintain a unified concept.
  • Cluster is a peripheral concept, so the purpose of cluster is to disguise multiple invokers as one invoker, so that other people only need to pay attention to the invoker of protocol layer. Adding cluster or removing cluster will not affect other layers, because cluster is not needed when there is only one provider.
  • The proxy layer encapsulates the transparent proxy of all interfaces. In other layers, the invoker is the center. Only when it is exposed to the user, can the invoker be converted into an interface or the interface implementation be converted into an invoker. That is to say, without RPC in the proxy layer, you can run. It’s just not so transparent, and it doesn’t look like calling remote services like calling local services.
  • The implementation of Remoting is the implementation of Dubbo protocol. If you choose RMI protocol, the whole remoting will not be used. The internal remoting is divided into transport transport layer and exchange information exchange layer. Transport layer is only responsible for one-way message transmission, which is for Mina, netty, Grizzly’s abstraction, which can also extend UDP transport, while the exchange layer encapsulates the request response semantics on top of the transport layer.
  • In fact, registry and monitor are not a single layer, but an independent node. They are only drawn together in a layer way for a global overview.

domain model

In Dubbo’s core domain model:

  • Protocol is a service domain, which is the main function portal of invoker exposure and reference. It is responsible for the lifecycle management of invoker.
  • Invoker is an entity domain,It’s the core model of Dubbo, other models rely on it or convert it to it. It represents an executable, and it can initiate the invoke call to it. It may be a local implementation, a remote implementation, or a cluster implementation.
  • Invocation is the session domain,It holds the variables in the call, such as method name, parameter, etc.

Basic design principles

  • Using microkernel + plugin mode, microkernel is only responsible for assembling plugin,Dubbo’s own functions are also realized through extension points, that is, all the function points of Dubbo can be replaced by user-defined extensions.
  • Using URL as the uniform format of configuration information, all extension points carry configuration information by passing URL.

Supplementary explanation of terms

Invoker

concept
Invoker is the entity domain, which is the core model of Dubbo. Other models rely on it or convert it to it. It represents an executable, which can be invoked by invoker. It may be a local implementation, a remote implementation, or a cluster implementation. It has a very important method result invoke (invocation invocation).

InvocationIt is a session domain, which holds important information such as method name, parameter and so on.

Two types of invokers

Invoker of local execution class

Local execution methods, such as unit tests that execute the project. For example, there is a Dubbo interface demoservice.sayhello. In this project, you can execute demoservice.sayhello by reflection through the injvmexporter.

Invoker of telecommunication class

Client side: to execute demoservice.sayhello, it encapsulates dubboinvoker for remote communication and sends the interface to be executed to the server side.
Server side: using abstractproxyinvoker to execute demoserviceimpl.sayhello, and then send the execution result back to the client

Classification by service provision and service consumption

Reference to official documents: divided into service providing invoker and service consuming invoker
Summary of Dubbo's overall architecture

In order to better explain the above figure, we combine the code examples of service consumption and provider to illustrate:

Service consumer code

public class DemoClientAction {
 
    private DemoService demoService;
 
    public void setDemoService(DemoService demoService) {
        this.demoService = demoService;
    }
 
    public void start() {
        String hello = demoService.sayHello("world" + i);
    }
}

The demoservice in the above code is the proxy of the service consumer in the figure above. The user code calls its corresponding invoker through the proxy, and the invoker realizes the real remote service call.

Service provider code

public class DemoServiceImpl implements DemoService {
 
    public String sayHello(String name) throws RemoteException {
        return "Hello " + name;
    }
}

The above class will be encapsulated as an abstractproxyinvoker instance and a new exporter instance will be generated. In this way, when the network communication layer receives a request, it will find the corresponding exporter instance and call its corresponding abstractproxyinvoker instance, thus calling the code of the service provider.

Invoker inheritance relationship

Summary of Dubbo's overall architecture

Directory

concept
In short, directory is the file directory where the invoker is loaded

Two important directories

StaticDirectory

Static directory service. Its invoker is fixed.

RegistryDirectory

Register directory service. Its invoker collection data comes from the ZK registry. He implements the notifylistener interface. The notify method in this interface is the callback of the registry, which is the source of its dynamic change according to the registry.
There is an important map variable in the whole process, methodinvokermap (it is the source of data; it is also an important operation object of notify, with the emphasis on write operations.)

Router

concept
With router, you can select one of multiple service providers to call
classification
There are mainly three implementation classes:
Conditional route: conditional route is mainly used to filter related invokers according to the routing rules configured by Dubbo management console
Mockinvokersselector: mainly based on parameters, judge whether to filter out normal (non mocked) invokers or mocks’ invokers
Scriptrouter (script route)

Example
Reference: org.apache.dubbo.rpc.cluster.router.script.scriptroutertest

LoadBalance

concept
The implementation of load balancing strategy. Similar to the router function, using the load balancing strategy (random, round robin, optimistic), select one of multiple service providers to call

ProxyFactory

At the service provider side, proxyfactory mainly packages the real implementation of services into an invoker, which implements the specific methods of service implementation objects through reflection. The default implementation is javassistproxyfactory. The code is as follows:

public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) {
    //Todo wrapper class does not properly handle class names with $
    final Wrapper wrapper = Wrapper.getWrapper(proxy.getClass().getName().indexOf('$') < 0 ? proxy.getClass() : type);
    return new AbstractProxyInvoker<T>(proxy, type, url) {
        @Override
        protected Object doInvoke(T proxy, String methodName, 
                                  Class<?>[] parameterTypes, 
                                  Object[] arguments) throws Throwable {
            return wrapper.invokeMethod(proxy, methodName, parameterTypes, arguments);
        }
    };
}

Protocol

Responsible for publishing and subscribing services.

Protocol is the service domain in Dubbo. It is only loaded when the service is enabled, stateless and thread safe. It is the main function entry for the entity domain invoker to expose and reference. It is responsible for the lifecycle management of the invoker and is the remote service call layer in Dubbo.

The protocol publishes the service according to the specified protocol. When the client calls the service according to the protocol, the protocol will give the invocation parameter passed by the client to the invoker for execution.

Protocol adds the remote communication protocol, and gets the parameter invocation according to the request of the client.

@Extension("dubbo")
public interface Protocol {

    int getDefaultPort();

    //For the service provider, the invoker of the local execution class is exposed to the outside through the protocol
    //The external can send the execution parameter invocation through the protocol, and then hand it to the local invoker for execution
    @Adaptive
    <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;

    //This is for the service consumer. The service consumer obtains the service information published by the service provider from the registry
    //The protocol used by the service provider is known through the service information, and then the service consumer still uses the protocol to construct an invoker. This invoker is the invoker of the telecommunication class.
    //During execution, the execution information needs to be sent to the service provider through the specified protocol. The service provider receives the parameter invocation and then hands it to the local invoker of the service provider for execution
    @Adaptive
    <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;

    void destroy();

}

Exporter

Responsible for the life cycle of the invoker, including an invoker object, which can revoke the service.

Exchanger

The component responsible for data exchange and network communication. Each invoker maintains a reference to the exchange client and communicates with the remote server through it.

extend

Dubbo’s interface definition

Dubbo parameters:

  • Parameter class must implement serializable serialization interface
  • The properties of the parameter must also be serializable
  • Property cannot be of class type