Dubbo source code parsing – framework overview

Begins with introduction

Dubbo framework has been practiced by our team for almost four or five years. Its out-of-the-box features, rich expansion capabilities and excellent performance have always been favored by our friends. Take advantage of the Spring Festival idle period to carefully sort out the whole Dubbo framework system content.

1. Application architecture evolution

With the continuous development of the Application scale of the Internet, single application and vertical application architecture can no longer meet the needs, so the distributed service architecture and mobile architecture are imperative, and a reasonable governance system is needed to ensure the continuous evolution of the architecture. A general architecture evolution architecture is shown in the figure.

There are two main types: single application and vertical application. The vertical application architecture has evolved into distributed application and mobile computing architecture. Among them

• Single application architecture: The website has less traffic and fewer functional modules. All functions are deployed together and only one application is required. Such architecture requires few deployment nodes and low cost. In this case, database access framework (ORM), such as Hibernate/Mybatis/JPA framework, is the key to simplify adding, deleting and checking.
• Vertical application architecture: When the traffic volume is high, the performance improvement effect of adding a single application is less and less. The application is usually divided into several unrelated applications to improve the development and operation efficiency. At this point, WEB frameworks (MVC) for improving front-end page development efficiency become key, such as the SpringMVC framework.
• Distributed service architecture: As more and more vertical applications are deployed, more and more applications will interact with each other. Core services will be extracted as independent services to form stable service centers, enabling applications to respond to changing market demands more quickly. At this point, improved business usage and the overall distributed services (RPC) are key to the architecture, with microservices frameworks such as Spring Cloud/Dubbo/HSF being typical.
• Mobile computing architecture: When there are more and more services, capacity assessment and waste of small service resources gradually emerge. At this time, a scheduling center needs to be added to manage cluster capacity in real time based on access pressure and improve cluster utilization. In this case, the resource scheduling and governance center for improving machine utilization is key.

2. The Dubbo architecture

Dubbo framework is mainly composed of Registry, Consumer, producer Provider and Monitor.

• When the Provider is started, it registers its metadata with the registry (such as the IP and port of the instance where the service Provider is located, the configuration of the service interface, etc.).
• When a Consumer starts up, it will fully pull the metadata of the service provider from the registry into the local cache and subscribe to the relevant metadata change events. The data change events of the registry will be pushed to the subscribed consumers.
• After obtaining the service metadata, the Consumer can initiate an RPC call and asynchronously report statistics to the monitoring center before and after the RPC call.

3. The Dubbo stratification

A well-designed system or framework must have a very reasonable design of layering, system/framework layering logically divides subsystems into collections, and the formation of the relationships between the layers must follow certain rules. By layering, you can limit the dependencies between subsystems, coupling the system in a looser way and making it easier to maintain.

The grouping criteria for subsystems includes the following rule visibility. Subsystems can only depend on subsystems at the same layer and those at the next layer. Through software design layering, the following is the layering structure of Dubbo framework. Service and Config can be regarded as API layers, which are provided to API and only need to configure and complete the business code. All of the following layers, taken together, can be thought of as the SPI layer, primarily for extenders, that is, users can do customized secondary development based on the Dubbo framework to extend its functionality.

In this hierarchy diagram, you can see that each level has core interfaces to support the logic of the entire level, and the following chapters will be developed around these core interfaces.

• Service: Business layer, mainly business code implemented by developers;
• Config: Configuration layer, mainly around ServiceConfig(exposed service configuration) and ReferenConfig(referenced service configuration) two implementation classes, initialization of configuration information;
• Proxy: The service Proxy layer, whether producer or consumer, will generate a Proxy class, the whole process is transparent to the upper layer;
• Registry: the registration layer, which is responsible for service registration and discovery. When a new service joins or an old service goes offline, the Registry senses and notifies all subscribers.
• Cluster: the fault tolerance layer of the Cluster. It is mainly responsible for the fault tolerance policy (such as failure retry and rapid failure) when remote invocation fails, and the load balancing policy (such as random hash and consistent hash) when specific nodes are invoked. Routing policies for special invocation paths (e.g., a consumer will only call a producer of an IP);
• Monitor: Monitoring layer, mainly responsible for monitoring the number of calls and call time, etc.
• Protocol: The remote call layer, which encapsulates the specific process of RPC calls. Protocol is the main functional entry for Invoker exposure (publishing a service for others to call) and reference (referencing a remote service to the local). It is responsible for managing the entire life cycle of Invoker.
• Exchange: information Exchange layer, establish the request-response model, such as the synchronous request into asynchronous request;
• Transport: The network Transport layer that encapsulates network Transport as a unified interface.
• Serialize: Serialize layer. If data is to be sent over the network, it needs to be serialized to binary. The serialization layer is responsible for serialization/deserialization of the entire framework network transmission.

4.Dubbo overall call process

As you can see in the figure below, an invocation process starts from a Proxy procedure of the consumer. The Proxy holds an Invoker object and then triggers an Invoke Invoke operation. During the Invoke invocation process, a Cluster is used, which is responsible for fault tolerance of the Cluster, such as retry of failed calls. The Cluster gets the Invoker list of all remote services that can be invoked from Directory before invoking it (an interface may have multiple nodes serving it). The LoadBalance method is used to balance the load and finally select an Invoker that can be called. The Invoker passes through a chain of filters before being called, which typically handles context, limiting, counting, and so on.

Then, the Client will be used for data transmission, such as our common Netty Client. Before transmission will do some proprietary protocol structure, will use the Codec interface at this time, after completion of construction, on the packet serialization, and then transfer to the service provider, the service provider side receives the packet, also use the Codec processing agreement head and some half a pack, glue bag and so on, after processing is completed do deserialization with complete data packet.

The Request is then allocated to a Threadpool for processing. The Server handles these requests and looks up the corresponding Exporter (which holds Invoker internally), which is layered with many FilterDs in decorator mode and thus passes through a filter link of the service provider before invoking the final implementation class. Finally, the actual implementation of the concrete interface is obtained and called, and the result is returned in the original way.

5.Dubbo features

Dubbo has the following features after reasonable layered, high-performance, high-expansion design method and technology implementation:

• High-performance RPC call: provides high-performance proxy-based remote call capability. The service is interface-grained, shielding the remote low-level call details for developers.
• Service self-registration and discovery: support a variety of registry services, real-time awareness of service instances up and down;
• Traffic monitoring and scheduling during operation: built-in conditions, files and other routing policies can be implemented. By configuring different routing rules, functions such as grayscale publishing and priority in the same machine room can be realized.
• Intelligent load balancing: Multiple load balancing policies are built in.
• Highly extensible: Following the design idea of microkernel + plug-in, all core capabilities are designed as extension points, which can be easily built in and implemented by third parties;
• Visual service governance and O&M: provide rich service governance and O&M tools.

6. Summary

This article is the beginning of Dubbo entire framework source code analysis, through the introduction of Dubbo architecture layer, core components, the overall call process, so that interested partners can first have a general understanding and understanding of Dubbo framework.

reference

Blog.csdn.net/e5max/artic…