Principle and example analysis of Java-based distributed service framework Dubbo

Preface

Before introducing Dubbo, let’s first understand the basic concepts:

Dubbo is a RPC framework. RPC, that is, Remote Procedure Call (remote procedure call), the opposite is local procedure call. Before the distributed architecture, the single application architecture and vertical application architecture used local Procedure call. It allows a program to call a procedure or function in another address space (usually another machine shared on a network) without the programmer having to explicitly code the details of the remote call.

Remote calls between distributed architecture applications require the RPC framework. The purpose is to make remote calls as simple as local calls.

Dubbo framework has the following components

Consumer

That is, the service consumer that calls the remote service. The consumer needs to interface programming, know Which interfaces can be called, the specific implementation requires the framework to provide a proxy class to provide a specific implementation for the interface, so that consumers only need to call which interface, and the acquisition of the specific implementation is handled by the proxy class.

Consumers also need to provide the calling method name and method parameter values.

But the proxy class does not yet know which remote method on the server needs to be called at this time. At this time, a registration center is needed to obtain a list of remote services that can be called.

Remote servers are generally deployed in clusters, so which server to call requires load balancing to select the most appropriate server to call.

At the same time, a cluster fault-tolerant mechanism is also required. Due to various reasons, remote calls may fail. At this time, a fault-tolerant mechanism is needed to retry the call to ensure the stability of the remote call.

At the same time, the communication protocol and serialization format are agreed upon with the service provider to facilitate communication and data transmission.

Provider

That is, the service provider that exposes the service. The service provider implements a specific interface internally, then exposes the interface, and then registers the service in the registration center, and the service consumer calls the service. After the provider receives the call request, it processes the request through the agreed communication protocol, and then deserializes it. After completion, it puts the request into the thread pool for processing. A thread receives the request and finds the corresponding interface implementation. Make a call and then return the result of the call.

Registry

It is the registration center for service registration and discovery. The registration center is responsible for the registration and search of service addresses, which is equivalent to the service directory. Service providers and consumers will only register with each other when starting. Center interaction, the registration center does not forward requests, and the pressure is low.

#The registry can also centralize configuration processing and dynamically notify subscribers of changes.

But why do we need a registration center? Isn’t it possible without a registration center?

In the absence of a registration center, the calling relationship between services is as follows:

When there are more and more services, service URL configuration management becomes It is very difficult. The single-point pressure on the hardware load balancer is also increasing. With the registration center, unified management of services can be achieved, soft load balancing can be achieved, and hardware costs can be reduced. The following is a schematic diagram of the registration center:

Monitor

is a monitoring center that counts the number of service calls and call time. Faced with many services, refined monitoring and convenient operation and maintenance are indispensable. , which is very important for later maintenance.

Container

is the container in which the service runs.

Architecture

The roles played by each node in the diagram have been introduced. The following is the calling relationship between each node:

Container The service container is responsible for starting, loading and running

ProviderService providerProviderWhen the service provider starts, it needs to expose itself. The remote server can discover and register the services it provides with the Registry registration center.

ConsumerWhen the service consumer starts, it registers with the Registry registration center. Subscribing to the services required

RegistryThe registration center returns the service provider list to the consumer. At the same time, if changes occur, the registration center will push real-time data to the consumer based on the long connection

When a service consumer needs to call a remote service, it will select a provider server from the provider's address list based on the load balancing algorithm to call. If the call fails, the call will be retried based on the cluster fault tolerance strategy

Service consumers and providers will count the number of calls and call times in memory, and then send the data to MonitorMonitoring Center

High Availability

# through scheduled tasks

• ##After the monitoring center goes down, it will not affect the service, but some statistical data will be lost.

• After registering the center cluster, after any one goes down, the service will be lost. Automatically switch to other registration centers

• When all registration centers are down, service providers and consumers can still communicate through the local cache that records each other's information, but if When one party makes a change, the other party cannot detect it.

• The service provider is stateless. If any server goes down, it will not affect the use. There will be other service providers to provide services

• When all service providers are down, the service consumer cannot use it normally and will reconnect indefinitely waiting for the service provider to reconnect and recover

Framework Design

The major layers are Business (business logic layer), RPC layer and Remoting layer.

Broken down further, Dubbo has a total of ten layers of architecture, and their functions are as follows:

Service, the business layer, which is the business logic layer in daily development

Config, configuration layer, external configuration interface, centered on ServiceConfig and ReferenceConfig, can directly initialize the configuration class, or can be generated through Spring parsing the configuration Configuration class

Proxy, service proxy layer, service interface transparent proxy, generate service client Stub and client Skeleton, responsible for remote Call and return results

Registry, the registration center layer, encapsulates the registration and discovery of service addresses, with the service URL as the center, and the extended interface is RegistryFactory, Registry, RegistryService

Cluster Routing and cluster fault tolerance layer encapsulates the routing, load balancing and cluster fault tolerance of multiple providers, and bridges the registration center , Responsible for selecting specific nodes to call through load balancing, processing special call requests and taking fault-tolerance measures for remote call failures

Monitor, monitoring layer, responsible for monitoring and counting the number of RPC calls and call time

Portocol, the remote call layer, mainly encapsulates the RPC remote call method

Exchange, the information exchange layer, used to encapsulate the request response model

Transport, network transport layer, abstract network transmission unified interface, Mina and Netty are available

Serialize, the serialization layer, serializes data into a binary stream for transmission, and can also deserialize and receive data

Service exposure process

First the Provider is started, and the Protocol will be required through the Proxy agent The exposed interface is encapsulated into an Invoker, which is an executable body, and then packaged through the Exporter and sent to the registration center to complete the registration. At this point, the service is exposed.

Service consumption process

Note: The blue part in the above picture is the service consumer, and the green part is the service provider.

When the service consumer starts, it will subscribe to the registration center and pull the required service provider information, and save it to the local cache. Therefore, even if all registration centers are down, the service provider and service consumer will Communication can also be carried out through local cache, but if one party has information changes, the other party cannot detect it, but it does not affect the progress of the service.

After that, the entire service consumption process starts from the Proxy in the figure, and is processed by the proxy class to achieve transparency and no perception.

ProxyFactory Generates a Proxy proxy class. Proxy holds an Invoker executable object. After calling invoke, you need to pass ClusterGet the list of all callable remote service Invoker from Directory. If certain routing rules are configured, you need to filter the Invoker list again.

The remaining Invokers will be selected for load balancing through

LoadBalance, and some data statistics need to be done through Filter, and then the data will be saved and sent to Monitor# regularly. ##. Next, use

Client

for data transmission, and generally use Netty for transmission. Transmission requires protocol construction through the

Codec

interface, and then serialization through Serialization, and finally the serialized binary stream is sent to the corresponding service provider By. <p>After receiving the binary stream, the service provider will also perform Codec protocol processing, and then deserialize (the processing here is symmetrical to the processing before transmission) and then put the request into the thread pool for processing. The thread will find the corresponding <code>Exporter according to the request, then filter it layer by layer through Filter to obtain the Invoker, and finally call the corresponding implementation class and return the result in the original way.

The above is the detailed content of Principle and example analysis of Java-based distributed service framework Dubbo. For more information, please follow other related articles on the PHP Chinese website!