The opening

This paper will analyze the underlying principles of Dubbo through illustrations and examples – explore the significance of Dubbo stratification.

Before reading, you should have some knowledge of Dubbo and be able to use it simply.

The body of the

Take a look at the Dubbo frame design from the official website. There are several other images that are not posted here. For details, please refer to the Dubbo frame design

In fact, the Dubbo website about the framework design section is very detailed, but for the inexperienced like me, it is not quick to understand in a short time.

Brief description of frame design

In the framework design drawing of Dubbo, there are ten layers from bottom to top, among which the Service and Config layers are API, and the other layers are SPI. That is, every layer except the Service and Config layers has at least one alternative.

For example, Protocol layer:

  • org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol
  • org.apache.dubbo.rpc.protocol.rmi.RmiProtocol
  • org.apache.dubbo.rpc.protocol.http.HttpProtocol

This high scalability of Dubbo is entirely based on the Dubbo SPI mechanism, which is the key and foundation of Dubbo’s source code.

Official website Demo case

For reasons of length, the specific use method and code is still to the official website Dubbo – Quick start, the following content is based on this case.

Diagram the service invocation process

The official website gives a very detailed service invocation process, but it is all from the architecture level, and the whole process will go through which class, which method, the following based on the official website pictures and pictures, combined with the case to give my own understanding.

From the code in the main function, the process looks simple

When we add the registry

Combined with XML configuration and dubo-architecture, the diagram is as follows:

Combined frame design

Service reference process

  • 4.1 the Proxy layer

This layer uses JavassistProxyFactory by default. For understanding of this layer, you can refer to the previous article to implement the most rudimentary version of RPC based on Java

  • 4.2 the Cluster layer

As can be seen from the figure, the service provider has two instances, which instance will be called by the consumer is determined by the Cluster layer, which layer will bridge the registry ZooKeeper and obtain the registration information of the two service providers, such as IP and port. Of course, this layer has other functions as well.

  • 4.3 Protocol layer

In order to realize the remote call in the figure, the essence is to transmit information through network communication. Dubbo provides multiple communication protocols for this purpose, with the default being DubboProtocol.

/ / there are cuts dubbo: / / LOCALHOST: 20880 / org. Apache. Dubbo. Demo. DemoService ? Anyhost = true&application = demo - provider&bind. IP = 192.168.31.87 & bind. The port = 20880 & interface=org.apache.dubbo.demo.DemoService &methods=sayHello,sayHello1&timestamp=1586693904645Copy the code
  • 4.4 Exchanger layer

Encapsulate the Request Response content as a Request/Response object. As anyone who has done web interface development knows, we wrap some parameters or response content into XXXRequest/YYYResponse objects.

  • 4.5 the Transport layer

This layer is the network transmission layer, based on Netty, Mina and other communication frameworks.

  • 4.6 Serialize

Since network transport is involved, the request object must be serialized.

Service exposure process

  • 5.1 Starting the Server and Listening to a specified Port

  • 5.2 Deserialize the request data

  • 5.3 Recovery The Request object

  • 5.4 Using the Protocol Layer, resolve the Request Object based on the Protocol

  • 5.5 Proxy the service implementation class of the service provider

conclusion

Combined with the Demo case on the official website, this paper simplifies the Dubbo framework design drawing by drawing, in order to understand the role of Dubbo framework layering.

From this article, we can know that a simple RPC framework is actually based on dynamic proxy + network communication,

  • Dynamic proxies are the transparent transformation of local calls into remote calls

  • Remote calls involve network communication (Transport) – socket-based

  • On socket basis, we can customize our Protocol or reuse existing protocols, such as HTTP

  • Based on the above procedure, we can encapsulate the Request/Response object (11003).

  • If you want to network, you need to Serialize/deserialize.

  • When multiple service provider instances are provided, there should be a place (registry) responsible for managing metadata information for the service provider

  • When a consumer selects one of the above service providers to invoke a service (Cluster), it selects a policy (such as polling, hash)

  • Finally, you need a Monitor that takes care of some statistical functions, such as the number of service calls