Hello,Dubbo

Hello, Dubbo. I’m meeting you for the first time. I want to make friends with you.

Dubbo, what the hell are you?

Apache Dubbo is a high-performance, lightweight, Java-based RPC open source framework.

So what is RPC?

Documents: dubbo.apache.org/zh-cn/docs/…

The document briefly and vividly compares the single application architecture, vertical application architecture, distributed service architecture and mobile computing architecture. It can be clearly seen that these four architectures are applicable to the scenarios. As business requirements become more and more complex, there will be a series of changes.

The full English name of RPC is Remote Procedure Call, also known as Remote Procedure Call. In fact, IT is a computer communication protocol. It is a protocol that requests services from Remote computer programs through the network without understanding the underlying network technology. There are many kinds of computer communication protocols, for development, many familiar is HTTP protocol, I will make a simple comparison here, HTTP protocol belongs to the application layer, while RPC spans the transport layer and application layer. In the three-way handshake protocol of HTTP itself, every time a request is sent, there will be a connection establishment process, which will bring a certain delay. In addition, THE packet size of HTTP itself is huge, while RPC can be connected on demand and broken after the call, or it can be a long link, and multiple remote procedure calls share the same link. It can be seen that RPC is more efficient than HTTP, but compared with developing simple and fast HTTP services,RPC services are more complicated.

Let’s get back to dubbo. Dubbo features connectivity, robustness, scalability, and scalability to future architectures. A detailed description of the features can also be found in the official documentation linked above. I will not elaborate on the contents of the official documents here.

Dubbo framework has been incubated by Apache Foundation and is open source on Github.

Github address: github.com/apache/incu…

Then we’ll talk about dubbo’s release strategy: the two major releases are developing in parallel, with 2.5.x being the stable version and 2.6.x being the experimental version with new features. Once the 2.6 experiment is stable, it will migrate to 2.5, so if you want to see the latest cool features of Dubbo, choose 2.6, otherwise use version 2.5. The rest of my introduction is based on version 2.6.x.

Dubbo frame design introduction

Dubbo’s official documentation is so good that I have to give it credit. Next, MY introduction to the whole framework design is based on the official document to expand, as far as possible to make more easy to understand.

Let’s take a look at the structure of the source clone:

You can see that Dubbo is broken up into multiple Maven projects (I haven’t captured all of them on the right).

Those of you who have read dubbo’s official documentation will have seen this picture

From the above figure, we can clearly see the dependency relationship between each module. In fact, the above figure only shows the key module dependency relationship, as well as some modules, such as dubbo-Bootstrap cleaning module, etc. Next, I will give a brief introduction to each module, at least to understand the functions of each module.

Let’s start with the following modules:

(1) Dubo-Registry — Registry module

The official documentation explains: clustering based on the address of the registry, and the abstraction of the various registries.

Dubbo’s registries include Multicast registries, Zookeeper registries, Redis registries, and Simple registries. This module encapsulates the implementation of the registries supported by Dubbo.

Take a look at the Registry directory structure:

  1. Dubo-registry-api: Abstracts registry registration and discovery, implements some common methods, and lets subclasses focus only on some key methods.
  2. The following four packages encapsulate each of the four registry implementations, with Dubbo-Registry-default being the Simple registry in the official documentation.
(2) Dubo-cluster — cluster module

Multiple service providers can be disguised as one provider, including load balancing, fault tolerance, routing, etc. The address list of the cluster can be statically configured or delivered by the registry.

This module encapsulates the implementation of a variety of strategies, and also supports its own extension of the cluster fault tolerance strategy, cluster disguised multiple Invoker as an Invoker, and in the camouflage process added fault tolerance logic, failed, try the next one.

Take a look at the cluster directory structure:

  1. The basic design principle of Dubbo is to use urls as a uniform format for configuration information. All extension points carry configuration information by passing urls. This package is used to generate configuration information according to uniform configuration rules.
  2. Directory package: encapsulates methods to disguise Invoker as one Invoker. Directory represents multiple Invokers. Invoker is an abstraction of Provider that calls Service. Invoker encapsulates the Provider address and Service interface information.
  3. Loadbalance package: encapsulates the implementation of load balancing. It selects a specific Invoker from multiple invokers using the load balancing algorithm. If the Invoker fails to be invoked, it needs to be selected again.
  4. Merger package: encapsulates merger returns, groups and aggregates into methods, and supports multiple types of data structures.
  5. Router packet: Encapsulates the implementation of routing rules that determine the target server for a dubbo service invocation. There are two types of routing rules: conditional routing rules and scripted routing rules, and extensible.
  6. Support package: encapsulates various invokers and clusters, including cluster fault-tolerant patterns and grouping-aggregated clusters and related Invokers.
(3) Dubo-common — common logic module

Official documentation: includes Util classes and generic models.

A utility class is a set of common methods, and a generic model is a model that has a common format throughout the project, such as urls, as mentioned above.

Take a look at common’s directory:

I won’t go into the meaning of packages in this class, but I’ll do it in a later article, because these are implementations of utility classes and packages are pretty obvious.

