Dubbo as a Lightweight RPC Framework for Solving Component Communication Issues on Apache Dubbo

Develop RPC Server and Client with Lightweight Java SDK

Mon, 01 Jan 0001 00:00:00 +0000

This example demonstrates how to use the lightweight Dubbo SDK to develop RPC Server and Client. The example uses Java Interface to define, publish, and access RPC services, with Triple protocol communication at the core. For the complete code of this example, please refer to dubbo-samples.

Based on the Triple protocol defined by Dubbo, you can easily write browser and gRPC-compatible RPC services that can run on both HTTP/1 and HTTP/2. The Dubbo Java SDK supports defining services using IDL or language-specific methods and provides a lightweight API for publishing or invoking these services.

Consumer Thread Model, Provider Thread Model

Mon, 01 Jan 0001 00:00:00 +0000

Consumer Thread Model

For Dubbo applications prior to version 2.7.5, especially some consumer applications, when faced with consuming a large number of services with a high concurrency scenario (typical in gateway scenarios), there often arises the issue of excessive thread allocation on the consumer side. For specific discussions, refer to Need a limited Threadpool in consumer side #2013.

The improved consumer thread pool model effectively addresses this issue by reusing the blocked business threads on the service side.

Asynchronous Call

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo asynchronous calls can be divided into Provider-side asynchronous calls and Consumer-side asynchronous calls.

Consumer-side asynchronous means that after initiating an RPC call, it returns immediately, allowing the calling thread to continue processing other business logic. When the response returns, a callback function is used to notify the consumer of the result.
Provider-side asynchronous execution moves blocking business from Dubbo’s internal thread pool to a user-defined thread, avoiding excessive occupation of the Dubbo thread pool, which helps prevent interference between different services.

Below is a working example diagram of consumer asynchronous calls:

Use Filter to Dynamically Intercept Requests or Responses

Mon, 01 Jan 0001 00:00:00 +0000

The Filter dynamically intercepts requests or responses to transform or utilize the information contained within them. Filters themselves do not typically create responses but provide generic functions that can be “attached” to any RPC request. Dubbo Filters are pluggable, allowing us to insert any type and number of Filters into an RPC request.

The operation of a Filter is illustrated as follows:

Some typical capabilities achievable through Filters include:

Logging request parameters and response results to log files
Adding authentication or verification logic for RPC requests
Formatting request bodies or header parameters before sending or executing requests
Compressing response results
Collecting metrics on request data, such as call time, success, and failure counts
Monitoring the number of concurrently executed requests to implement rate limiting and degradation capabilities

Usage

As shown in the figure above, the Dubbo proxy automatically loads Filter implementations and assembles them into the call chain. Filter is a standard SPI definition, and the framework automatically loads Filter implementations based on certain activation rules.

Specify timeout duration for service calls

Mon, 01 Jan 0001 00:00:00 +0000

Setting a timeout for RPC calls can improve the overall stability of the cluster, avoiding resource occupation caused by waiting indefinitely for response results (e.g., a large number of long-running unresponsive requests occupying the thread pool). In cases of no response, for example, after 5 seconds, the Dubbo framework will automatically terminate the call wait process (throwing a TimeoutException) and release the resources occupied by this call.

Usage

There are multiple ways to configure the RPC call timeout, from coarse-grained global defaults to independent configurations at the specific service or method level:

Version and Group

Mon, 01 Jan 0001 00:00:00 +0000

In Dubbo services, an interface cannot uniquely identify a service. Only the tuple interface + group + version can uniquely identify a service.

When the same interface is used for different business scenarios, usage needs, or functional modules, service groups can be used to distinguish different implementations. At the same time, these different implementations can coexist and call each other.
When the interface implementation needs upgrading while retaining the original implementation, we can distinguish them using different version numbers.

The complete source code of this article’s examples can be found at the following links:

Implicit Parameter Passing in Call Chain

Mon, 01 Jan 0001 00:00:00 +0000

Parameters can be implicitly passed between service consumers and providers using setAttachment and getAttachment on RpcContext without modifying method signatures and parameter definitions. Implicit parameter passing supports the following two directions:

From consumer to provider, i.e., additional parameters are passed via attachment when the request is initiated, outside of method parameters.
From provider to consumer, i.e., additional parameters are passed via attachment when the response is returned, outside of the response result.

The most direct way to understand implicit parameter passing is the HTTP header, which works exactly like an HTTP header. Any number of header parameters can be passed outside of the GET or POST request body. Regarding implementation principles, the implementation of attachments varies slightly for different protocols:

Cluster Fault Tolerance

Mon, 01 Jan 0001 00:00:00 +0000

Background

When cluster calls fail, Dubbo provides various fault tolerance solutions, with failover retry as the default.

Node relationships:

Here, Invoker is an abstraction of a callable Service of Provider, encapsulating the Provider address and Service interface information.
Directory represents multiple Invokers, which can be viewed as List<Invoker>, but unlike List, its values may change dynamically, such as changes pushed by the registry.
Cluster disguises multiple Invokers in Directory as a single Invoker, transparent to the upper layer, involving fault tolerance logic; if a call fails, it retries another.
Router selects a subset from multiple Invokers based on routing rules, such as read-write separation and application isolation.
LoadBalance selects a specific Invoker for the current call from multiple Invokers, involving load balancing algorithms; if a call fails, it needs to reselect.

Cluster Fault Tolerance Modes

You can extend the cluster fault tolerance strategy. See: Cluster Extension

Generic Call

Mon, 01 Jan 0001 00:00:00 +0000

Note

Generic calls are suitable for older versions of the Dubbo communication protocol. If you are using the triple protocol from version 3.3 and onwards, please use the HTTP application/json capabilities provided by the triple protocol to directly initiate service calls. Relevant examples can be found in Gateway Access Instructions.

A generic call (client generic call) refers to invoking the service when the caller does not have the service provider’s API (SDK) and can still obtain the call result. The caller can invoke the corresponding interface through a generic call by knowing the fully qualified class name and method name of the service interface.