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

Dubbo is an open source distributed service framework of Alibaba. Its biggest feature is that it is structured in a hierarchical manner, which can be used to decouple (or loosely couple each layer to the maximum). From the point of view of the service model, Dubbo adopts a very simple model, either the provider provides the service or the consumer consumes the service, so the roles of service provider (Provider) and service consumer (Consumer) can be abstracted from this point. For more information about registry, protocol support, service monitoring, and so on, see the description below.

Overall architecture

The overall architecture of Dubbo, as shown in the figure:

The Dubbo framework design is divided into 10 layers, and the top Service layer is the interface layer for developers who actually want to use Dubbo to develop distributed services to implement business logic. In the figure, the light blue background on the left is the interface used by the service consumer, the light green background on the right is the interface used by the service provider, and the interface on the central axis is used by both parties.

Next, in combination with the Dubbo official documentation, let's take a look at the design points at each level of the framework hierarchical architecture:

Service Interface layer (Service): this layer is related to the actual business logic, and the corresponding interfaces and implementations are designed according to the business of the service provider and service consumer.

Configuration layer (Config): the external configuration interface is centered on ServiceConfig and ReferenceConfig. You can directly new the configuration class or generate the configuration class through spring parsing configuration.

Service proxy layer (Proxy): transparent proxy of service interface, generate client-side Stub and server-side Skeleton of service, take ServiceProxy as center, and extend interface to ProxyFactory.

Service Registration layer (Registry): encapsulates the registration and discovery of service addresses, with service URL as the center and extended interfaces as RegistryFactory, Registry and RegistryService. There may be no service registry, where the service provider directly exposes the service.

Cluster layer (Cluster): encapsulates the routing and load balancing of multiple providers, bridges the registry, takes Invoker as the center, and extends the interfaces for Cluster, Directory, Router and LoadBalance. Multiple service providers are combined into a single service provider, which is transparent to the service consumer and only needs to interact with one service provider.

Monitoring layer (Monitor): monitoring the number and time of RPC calls, with Statistics as the center, and extending interfaces for MonitorFactory, Monitor and MonitorService.

Remote invocation layer (Protocol): encapsulates RPC calls, focusing on Invocation and Result, and extending interfaces for Protocol, Invoker, and Exporter. Protocol is the service domain, it is the main functional entry for Invoker exposure and reference, and it is responsible for the lifecycle management of Invoker. Invoker is a physical domain, it is the core model of Dubbo, other models rely on it, or converted to it, it represents an executable, you can make invoke calls to it, it may be a local implementation, it may be a remote implementation, or a cluster implementation.

Information exchange layer (Exchange): encapsulates the request response mode, changes synchronously to different steps, takes Request and Response as the center, and expands the interfaces for Exchanger, ExchangeChannel, ExchangeClient and ExchangeServer.

Network Transport layer (Transport): abstract mina and netty are unified interfaces, Message is the center, and the extended interfaces are Channel, Transporter, Client, Server and Codec.

Data serialization layer (Serialize): reusable tools with extension interfaces for Serialization, ObjectInput, ObjectOutput, and ThreadPool.

As can be seen from the figure above, Dubbo provides interfaces for service providers and service consumers from the 10 layers of the framework that they need to care about and extend, respectively, to build the entire service ecosystem (the service provider and service consumer themselves are service-centric).

According to the official description of the relationship between the above layers, it is as follows:

In RPC, Protocol is the core layer, that is, as long as there is Protocol + Invoker + Exporter, you can complete the opaque RPC call, and then Filter the intercept point on the main procedure of Invoker.

The Consumer and Provider in the figure are abstract concepts, just to give the viewer a more intuitive understanding of which classes belong to the client side and the server side. The reason for not using Client and Server is that Dubbo uses Provider, Consumer, Registry and Monitor to divide logical Topp nodes in many scenarios to maintain a unified concept.

Cluster is a peripheral concept, so the purpose of Cluster is to disguise multiple Invoker as an Invoker, so that others only need to pay attention to the Protocol layer Invoker. 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, while in the other layers, Invoker is the center. Only when exposed to users, Proxy is used to convert Invoker into interface or interface implementation into Invoker, that is, RPC can be Run without Proxy layer, but it is not so transparent and looks like calling remote services like local services.

