限流

假设现在只能承载1万并发，那么过来5万并发会怎么样？一般情况下，只要持续时间稍久一些，服务基本全都挂了。这种情况在生产环境难免会发生，毕竟业务量也无法测算那么精准。所以为了提高可用性，瞬时请求超过最大阈值，其他的全都忽略才能保证服务安全可用。让客户等下一次请求，总好过服务挂了没的请求。

• 限流也是配置就能实现，在路由中新增下面的节点：

"RateLimitOptions": {
    "ClientWhitelist": [],
    "EnableRateLimiting": true,
    "Period": "1s",
    "PeriodTimespan": 1,
    "Limit": 1
}

• ClientWhitelist：客户端白名单，白名单不受限流规则限制。
• EnableRateLimiting：是否启用限流。
• Period：周期，单位有s(秒)、m(分)、h(时)、d(天)，比如1h
• PeriodTimespan：多少秒后重试。
• Limit：周期内允许多少个请求。

想要更精细的控制，还可以在Global部分添加这些：

"RateLimitOptions": {
  "DisableRateLimitHeaders": false,
  "QuotaExceededMessage": "Customize Tips!",
  "HttpStatusCode": 999,
  "ClientIdHeader" : "Test"
}

• DisableRateLimitHeaders：是否禁用X-Rate-Limit、Retry-After标头。
• QuotaExceededMessage：触发限流时返回的消息。
• HttpStatusCode：触发限流时返回的http状态码（一般会写429）。
• ClientIdHeader：用来识别客户端的标头。
• tips：DisableRateLimitHeaders中提到的X-Rate-Limit、Retry-After：X-Rate-Limit——标准时间内允许多少个请求，Retry-After——触发限流以后多久可以重试。

接下来修改我的配置：

"RateLimitOptions": {
  "ClientWhitelist": [ "myclient" ],
  "EnableRateLimiting": true,
  "Period": "1s",
  "PeriodTimespan": 10,
  "Limit": 1
}

修改全局配置：

"RateLimitOptions": {
  "DisableRateLimitHeaders": false,
  "QuotaExceededMessage": "123123",
  "HttpStatusCode": 429,
  "ClientIdHeader": "Test"
}

• 按配置来看，我设置1秒内最多允许1个请求，超过就触发限流。之后的请求都会返回429和123123，持续10秒。来试试：

• 等待10秒后再次请求，恢复正常：

白名单

白名单里的客户端是不会受到限流限制的。按照配置添加请求头，就可以被白名单识别：

请求时添加这个请求头，无论怎么刷都不会被限流。

超时、熔断、限流的必要性和好处是不言而喻的，但是上生产一定要注意配置的合理性，充分综合业务场景和需要才是王道，毕竟技术如果不解决问题那就毫无意义。