(4) Dubo-config — configuration module

Dubbo is the external API of Dubbo. Users use Dubbo through Config to hide all details of Dubbo.

Dubbo also provides four configuration methods, including XML configuration, attribute configuration, API configuration and annotation configuration. The configuration module implements these four configuration functions.

Take a look at the config directory:

  1. Dubo-config-api: implements API configuration and attribute configuration.
  2. Dubbo-config-spring: Implements XML configuration and annotation configuration.
Dubbo-rpc — remote call module

Abstract various protocols, as well as dynamic proxies, with one-to-one calls and no concern for cluster management.

Dubbo provides a lot of protocol implementations, but the official recommendation is to use Dubbo’s own protocol, as well as a performance test report.

Performance test Report address: dubbo.apache.org/zh-cn/docs/…

This module relies on the Dubo-Remoting module to abstract various protocols.

Take a look at RPC’s directory:

  1. Dubo-rpc-api: Abstracts dynamic proxies and various protocols to implement one-to-one calls
  2. The other packages are implementations of each protocol.
Dubo-remoting — remote communication module

As an implementation of the Dubbo protocol, this package is not required if RPC uses the RMI protocol.

This module provides a variety of client and server communication functions, such as Grizzly, Netty, Tomcat, etc. RPC protocols besides RMI use this module.

Take a look at the Remoting directory:

  1. Dubo-remoting-api: Defines the client and server interfaces.
  2. Dubo-remoting-grizzly: Client and Server based on the Grizzly implementation.
  3. Dubo-remoting-http: Client and Server based on Jetty or Tomcat implementations.
  4. Dubo-remoting-mina: Client and Server based on mina implementations.
  5. Dubo-remoting-netty: Client and Server implemented based on Netty3.
  6. Dubo-remoting-netty4: Client and Server implemented based on Netty4.
  7. Dubo-remoting-p2p: P2P server used in multicast registries.
  8. Dubo-remoting-zookeeper: encapsulates the ZooKeeper Client and communicates with the ZooKeeper Server.
(7) Dubo-Container — Container module

Spring is a Standlone container that starts with a simple Main load. There is no need to use a Web container to load services, since services usually do not require Web container features such as Tomcat/JBoss.

Because the background service does not need the functions of Web containers such as Tomcat/JBoss, it does not need to use these thick containers to load the service provider, which is a waste of resources and increases the complexity. The service container is just a simple Main method that loads some built-in containers and supports extension containers as well.

Take a look at the container directory:

  1. Dubbo-container-api: defines the Container interface and implements the Main method for loading services.
  2. The other three provide corresponding containers for the Main method to load.
(8) Dubo-monitor — monitoring module

Count the number of service calls, the call time, and the service tracked by the call chain.

This module is clear, is the monitoring of services.

Take a look at monitor’s directory:

  1. Dubbo-monitor-api: defines the monitor-related interfaces and implements the filters required for monitoring.
  2. Dubo-monitor-default: implements dubbo monitoring functions.
(9) Dubbo-bootstrap — clean module

This module has only one class, which acts as a bootstrap class for Dubbo and cleans up resources during shutdown. I will explain the specific introduction in the follow-up articles.

Dubo-demo — sample module

This module is a quick start example that includes service providers and callers, the multicast registry, and the XML configuration method, which can be described in the official documentation.

Example Address: dubbo.apache.org/zh-cn/docs/…

(11) Dubo-filter — filter module

This module provides some built-in filters.

Take a look at filter’s directory:

  1. Dubo-filter-cache: provides cache filters.
  2. Dubo-filter-validation: Provides a parameter validation filter.
Dubo-plugin — Plugin module

This module provides built-in plug-ins.

Take a look at the plugin’s directory:

  1. Dubbo-qos: provides online O&M commands.
(13) Dubo-serialization module

This module encapsulates the support implementation of various serialization frameworks.

Take a look at the serialization directory:

  1. Dubbo-serialization-api: defines the interface for serialization and data input and output.
  2. The other packages are methods that implement the corresponding serialization framework. These types of serialization frameworks are built into Dubbo, and serialization also supports extensions.
(14) Dubo-test — test module

This module encapsulates performance testing, compatibility testing and other functions for Dubbo.

Take a look at the test directory:

  1. Dubo-test-benchmark: Tests performance.
  2. Dubo-test-compatibility: compatibility test for spring3.
  3. Dubo-test-examples: examples used for tests.
  4. Dubo-test-integration: POM file required for testing

Let me talk about maven-related POM files in Dubbo

  1. Dubbo – BOM/POM.xml, using Maven BOM unified definition of dubbo version number. Dubbo-test and Dubbo-Demo all refer to dubbo-bom/pom.xml in their POM files.

  2. Dubo-dependencies -bom/ POM. XML: Uses Maven BOM to define the version numbers of third-party libraries that Dubbo depends on. Dubbo-parent introduces this BOM:

  3. All /pow.xml: defines the dubbo packaging script. When using the Dubbo library, you need to introduce the modified POM file.

  4. Dubbo -parent: Is the parent POM of Dubbo, which is imported by dubbo’s Maven modules.