Traffic Control on Apache Dubbo

Sample Application Architecture

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

This task demonstrates the traffic control capabilities of Dubbo based on a simple online shopping mall microservice system.

Note

All capabilities demonstrated in this example are implemented based on Dubbo Routing Rules. For detailed information on how they work, please check the specifics.

The architecture diagram of the online mall is as follows:

The system consists of 5 microservice applications:

Frontend Shopping Mall Home, which serves as the web interface interacting with users, calling User, Detail, Order, etc., to provide user login, product display, and order management services.
User Service, responsible for user data management and identity verification.
Order Service, providing order creation and query services, relying on the Detail service to validate product stock information.
Detail Service, displaying detailed product information and calling the Comment service to show user comments on products.
Comment Service, managing user comments on products.

Deploying the Mall System

For convenience, we will deploy the entire system on a Kubernetes cluster. Execute the following command to complete the mall project deployment. The source code example is in dubbo-samples/task.

Dynamically Adjust Service Timeout

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

Dubbo provides the ability to dynamically adjust service timeout, allowing adjustments without restarting the application, which is very effective for temporarily resolving issues of invocation failure due to unstable upstream and downstream service dependencies.

Before You Start

Deploy the Shop mall project
Deploy and open Dubbo Admin

Task Details

The mall project provides user information management services through org.apache.dubbo.samples.UserService. Access http://localhost:8080/, enter any username and password, and click Login to log into the system.

Improve Service Call Success Rate Through Retry

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

Retrying after an initial service call failure can effectively increase the overall call success rate. However, it is important to note that retries may lead to increased response times and higher system load. Additionally, retries are generally suitable for read-only services or write services that guarantee idempotency.

Before You Begin

Deploy the Shop Mall Project
Deploy and open Dubbo Admin

Task Details

After successfully logging into the mall project, the mall will automatically display the details of the currently logged-in user on the homepage.

Dynamically Enable Access Log to Track Service Calls

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

The access log can effectively record all service request information processed by a machine over a period of time, including request reception time, remote IP, request parameters, response results, etc. Dynamically enabling the access log at runtime is very helpful for problem troubleshooting.

Before You Start

Deploy the Shop Mall Project
Deploy and open Dubbo Admin

Task Details

All user services of the mall are provided by the UserService of the User application. Through this task, we enable the access log for one or more machines of the User application to observe the overall access situation of user services.

Same Data Center/Region Priority

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

To ensure the overall high availability of services, we often adopt a strategy of deploying services across multiple availability zones (data centers). Through this redundancy/disaster recovery deployment model, we can still guarantee the overall availability of services when a region experiences a failure.

When applications are deployed across multiple different data centers/regions, cross-region calls may occur between applications, which can increase response times and impact user experience. Same data center/region priority means that when an application calls a service, it prefers to call service providers in the same data center/region, avoiding network delays caused by cross-region calls and thereby reducing response times.

Conditional Traffic Routing

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

Routing is the core traffic control mechanism in Dubbo. Based on it, we can implement canary releases, proportional traffic forwarding, same-region prioritization, full-link grayscale, and other traffic strategies. The design and basic principles of the routing (Router) mechanism in Dubbo, along with several built-in routing rules.

Common Traffic Control Scenarios

The built-in traffic strategies in Dubbo are very flexible, but there is also a certain understanding and usage cost. Therefore, we summarize some common usage scenarios and provide configuration methods:

Achieving Traffic Isolation Environments Through Tags (Canary Releases, Multiple Development Environments, etc.)

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

Whether in daily development and testing environments or in pre-production environments, the need for traffic isolation environments often arises.

In daily development, to avoid mutual interference during testing, we need to set up multiple independent testing environments, but building physical clusters is very costly and not flexible enough.
During production releases, to ensure that the new version is fully validated, we need to set up a completely isolated online canary environment to deploy new version services. The online canary environment can fully simulate production runtime conditions, but only a fixed amount of traffic with specific tags will flow to the canary environment, minimizing the risk of online changes while thoroughly validating the new version.

Using Dubbo’s tag routing capability allows for very flexible traffic isolation. It can separately isolate a specific application in a cluster or an entire microservice cluster; it can statically mark the isolation environment during deployment or dynamically isolate part of the machine environment through rules during runtime.

Guiding Traffic Distribution Based on Request Parameters

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

Forwarding traffic based on request parameter values is a very flexible and practical traffic control strategy. For instance, in microservice practices, routing traffic based on parameters (such as user ID) allows a portion of user requests to be directed to the latest product version to validate the stability of the new version and gather user feedback on the product experience, which is a commonly used effective gray mechanism in production practices.

Proportional Traffic Forwarding Based on Weight Values

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

Dubbo provides a weight-based load balancing algorithm that allows for proportional traffic distribution: machines with higher weight receive more request traffic, while those with lower weight receive relatively less.

Based on a weight-based traffic scheduling algorithm, dynamically adjusting the weight of a single machine or a group of machines via rules can change the distribution of request traffic at runtime, enabling dynamic proportional traffic routing, which is useful for several typical scenarios.

Service Downgrading for Weak Dependencies Before Major Promotions

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

Due to the distributed nature of microservice systems, a service often needs to rely on many external services to implement a certain function. Therefore, the stability of a service depends not only on itself but also on the stability of all external dependencies. We can categorize these dependencies based on their importance into strong and weak dependencies: strong dependencies are those that must ensure stability at all costs, as the current service will also be unavailable if they are not; weak dependencies refer to those dependencies that allow the current service to function normally even when they are unavailable, as their unavailability only affects part of the functionality.

Point-to-point Traffic Redirection to a Single Machine (e.g., Troubleshooting Issues)

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

Automatic address discovery and load balancing mechanisms have many advantages; they make it possible to build scalable distributed microservices systems. However, this dynamic traffic allocation also brings a lot of complexity. A typical issue is that we can no longer predict which provider machine a request will hit. Yet, being able to expect or control requests to a specific provider machine can be very useful in certain scenarios. For instance, when developers troubleshoot complex issues in testing or production environments, reliably reproducing issues on a specific machine can greatly aid in final problem resolution.