Dubbo Architecture Design Details (go to Favorites)

Transferred from: http://shiyanjun.cn/archives/325.html

Dubbo is the Alibaba Open source distributed service framework, and its biggest feature is the layered approach to architecting, which allows for decoupling (or maximum coupling) between layers. From the point of view of the service model, Dubbo uses a very simple model, either the provider service or consumer consumption services, so it can be abstracted from the service provider (Provider) and the service consumer (Consumer) two roles. For registration Center, Protocol support, service monitoring and other content, see the following description.

Overall architecture

Dubbo's overall architecture,:

The Dubbo framework is divided into 10 tiers, and the top service layer is the interface layer that is left to the developers who actually want to use Dubbo to develop the distributed service to implement the business logic. The interface used by the service consumer is the light-blue background on the left, and the interface used by the service provider on the right green background is on the middle axis for both sides.
Below, combined with Dubbo official documentation, we understand the design points of each level in the framework hierarchy:

2. Services Interface Layer (service): This layer is related to the actual business logic, according to the service provider and the service consumer's business design corresponding interface and implementation.
4. Configuration layer (config): External configuration interface, with ServiceConfig and Referenceconfig as the center, you can configure the class directly, or you can generate the configuration class through the spring parsing configuration.
6. Service agent Layer (proxy): Service interface transparent proxy, build client stub and server side skeleton of service, take Serviceproxy as center, extension interface is proxyfactory.
8. Service registration Layer (REGISTRY): Encapsulates the registration and discovery of service addresses, centered on the service URL, and extends the interface to Registryfactory, Registry, and Registryservice. There may not be a service registry, at which point the service provider exposes the service directly.
10. Cluster Layer (Cluster): Encapsulates Routing and load balancing for multiple providers, bridging the registry, Invoker-centric, and extending interfaces to Cluster, Directory, router, and loadbalance. By combining multiple service providers into one service provider, the implementation is transparent to the consumer of the service and only needs to interact with a service provider.
12. Monitoring Layer (monitor): The number of RPC calls and call time monitoring, with statistics as the center, the expansion interface for Monitorfactory, monitor and Monitorservice.
14. Remote Call Layer (PROTOCOL): The RPC call is called, centered on invocation and result, and the extension interfaces are Protocol, invoker, and exporter. Protocol is the service domain, which is the primary function portal for invoker exposure and referencing, and it is responsible for invoker lifecycle management. Invoker is the entity domain, which is the core model of the Dubbo, the other model is disturbed, or converted to it, it represents an executable, can be launched invoke invoke, it may be a local implementation, it may be a remote implementation, or a cluster implementation.
16. Information exchange layer (Exchange): Encapsulates the request-response mode, synchronous-to-asynchronous, with request and response as the center, the expansion interface is exchanger, Exchangechannel, Exchangeclient and ExchangeServer.
18. Network Transport Layer (Transport): abstract Mina and Netty are unified interfaces, message centric, channel, Transporter, Client, server, and codec are expanded.
20. Data serialization Layer (SERIALIZE): Reusable tools that extend interfaces to serialization, ObjectInput, ObjectOutput, and ThreadPool.

As can be seen, Dubbo for service providers and service consumers, from the framework of the 10 layers of the respective need to care and expand the interface to build the entire service ecosystem (service providers and service consumers themselves is a service-centric).
According to the official provision, the description of the relationships between the above layers is as follows:

• In RPC, protocol is the core layer, that is, as long as there is protocol + Invoker + exporter can complete the non-transparent RPC call, and then in the main process of Invoker filter intercept point.
• The Consumer and provider in the graph are abstract concepts, just want to let the person who see the figure more intuitively understand which class belongs to the client and server side, the reason that does not need client and server is Dubbo in many scenes use provider, Consumer, Registry, monitor divides the logical Tuopu node, maintains the unified concept.
• and cluster is the peripheral concept, so the cluster is to disguise a plurality of invoker as a invoker, so that other people just focus on protocol layer Invoker, plus cluster or remove cluster will not affect other layers, Because there is only one provider, there is no need for cluster.
• Proxy layer encapsulates all the interfaces of the transparent agent, and in other layers are invoker-centric, only to the user when exposed to the use of proxy will invoker into the interface, or the interface implementation into Invoker, that is, remove the proxy layer RPC can run, Just not so transparent, it doesn't look like a local service to tune the remote service.
• and remoting implementation is the implementation of the Dubbo protocol, if you choose the RMI protocol, the entire remoting will not be used, remoting internal again zoned transport transport layer and exchange information exchange layer, the transport layer is responsible for one-way message transmission, is an abstraction of Mina, Netty, Grizzly, which can also extend UDP transmissions, while the exchange layer encapsulates request-response semantics on top of the transport layer.
• Registry and monitor are not really a layer, but a separate node, just for a global overview, with layers of the way to draw together.

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

