This is the 11th day of my participation in the August More Text Challenge. For details, see:August is more challenging

1. What is Dubbo?

Dubbo is a distributed service framework dedicated to providing high-performance and transparent RPC remote service invocation solutions and SOA service governance solutions. In short, Dubbo is a service framework. If there is no distributed requirement, it is not necessary to use it. Only if it is distributed, there is a need for a distributed service framework like Dubbo, and it is essentially a service invocation thing. It is a distributed framework for remote Service invocation (free from WSdl in the Web Service schema and registered on Dubbo as a server and consumer). Its core parts include:

  1. Telecommunication: Provides abstract encapsulation of a variety of long-connection-based NIO frameworks, including multiple threading models, serialization, and request-response mode of information exchange.
  2. Cluster fault tolerance: Provides transparent remote procedure calls based on interface methods, including multi-protocol support, as well as soft load balancing, failure tolerance, address routing, dynamic configuration and other cluster support.
  3. Automatic discovery: Based on the registry directory service, the service consumer can dynamically find the service provider, make the address transparent, so that the service provider can smoothly add or reduce machines.

Dubbo layered

Dubbo is a high-performance Java RPC architecture. It implements interface proxy oriented RPC invocation, service registration and discovery, load balancing, fault tolerance, extensibility and so on.

Dubbo is roughly divided into three layers, which are:

  • The business layer
  • RPC layer
  • The Remoting layer

Main application scenarios of Dubbo

Transparent remote method calls, calling remote methods just like local methods, with simple configuration and no API intrusion.

Soft load balancing and fault tolerance can replace hardware load balancers such as F5 on the Intranet, reducing costs and single points. (F5 load balancer I also come from Baidu).

Automatic service registration and discovery, no need to write the IP address of the service provider, the registry based on the interface name query service provider IP address, and can smoothly add or delete service providers.

Dubbo invokes the workflow

The Dubbo framework is designed to handle service discovery and registration and invocation in distributed systems, and to manage the invocation process.

Workflows involve providers, registrations, networks and consumers:

  • At startup, the service provider instantiates the service by reading some configuration.

  • Proxy encapsulates the service invocation interface to facilitate the invocation by the caller. When a client obtains a Proxy, it can invoke a remote service as if it were a local service.

  • During Proxy encapsulation, the Proxy calls Protocol to define the Protocol format, for example, Dubbo Protocol.

  • Encapsulate the Proxy as Invoker, which is an instance of the actual service invocation.

  • Turn Invoker into an Exporter, which simply wraps Invoker in a layer to expose itself in the registry for consumers to use.

  • Register the wrapped Exporter to the registry.

  • The service consumer sets up an instance and subscribes to the service provider’s metadata in the service registry. The metadata includes the service IP and port and the invocation mode (Proxy).

  • The consumer is called from the fetched Proxy. As you can see from the service provider wrapping process, the Proxy actually wraps the Invoker entity, so Invoker needs to be used for the invocation.

  • Before the Invoker call, the list of invokers for the service provider is obtained through Directory. In a distributed service, the same service may be distributed on different nodes.

  • Based on routing rules, you can know which nodes the service needs to obtain information from.

  • During Invoker invocation, fault tolerance is carried out through Cluster, and retry if failure policy is encountered.

  • In the call, because multiple services may be distributed to different nodes, LoadBalance is implemented through LoadBalance.

  • The Invoker call is preceded by a Filter, which is a Filter chain that handles context, flow limiting, and counting.

  • Generate the Invoker after filtering.

  • The Client is used for data transmission.

  • A Codec constructs a Protocol based on the Protocol defined by Protocol.

  • The constructed data is transmitted to the service provider through Serialization.

  • The Request has arrived at the service provider and is assigned to a ThreadPool for processing.

  • When the Server receives the request, it looks for the appropriate Exporter (including the Invoker).

  • Because Export is also wrapped in filters

  • Get the Invoker after passing the Filter

  • Finally, the service provider entity is invoked.

The above call step goes through so many processes that Proxy, Invoker, Exporter, Filter appear.

In fact, they are all different representations of the calling entity at different stages, essentially the same, using different entities in different usage scenarios.

For example, Proxy is used to facilitate the invocation by the caller. Invoker is used when invoking a concrete entity. To register with the registry and so on.