Guiding Traffic Distribution Based on Request Parameters
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.
Alternatively, some products offer differentiated paid services that require routing requests to clusters with different service level guarantees based on user IDs in the request parameters, just as we will do in the example tasks below.
Before You Begin
- Deploy Shop Mall Project
- Deploy and open Dubbo Admin
Task Details
To increase user engagement, we have added a VIP user service to the mall example system. Now the mall has two types of users: regular users and VIP users, where VIP users can see lower product prices than regular users.
Returning to the mall login page, we log in to the system as VIP user dubbo
. Do we see the VIP exclusive product prices as shown in the following image? Refresh the product page a few times.
Oh, is the price fluctuating?! This is because in the currently deployed example system, only the detail v2 version can recognize VIP users and provide special pricing services. Therefore, we need to ensure that the dubbo
user always accesses the detail v2 instance to enjoy stable VIP services.
Providing Stable Special Price Product Services for VIP Users
The detail v2 version can identify VIP users and display special prices in the product details. The product detail service is provided by the org.apache.dubbo.samples.DetailService
service in the Detail application, and the getItem
method of DetailService
is defined as follows, with the second parameter being the username.
public interface DetailService {
Item getItem(long sku, String username);
}
Thus, we will add parameter routing rules to the getItem
method of DetailService
so that if the user parameter is dubbo
, requests will be forwarded to the v2 version of the service.
Operation Steps
- Open the Dubbo Admin console.
- In the left navigation bar, select 【Service Governance】 > 【Parameter Routing】.
- Click the “Create” button and enter.
The index of the method parameters starts from 0
. Filling in 1
indicates that traffic forwarding is based on the second parameter.
Rule Details
Rule Key: org.apache.dubbo.samples.DetailService
Rule Body
configVersion: v3.0
key: org.apache.dubbo.samples.DetailService
scope: service
force: false
enabled: true
priority: 1
conditions:
- method=getItem & arguments[1]=dubbo => detailVersion=v2
method=getItem & arguments[1]=dubbo
indicates that the traffic rule matches the second parameter of thegetItem
method call, performing further address subset filtering when the parameter value isdubbo
.detailVersion=v2
filters out all URL address subsets marked withdetailVersion=v2
(in the example deployment, all our detail v2 instances have been labeled withdetailVersion=v2
).
conditions:
- method=getItem & arguments[1]=dubbo => detailVersion=v2
force: false
means that if there are no addresses with detailVersion=v2
, it will randomly access all available addresses.
Other Considerations
This example is just one use case of Dubbo conditional routing. In addition to forwarding traffic based on method names and parameter matches, conditional routing can also route traffic based on additional parameters Attachments, data in the URL, etc., and the matching conditions support ranges and wildcards, such as:
- attachments[key]=hello*
- arguments[0]=1~100
- url_key=value
More flexibly, the matching conditions for conditional routing support extension, allowing users to customize the source and format of matching conditions. For details, refer to Conditional Routing Rule Description。
Feedback
Was this page helpful?
Yes No
Last modified September 30, 2024: Update & Translate Overview Docs (#3040) (d37ebceaea7)