Remoting implementation is the implementation of Dubbo protocol, if you choose RMI protocol, the whole Remoting will not be used. Remoting is divided into Transport transport layer and Exchange information exchange layer. Transport layer is only responsible for one-way message transmission, which is the abstraction of Mina, Netty and Grizzly. It can also expand UDP transmission, while Exchange layer encapsulates Request-Response semantics on the transport layer.

Registry and Monitor are not actually a layer, but a separate node, just for a global overview, drawn together in a layer way.

From the architecture diagram above, we can see that Dubbo, as a distributed service framework, mainly has the following core points:

Service definition

The service revolves around the service provider and the service consumer, who implements the service and the service consumer invokes the service.

Service registration

For the service provider, it needs to publish services, and because of the complexity of the application system, the number and type of services are constantly expanding; for the service consumer, it is most concerned about how to get the services it needs. in the face of complex application systems, it needs to manage a large number of service invocations. Moreover, for both service providers and service consumers, they may also play both roles, that is, both the need to provide services and the need to consume services.

Through the unified management of services, the process and management of service publishing / use by internal applications can be effectively optimized. The service registry can complete the external unification of the service through a specific protocol. Dubbo provides several types of registries to choose from:

Multicast registry

Zookeeper registry

Redis registry

Simple registry

Service monitoring

Both service providers and service consumers need to effectively monitor the actual status of service invocation so as to improve the quality of service.

Remote communication and information exchange

Remote communication needs to specify the protocol agreed by both sides of the communication, on the basis of ensuring that both sides understand the semantics of the protocol, but also to ensure efficient and stable message transmission. Dubbo inherits the current mainstream network communication framework and mainly includes the following:

Mina

Netty

Grizzly

Service invocation

Let's take a look at the invocation relationship between service providers and service consumers based on the RPC layer directly from the Dubbo official website, as shown in the figure:

In the figure above, the blue one shows interaction with the business, and the green one only interacts with the Dubbo. The invocation process described in the above figure is as follows:

The service provider publishes the service to the service registry

Service consumers subscribe to services from the service registry

The service consumer invokes the registered available services

Next, expand the above abstract call flow chart, as shown in the figure:

Register / unregister service

Registration and deregistration of services is for the role of service provider, then the timing diagram of registering and unregistering services is shown in the figure:

Service subscription / cancellation

In order to meet the needs of the application system, the service consumer may need to subscribe to the specified service published by the service provider from the service registry, and can invoke the service directly when it is notified that the service can be used. Conversely, if you no longer need a service, you can cancel it. Let's take a look at the corresponding timing diagram, as shown in the figure:

Protocol support

Dubbo supports a variety of protocols, as follows:

Dubbo protocol

Hessian protocol

HTTP protocol

RMI protocol

WebService protocol

Thrift protocol

Memcached protocol

Redis protocol

In the process of communication, different service levels generally correspond to different quality of service, so it is very important to choose the appropriate protocol. You can choose according to the creation of your application. For example, the use of RMI protocol is generally limited by firewalls, so for external and internal communication scenarios, do not use RMI protocol, but based on HTTP protocol or Hessian protocol.

Reference supplement

Dubbo organizes each module, each module and their relationships in a package structure, as shown in the figure:

You can compare it with the above modules by organizing it with Dubbo code (managed by Maven). Briefly describe the situation of each package:

Dubbo-common common logic modules, including Util classes and generic models.

Dubbo-remoting remote communication module, which is equivalent to the implementation of Dubbo protocol. If RPC uses RMI protocol, it is not necessary to use this package.

Dubbo-rpc remote invocation module abstracts various protocols and dynamic proxies only contains one-to-one calls and does not care about cluster management.

Dubbo-cluster cluster module, which disguises multiple service providers as one provider, including load balancing, fault tolerance, routing, etc. The address list of the cluster can be statically configured or issued by the registry.

Dubbo-registry registry module, the cluster mode based on the address issued by the registry, as well as the abstraction of various registries.

Dubbo-monitor monitoring module, count the number of service calls, call time, call chain tracking services.

Dubbo-config configuration module is the external API of Dubbo. Users use Dubbo through Config to hide all the details of Dubbo.

The dubbo-container container module, which is a Standalone container, starts with simple Main loading Spring, because services usually do not need the features of Web containers such as Tomcat/JBoss, and it is not necessary to use Web containers to load services.

Source: http://dubbo.io/user-guide/

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.