Service definition
Services are around service providers and service consumers, service providers implement services, and service consumers invoke services.

Service Registration
For the service provider, it needs to publish the service, and because of the complexity of the application system, the number and type of services are expanding, for the service consumer, it is most concerned about how to obtain the services it needs, and in the face of complex application systems, the need to manage a large number of service calls. Moreover, for service providers and service consumers, they may also have both roles, namely, the need to provide services and the need for consumer services.
By unifying services, you can effectively optimize the process and management of internal applications for service Release/use. Service registries can accomplish the unification of services through specific protocols. There are several types of registries available at Dubbo:

• Multicast Registration Center
• Zookeeper Registration Center
• Redis Registration Center
• Simple Registration Center

Service Monitoring
Whether it is a service provider or a service consumer, they need to effectively monitor the actual state of the service invocation to improve the quality of service.

Remote Communication and information exchange
The remote communication needs to specify the protocol agreed by both sides of the communication, in order to ensure that both parties understand the semantics of the agreement, but also to ensure efficient and stable message transmission. Dubbo inherits the current mainstream network communication framework, mainly including the following:

• Mina
• Netty
• Grizzly

Service invocation
Take a look at the call relationship between the service provider and the service consumer based on the RPC layer, from the Dubbo website:

, the blue representation interacts with the business, and the green representation only interacts internally with the Dubbo. The invocation process described in the diagram above is as follows:

1. The service provider publishes the service to the Service registration center;
2. The service consumer subscribes to the service from the Service registration center;
3. The service consumer invokes the available services that are already registered

Next, the above abstract invocation flowchart is expanded, in detail:

Registration/deregistration Services
The registration and logoff of services is a time-series diagram of the service provider role, the registration service and the Logout service:

Service Subscription/Cancellation
In order to meet the requirements of the application system, the service consumer may need to subscribe to the service provided by a service provider, which is published by the service registry, and can invoke the service directly when it is notified that the service is available. Conversely, if a service is not needed, you can cancel the service. Take a look at the corresponding timing diagram below:

Protocol support
The 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 service quality, so choosing the right protocol is a very important thing. You can choose according to the creation of your app. For example, using the RMI protocol is generally restricted by firewalls, so for scenarios that communicate externally and internally, do not use the RMI protocol, but are based on the HTTP protocol or the Hessian protocol.

Reference supplement
Dubbo organizes various modules, modules and their relationships in a package structure:

The Dubbo code (using MAVEN management) can be used to compare the above modules. A brief description of each package:

• Dubbo-common common logic modules, including util classes and generic models.
• The Dubbo-remoting remote communication module, equivalent to the implementation of the Dubbo protocol, does not require the use of this package if RPC uses the RMI protocol.
• DUBBO-RPC Remote Call module, abstract various protocols, as well as dynamic proxy, contains only one-to call, do not care about the management of the cluster.
• The Dubbo-cluster cluster module, which disguises multiple service providers as a provider, includes: Load balancing, fault tolerance, routing, etc., the address list of a cluster can be statically configured, or it can be issued by a registry.
• Dubbo-registry Registration Center module, based on the registry address of the cluster mode, as well as the various registry of the abstraction.
• Dubbo-monitor monitoring module, count the number of service calls, call time, call chain tracking service.
• Dubbo-config configuration module, is Dubbo External API, the user through config to use Dubbo, hide Dubbo all the details.
• The Dubbo-container container module, which is a standalone container, starts with a simple main load spring, because the service typically does not require the features of the Web container such as Tomcat/jboss, and it is not necessary to use the Web container to load the service.

Reference links

• Https://github.com/alibaba/dubbo
• Http://alibaba.github.io/dubbo-doc-static/Home-zh.htm
• Http://alibaba.github.io/dubbo-doc-static/User+Guide-zh.htm
• Http://alibaba.github.io/dubbo-doc-static/Developer+Guide-zh.htm
• Http://alibaba.github.io/dubbo-doc-static/Administrator+Guide-zh.htm
• Http://alibaba.github.io/dubbo-doc-static/FAQ-zh.htm

Dubbo Architecture Design Details (go to Favorites)