Shulou(Shulou.com)06/01 Report--

This article is to share with you the content of the example analysis of the principle mechanism of java developing distributed service framework Dubbo. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Preface

Before introducing Dubbo, let's understand the basic concepts:

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

Remote calls between distributed applications and applications need to be done by the RPC framework in order to make remote calls as simple as local calls.

The Dubbo framework has the following components: Consumer

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

The consumer also needs to provide the name of the calling method and the parameter values of the method.

However, the proxy class does not know which server to call the remote method at this time, and needs a registry to obtain the list of remote services that can be called through the registry.

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

At the same time, we also need a cluster fault-tolerant mechanism. For various reasons, the remote call may fail. At this time, we need a fault-tolerant mechanism to retry the call to ensure the stability of the remote call.

At the same time, agree on the communication protocol and serialization format with the service provider to facilitate communication and data transmission.

Provider

That is, the service provider of the service is exposed, the specific interface is implemented within the service provider, and then the interface is exposed, and then the service is registered with the registry, and the service consumer invokes the service. After the provider receives the invocation request, the request is processed through an agreed communication protocol, and then deserialized. After completion, the request is put into the thread pool for processing. A thread receives the request and finds the corresponding interface implementation to make the call, and then returns the result of the call.

Registry

That is, the registration center of service registration and discovery, the registry is responsible for the registration and search of the service address, which is equivalent to the service catalog. Service providers and consumers will only interact with the registry when it is restarted, and the registry does not forward requests, so there is little pressure.

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

But why do you need a registry? Is it not possible without a registration center?

In the absence of a registry, the invocation relationship between services is as follows:

When there are more and more services, the configuration management of the service URL becomes very difficult, and the single point of pressure on the hardware load balancer is also increasing. With the registry, you can achieve unified service management, achieve soft load balancing, and reduce hardware costs. The following is a schematic diagram of the registry:

Monitor

That is, the monitoring center that counts the number and time of service invocation, in the face of many services, fine monitoring and convenient operation and maintenance is indispensable, and it is very important for later maintenance.

Container

That is, the container where the service runs.

Architecture

The roles played by each node in the figure have been introduced, and the following is the invocation relationship between each node:

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

When the Provider service provider Provider service provider starts, it needs to expose itself so that the remote server can discover it, while registering its own services with the Registry registry

When the Consumer service consumer starts, subscribe to the required services from the Registry registry

The Registry registry returns a list of service providers to the consumer, and if there is a change, the registry will push real-time data to the consumer based on the persistent connection

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

Service consumers and providers count the number and time of calls in memory, and then send the data to the Monitor monitoring center through scheduled tasks.

High availability

The downtime of the monitoring center will not affect the service, but only lose some statistical data.

After the registry cluster, when any one of them goes down, it will automatically switch to another registry.

When all registries are down, service providers and consumers can still communicate through a cache in which each other's information is locally recorded, but if one party changes, the other party will not be aware of it.

The service provider is stateless, and the use of any server will not be affected after downtime, and other service providers will provide services.

When all service providers go down and the service consumers cannot use it properly, they will reconnect indefinitely and wait for the service providers to reconnect and resume.

Frame design

The large layers are Business (Business Logic layer), RPC layer and replacement layer.

Further subdivided, Dubbo has a total of 10 layers of architecture, and its functions are as follows:

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

Config, configuration layer, external configuration interface, with ServiceConfig and ReferenceConfig as the center, can initialize the configuration class directly, or generate the configuration class through Spring parsing configuration

Proxy, service proxy layer, service interface transparent proxy, client-side Stub and client-side Skeleton that generate services, responsible for remote invocation and return results

Registry, registry layer, encapsulates the registration and discovery of service addresses, takes the service URL as the center, and extends the interface to RegistryFactory,Registry,RegistryService

The Cluster routing and cluster fault tolerance layer encapsulates the routing, load balancing and cluster fault tolerance of multiple providers, and bridges the registry, which is responsible for selecting specific nodes for calling through load balancing, handling special call requests and fault tolerance measures for remote call failures.

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

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

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

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

Serialize, the serialization layer, serializes data into a binary stream for transmission, or deserializes received data

Service exposure process

First, Provider starts, and Protocal encapsulates the interface that needs to be exposed into Invoker through the Proxy agent, which is an executable, then wraps it through Exporter and sends it to the registry to complete registration, and then the service is exposed.

Service consumption process

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

When starting, the service consumer will subscribe to and pull the information of the required service provider from the registry and save it to the local cache, so that even if all registries are down, the service provider and the service consumer can communicate through the local cache. it's just that one party has information changes and the other party can't perceive it, but it doesn't affect the progress of the service.

Then the whole service consumption process starts from the Proxy in the figure and is processed by the proxy class to achieve transparency and imperceptibility.

ProxyFactory generates a Proxy proxy class, and Proxy holds an Invoker executable object. After calling invoke, you need to get the Invoker list of all callable remote services from Directory through Cluster. If some routing rules are configured, you need to filter the Invoker list again.

Select one of the remaining Invoker through LoadBalance for load balancing, and then do some data statistics through Filter, then save these data and send them to Monitor regularly.

Then use Client to do data transmission, generally use Netty for transmission.

The transport needs to be constructed through the Codec interface, then serialized through Serialization, and finally sent to the corresponding service provider.

After receiving the binary stream, the service provider will also perform Codec protocol processing, and then deserialize (the processing here is symmetrical with the processing before transmission) and put the request into the thread pool for processing. A thread will find the corresponding Exporter according to the request, then filter the Invoker layer by layer through Filter, and finally call the corresponding implementation class and return the result.

Thank you for reading! On the "java development of distributed service framework Dubbo principle mechanism example analysis" this article is shared here, I hope the above content can be of some help to you, so that you can learn more knowledge, if you think the article is good, you can share it out for more people to see it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.