Traffic spikes and slow downstream dependencies can cascade into application-wide failures. SAE integrates the traffic protection capabilities of Microservices Engine (MSE), letting you apply throttling, concurrency isolation, circuit breaking, and hotspot parameter protection rules to your microservices applications — all from the SAE console.
Prerequisites
Before you begin, make sure you have:
A deployed SAE application. See Application deployment
Microservices Governance Enterprise Edition of MSE activated. See Activate Microservices Governance
Cost considerations
MSE is billed separately from SAE. For pricing details, see Billing overview of Microservices Governance.
Limitations
Traffic protection applies only to microservices applications created on November 8, 2023 or later.
Open the Traffic Protection tab
Log on to the SAE console. In the left-side navigation pane, choose Applications > Applications.
In the top navigation bar, select a region. From the Namespace drop-down list, select a namespace, and then click the application name.
In the left-side navigation pane, choose Microservice Governance > Traffic Governance, and click the Traffic Protection tab.
Configure rules
All rule types share the same three-step dialog workflow:
Select Protection Scenario — specify the API type, traffic direction, and interface name.
Configure Protection Rule — set thresholds and behavior.
Configure Protection Behavior — associate a behavior (fallback response) with the rule.
After a rule is created, you can edit or delete it from its corresponding tab.
Create a throttling rule
A throttling rule monitors queries per second (QPS). When QPS reaches the threshold, the system intercepts or delays incoming traffic to keep your application stable during traffic spikes.
On the Interface Flow Control tab, click Add Throttling Rule.
In the Add Throttling Protection Rule dialog box, complete all three steps.
In the Configure Protection Rule step, set the following parameters:
| Parameter | Description | Default |
|---|---|---|
| Whether to open | Toggle ON to activate the rule immediately after creation. | Disabled |
| Stand-alone QPS threshold | The QPS value that triggers the rule. | — |
| Flow control effect | How blocked requests are handled. See Choose a flow control effect. | — |
Choose a flow control effect
| Effect | Behavior | Use when |
|---|---|---|
| Fast failure | Requests exceeding the QPS threshold are rejected immediately. The response content is determined by the adaptation module configuration. | You need hard cutoffs to protect backend capacity. |
| Waiting in line | Requests are processed at a constant rate; excess requests queue up. Requests queued longer than the timeout period fail. Must set a queuing timeout. | You want peak-load shifting — delaying bursts rather than dropping them. |
Create a concurrency isolation rule
A concurrency isolation rule caps the number of concurrent threads for an interface or dependency. When the cap is reached, excess requests are rejected until active threads drop below the threshold, preventing thread exhaustion from cascading into broader failures.
On the Concurrency Isolation tab, click Add isolation rule.
In the Add Isolation Protection Rule dialog box, complete all three steps.
In the Configure Protection Rule step, set the following parameters:
| Parameter | Description | Default |
|---|---|---|
| Whether to open | Toggle ON to activate the rule immediately after creation. | Disabled |
| Concurrency threshold | Maximum number of concurrent threads allowed to process requests. | — |
Create a circuit breaking rule
A circuit breaking rule monitors the response time (RT) or abnormal request ratio of a downstream dependency. When the threshold is exceeded, the system immediately lowers the priority of the dependent downstream application and does not call it within the circuit breaking duration. After the duration elapses, the circuit breaker tests recovery based on the configured policy.
To create a circuit breaking rule:
On the Circuit Breaking Rule tab, click Add Circuit Breaking Rule.
In the Add Circuit Breaking Rule dialog box, complete all three steps.
In the Configure Protection Rule step, set the following parameters:
| Parameter | Description | Default |
|---|---|---|
| Statistical window duration | The time window used to evaluate thresholds. Valid range: 1 second–120 minutes. | — |
| Minimum number of requests | The minimum number of requests in the window required to trigger circuit breaking. Below this count, the rule does not trigger even if the threshold is met. | — |
| Threshold type | The metric used to evaluate the rule: Slow call ratio (%) or Abnormal proportion (%). | — |
| Slow call RT | *(Slow call ratio only)* Response time threshold in milliseconds. Requests exceeding this value count as slow calls. | — |
| Circuit Breaking Ratio Threshold | The percentage of slow or abnormal calls that triggers circuit breaking. | — |
| Circuit Breaking Duration (s) | *(Click Show Advanced Options)* How long the circuit stays open. During this period, all calls to the resource fail. | — |
| Circuit Breaking Policy | *(Click Show Advanced Options)* How the circuit breaker tests recovery after the duration elapses. See Choose a circuit breaking policy. | Single detection recovery |
Choose a circuit breaking policy
| Policy | Behavior | Use when |
|---|---|---|
| Single detection recovery | After the circuit breaking duration elapses, the next request is tested. If it passes (not slow or abnormal), the circuit closes. If it fails, the circuit opens again. | The dependency recovers quickly and predictably. |
| Progressive recovery | Traffic is gradually re-admitted across N recovery stages. Each stage allows a larger percentage of requests (T%, 2T%, ... 100%, where T = 100/N). If any stage exceeds the threshold, circuit breaking triggers again. Set Number of recovery phases and Minimum number of passes per step. | The dependency is unstable after an incident and needs gradual warm-up. |
Progressive recovery example: With 3 recovery stages and a minimum of 5 passes per stage, traffic is admitted at 33%, 67%, and 100%. If requests in a stage reach 5, a threshold check runs. Failure at any stage re-opens the circuit.
Create a hotspot parameter protection rule for RPC
Hotspot parameter protection (RPC) identifies the parameters most frequently accessed during resource calls and applies per-parameter throttling. This prevents a small set of hot parameters from consuming disproportionate resources.
The parameter index corresponds to the position in SphU.entry(xxx, args). For example, in SphU.entry(resourceName, EntryType.IN, 1, paramA, paramB), paramA has index 0 and paramB has index 1.
On the Hotspot Parameter Protection (RPC) tab, click Add Hotspot Parameter Protection (RPC) Rule.
In the Add Hotspot Parameter Protection (RPC) Rule dialog box, complete all three steps.
In the Configure Protection Rule step, set the following parameters:
| Parameter | Description | Default |
|---|---|---|
| Parameter position index | Index of the hot parameter in SphU.entry(xxx, args). | — |
| Statistical dimension | Number of requests: limits requests per period. Concurrent number: limits max concurrent requests. | — |
| Statistical cycle time | The measurement period, in seconds. Example: cycle = 10 s, threshold = 5 means max 5 accesses per parameter per 10 seconds. | — |
| Single machine threshold | QPS threshold per hot parameter. | — |
| Flow control effect | *(Available when Statistical dimension = Number of requests)* Fast failure or Waiting in line. In Fast failure mode, set Number of buffered requests to allow additional requests during bursts. In Waiting in line mode, requests exceeding the threshold are queued; set a timeout after which queued requests are rejected. | — |
| Whether to open | Toggle ON to activate the rule immediately after creation. | Disabled |
Create a hotspot parameter protection rule for HTTP requests
Hotspot parameter protection (HTTP requests) applies per-value throttling based on request attributes such as client IP, hostname, HTTP headers, or URL parameters. Use this for fine-grained control over web services.
On the Hotspot Parameter Protection (HTTP Requests) tab, click New Hotspot Parameter Protection (HTTP Requests).
In the New Hotspot Parameter Protection (HTTP Requests) dialog box, complete all three steps.
In the Configure Protection Rule step, set the following parameters:
| Parameter | Description | Default |
|---|---|---|
| Parameter Properties | The request attribute to track: Client IP (uses X-Forwarded-For if proxied), Remote Host, Header (specify header name; supports matching mode), or URL Parameters (specify parameter name; supports matching mode). | — |
| Threshold type | The metric used to evaluate the rule. | Number of requests |
| Threshold | QPS threshold. Supported units: second, minute, hour, day. Example: 10 requests per minute means max 10 requests per minute per parameter value. | — |
| Whether to open | Toggle ON to activate the rule immediately after creation. | Disabled |
| Flow Control Method | *(Click Show Advanced Options)* Fast failure: requests exceeding the threshold are blocked; returns the custom behavior response or default HTTP 429. Waiting in line: requests queue at a constant rate; queued requests exceeding the timeout are rejected immediately. Set QPS to 1,000 per second or fewer when using this mode. | — |
| Burst size | *(Click Show Advanced Options, only for Fast failure)* Number of additional requests allowed during traffic bursts. | — |
| Timeout Period | *(Click Show Advanced Options, only for Waiting in line)* Maximum queuing duration in milliseconds. Requests queued longer than this are rejected. | — |
Manage behaviors
A behavior defines the fallback response returned when a rule triggers. For example, after a web interface hits its throttling limit, the system can return a custom HTTP response instead of a generic error.
Create a behavior
On the Behavior Management tab, click New behavior.
In the New behavior dialog box, configure the parameters and click New.
Apache Dubbo versions 2.7.0–2.7.3 do not support custom behaviors. These versions returnjava.lang.RuntimeExceptioncontainingSentinelBlockedExceptionwhen throttling triggers.
When strategy = Custom return:
| Parameter | Description | Example |
|---|---|---|
| Custom Response Class Name | Full class path. Generic types such as Map<K, V> and List<T> are not supported. | com.alibaba.demo.OrderService:getOrder(long) |
| Custom Response Content (JSON Format) | The JSON response body returned when the rule triggers. | {"id": "123", "name": "test"} |
When strategy = Custom exception:
| Parameter | Description | Example |
|---|---|---|
| Exception Class Name | Full path of the exception class. | java.lang.RuntimeException |
| Exception Message Text | The exception message returned when the rule triggers. | "Operation failed" |
Associate a behavior with a rule
On the Traffic Protection tab, open the tab for the rule type. Find the rule and click Edit in the Actions column.
Complete the Select Protection Scenario and Configure Protection Rules steps.
In the Configure Protection Behavior step, select a behavior from the Association Behavior drop-down list, or click New behavior to create one.
Click Save.
To use the default fallback, select Default Behavior and leave API Type unspecified.
If the interface already has an associated behavior, associating a new one overwrites the existing behavior.
If API Type is not specified in the Select Protection Scenario step, the default behavior is associated automatically.
After API Type is set and a behavior is associated, the type cannot be changed.
Use cases
The following examples show how to configure each rule type for common scenarios.