Hot parameter throttling rules for HTTP requests apply fine-grained throttling to individual parameters in incoming requests for applications that provide web services. For applications that use mainstream web frameworks such as Servlet containers, Spring Web, and Spring Boot, Microservices Engine (MSE) parses request parameters at the API level, so you can throttle resource calls by request dimension to protect your services and system stability. This topic describes how to configure a hot parameter throttling rule for HTTP requests for an application.
Hot parameter throttling rules for HTTP requests were formerly known as web application protection rules.
Background information
In web service scenarios, throttling protection for resource calls by dimensions such as the source IP address of a request or a request parameter complements API-level throttling and degradation, and helps keep your applications running as expected. For example, in high-traffic web scenarios, you may need to limit not only the current API but also the source IP address with the highest access frequency or the product ID with the highest access frequency. The following examples show such cases:
Limit the product ID that is purchased most frequently within a period of time to prevent cache penetration, which sends a large number of requests to the database.
Limit the source IP address that sends a high volume of requests within a period of time to prevent fraudulent bulk requests that submit fake information.
Usage notes
Before you configure a hot parameter throttling rule for HTTP requests, review the following behaviors and limits:
Client IP resolution — If you set Parameter Properties to Client IP and the request passes through a proxy, MSE first tries to obtain the IP address from the
X-Forwarded-Forrequest header. If that header carries an IP address, MSE uses it as the actual client IP address.Response to a throttled request — A rejected request returns the custom message that is configured in behavior management. If no custom message is configured, the default behavior applies: an HTTP 429 error code and the default text message.
Threshold ceiling for queuing — When you use Waiting in line, do not set the QPS to a value greater than 1,000 (a request interval of 1 ms).
Procedure
-
Log on to the MSE console, and select a region in the top navigation bar.
-
In the left-side navigation pane, choose Microservices Governance > Application Governance.
-
On the Application list page, click the resource card of the desired application.
After you go to the application, choose API Details in the left-side navigation pane, click the Hotspot Parameter Protection (HTTP Requests) tab, and then click New.
In the Hotspot Parameter Protection (HTTP Requests) dialog box, configure the rule information, and then click New.
Set the rule information based on the descriptions in Parameters.
In the rule list, select the rule that you created, and then click Open in the Status column.
In the Tips dialog box, click OK to enable the protection rule that you configured.
Parameters
The following table describes the parameters in the Hotspot Parameter Protection (HTTP Requests) dialog box. A row that has no description marks the configuration step or the dialog box section that contains the parameters listed after it. For the client IP resolution rule, the response returned to a throttled request, and the threshold ceiling for queuing, see Usage notes. For examples that map a scenario to a set of values, see Use cases.
| Parameter | Description |
| Configure Protection Rule | |
| Parameter Properties | Applies throttling based on a parameter property of the selected API. For the supported properties, see Parameter property values. |
| (Optional) Match Pattern and Match String | Available when you set Parameter Properties to Header or URL Parameters. Turn on the Property Value Match switch, and then specify Match Pattern and Match String. For the supported patterns, see Match patterns. |
| Threshold Type | The default value is Number of requests. |
| Threshold | The QPS threshold of the statistical object that triggers throttling for the API. When you set the threshold, select a statistical interval. Second, minute, hour, and day are supported. For example, if you set the threshold to 10 and select Points as the interval, no more than 10 requests are allowed per minute. |
| Advanced Options | |
| Flow Control Method | Specifies how throttled traffic is handled. For the supported methods, see Flow control methods. |
| Burst size | If you set Flow Control Method to Fast failure, you can specify an additional burst size, which is the number of extra requests that are allowed for traffic spikes. |
| Timeout time | If you set Flow Control Method to Waiting in line, you must specify a timeout in milliseconds (ms). For example, if the QPS is 5, only one request passes every 200 ms, and the excess requests are queued. The timeout is the maximum queuing time. A request that exceeds the maximum queuing time is rejected. |
| Whether to open | Enabled: The hot parameter throttling rule for HTTP requests takes effect as soon as it is created. Disabled: The rule does not take effect after it is created. |
| Configure Protection Behavior | |
| Association Behavior | Specifies the post-throttling behavior of the rule. For the available options, see Association behavior options. |
Parameter property values
The following values are supported for Parameter Properties:
Client IP: The IP address of the client that sends the request.
Remote Host: The Host header of the client that sends the request.
Header: Throttling is based on the specified HTTP header. If you enter a specific header key, the rule limits the hot values under that header key separately. After you select Header, you can configure a matching policy for the request attribute value. Only attribute values that match the pattern are counted and throttled.
URL Parameters: Throttling is based on the specified HTTP request parameter. You must enter the corresponding parameter name. After you select URL Parameters, you can configure a matching policy for the request attribute value. Only attribute values that match the pattern are counted and throttled.
Match patterns
Valid values of Match Pattern:
accurate: Matches values strictly against the specified match string.
Substring: Matches if the request attribute value contains the substring. For example, if the substring is
ab, bothabaandcabcare matched, butcbais not.Regular: Matches values against the specified regular expression.
Flow control methods
The following values are supported for Flow Control Method:
Fast failure: If the threshold type is QPS, the throttled traffic fails fast. That is, requests are rejected immediately when the threshold is reached.
Waiting in line: If the threshold type is QPS, the throttled requests pass at a steady rate and are allowed to queue. You must specify a timeout. A request that is expected to reach the timeout fails immediately instead of entering the queue. For example, if the QPS is 10, only one request passes every 100 ms, and the excess requests are queued. The timeout is the maximum queuing time. A request that exceeds the maximum queuing time is rejected.
Association behavior options
The following values are supported for Association Behavior:
Default Behavior: The default option. Use the default behavior if you do not need to customize the post-throttling behavior.
New behavior: Adds a custom post-throttling behavior. After you create the behavior, you can select it from the Association Behavior drop-down list.
Use cases
Each of the following examples maps a scenario to the parameter values that the scenario requires in the Hotspot Parameter Protection (HTTP Requests) dialog box. Configure the parameters that an example does not list, such as Whether to open, as described in Parameters.
Flash sale for a hot product
In scenarios such as flash sales, high traffic may slow down the response of your system or even crash it. To keep the system stable, configure a hot parameter throttling rule for HTTP requests. When the specified threshold is exceeded, the system rejects the excess traffic for the hot product.
For example, to allow a maximum of 100 order requests per second for each individual hot product ID and reject all excess order requests for that product, configure the following parameters:
Set Parameter Properties to URL Parameters.
For URL Parameter Name, enter
stockId.Set Threshold to 100 requests per Second.
Set Flow Control Method to Fast failure.
For Parameter Properties, select the parameter field that carries the ID of the current hot product. In this example, the URL parameters contain a stockId field that carries the requested product ID.
Fraudulent bulk requests during a promotion
During promotions, a large number of fraudulent bulk requests may consume product inventory or server resources. In this case, apply Waiting in line to the source IP addresses of the requests so that requests pass at a steady rate and excessive requests do not affect service stability.
For example, configure the following parameters. Requests that each different source IP address sends to this API pass at a steady rate of one request every 10 ms (1 s/100 = 10 ms), and the excess requests are queued. A queued request that waits for more than 30 ms fails immediately.
Set Parameter Properties to Client IP.
Keep the default value Number of requests for Threshold Type.
Set Threshold to 100 requests per Second.
Set Flow Control Method to Waiting in line.
For Timeout time, enter 30.
Set Whether to open to Enabled.