How to Implement Robust Rate Limiting with Alibaba Cloud AHAS

Hello, I am Huang Bowen (nickname Yanmei), responsible for designing and developing the Flow pipeline product under CloudEff. In microservice architectures, the growing number of services and complex inter‑service calls make high availability a challenge. A past incident showed that a sudden API traffic surge can overload a service, so a fast throttling or circuit‑breaking mechanism is essential.

AHAS (Application High Availability Service) is Alibaba's cloud product built on the open‑source Sentinel component. It provides flow control, circuit breaking, hotspot protection, adaptive overload protection, cluster flow control, and service debouncing, along with second‑level traffic monitoring.

Understanding What to Throttle

Traffic can be classified by access method (HTTP synchronous calls, background task calls), by intent (normal business growth, malicious behavior), and by source (end‑user terminals, upstream system calls). Knowing these categories helps define what to limit.

Core Flow‑Control Rule Elements

Interface name – the API to protect.

Source application – usually set to default to apply to all callers.

Per‑machine QPS threshold – the maximum QPS a single instance can handle.

Flow‑control effect – the action taken when the threshold is exceeded (e.g., return 429 Too Many Requests).

Determine the QPS threshold by performance testing; for example, if an interface can handle 200 QPS, you might set the limit to 180 QPS (90% of the maximum).

Ensuring Overall System Availability

Configure a generic flow‑control rule to protect core interfaces and avoid single‑point bottlenecks.

Preventing Individual User Abuse

Identify core service entry methods and set reasonable per‑user call frequencies. Use Sentinel's hotspot flow control by annotating methods:

@SentinelResource(value = "biz1")
public Result doBussinessLogic(String uid, int type) {
    // uid is parameter index 0, type is index 1.
    // some logic here...
}

In the console, configure per‑user limits (e.g., 20 calls per minute per user across 5 instances, which translates to 4 calls per minute per instance).

Isolating Upstream System Abnormal Calls

Inject a request‑origin parser to distinguish callers by a custom header (e.g., income) and assign different thresholds for primary and secondary upstream systems.

@Configuration
public class InterceptorConfiguration extends WebMvcConfigurerAdapter {
    @PostConstruct
    public void setOriginParser() {
        WebCallbackManager.setRequestOriginParser(
            httpServletRequest -> httpServletRequest.getHeader("income"));
    }
}

Define separate flow‑control rules for each upstream source based on the parsed origin.

Full‑Spectrum Limiting Beyond HTTP

For non‑HTTP code, use Sentinel hotspot rules. Example:

@SentinelResource(blockHandler = "blockHandlerExecuteTask")
public Boolean executeTask(Long taskId) throws Exception {
    return taskService.executeTask(taskId);
}

public Boolean blockHandlerExecuteTask(Long taskId, BlockException ex) {
    throw new RuntimeException("execute task exceed");
}

After redeploying, custom‑point data appears in the AHAS console, and you can configure throttling for these non‑HTTP entry points as well.

Overall, these practices help you quickly set up a comprehensive rate‑limiting system with AHAS to protect services from overload, abuse, and upstream anomalies.