wso2~高级限流策略

• https://apim.docs.wso2.com/en/3.1.0/learn/rate-limiting/adding-new-throttling-policies/
• https://apim.docs.wso2.com/en/3.2.0/learn/rate-limiting/setting-throttling-limits/

对api资源的ip,请求头，请求参数，jwt解析信息的限流规则，让限流更细粒度。

一 api级别策略

admin平台中的Advanced Rate Limiting Policies，需要你在publisher平台api的resourcs菜单中选择API LEVEL才可以配置高级策略

• 开启几个特性的限流

wso2:
 apim:
  configurations:
   throttling:
        enableUnlimitedTier: true
        enableHeaderBasedThrottling: true
        enableJwtClaimBasedThrottling: true
        enableQueryParamBasedThrottling: true

二 application级别策略

admin平台中的Application Rate Limiting Policies

三 应用订阅api的限流策略

admin平台中的https://test-apim.pkulaw.com/admin/throttling/subscription

限流返回值

• handWidth带宽限制和requests请求数限制的返回值，状态码429，内容如下：

{
    "code": "900804",
    "message": "Message throttled out",
    "description": "You have exceeded your quota .You can access API after 2025-Jun-26 04:00:00+0000 UTC",
    "nextAccessTime": "2025-Jun-26 04:00:00+0000 UTC"
}

四 自定义策略

• 复制的策略，需要编写自定义的脚本

五 拒绝策略

可以以下资源进行限制

• api ${context}
• application ${userName}:${applicationName}
• ip ${ip}
• ip range
• user

六 限流的状态码说明

WSO2 APIM 的限流机制设计得很精细，涵盖了从请求频率到后端保护等多个层面。当请求被限流时，API 网关会返回统一的 HTTP 429 (Too Many Requests) 状态码，并在响应体中通过一个特定的错误码来精确指明触发了哪种限流策略。

核心限流策略与错误码

下表整理了 WSO2 APIM 中主要的限流类型及其对应的错误码：

限流策略层级	错误码	描述
API 级别 (API Level)	900800	触发了为整个 API 设置的总体请求配额。
资源级别 (Resource Level)	900802	触发了对 API 中特定资源（如某个 URL 路径）的限流策略。
应用级别 (Application Level)	900803	触发了针对调用该 API 的应用（Application）级别的限流策略。
订阅级别 (Subscription Level)	900804	触发了针对应用订阅该 API 的特定策略（即原先的Tier），这是最常见的一种限流。
自定义策略 (Custom Policy)	900806	触发了用户通过高级策略创建的、复杂的自定义限流规则。
突发控制 (Burst Control)	900807	触发了订阅策略中设置的每秒请求数（RPS）突发限制。
硬限流 (Hard Limit)	900801	触发了为保护后端服务而设置的“最大后端吞吐量”限制，防止后端被压垮。
请求被阻止 (Blocked)	900805	因管理员的实时操作（如封禁IP、用户或应用）而导致请求被直接阻止。

限流响应示例

一个典型的限流响应报文结构如下。其中 code 字段就是上表中的错误码，description 和 nextAccessTime 会提供更具体的受限原因和可重新访问的时间。

{
  "code": "900804",
  "message": "Message throttled out",
  "description": "You have exceeded your quota. You can access API after 2025-Jun-26 04:00:00+0000 UTC",
  "nextAccessTime": "2025-Jun-26 04:00:00+0000 UTC"
}