无论 HTTP 请求是恶意的（暴力破解密码或 DDoS 攻击）还是正常的（用户批量访问），大量的 HTTP 请求都有可能导致服务不堪重负，从而导致应用崩溃。这个问题有一个简单的解决办法：使用速率限制控制每个用户在特定时间段内的请求数量。然而，在 Kubernetes 环境中，到达某个 service 的大部分流量（即那些与其他 service 通信的流量）可能不在 Ingress controller 的权限范围内。在这种情况下，可以使用 service mesh 来设置速率限制策略。

借助 NGINX Service Mesh，您可以在 10 分钟内轻松完成速率限制的配置。请观看以下实际操作演示，并继续阅读下文，了解如何定义和应用速率限制策略。

Demo：使用 NGINX Service Mesh 配置速率限制

Demo使用三个插入 NGINX Service Mesh sidecar 的容器：一个后端 service、一个前端 service 和一个 bash终端，同时还部署了 NGINX Service Mesh 控制平面。

前端 service 每秒都会向后端 service 发送一个请求，我们可以在前端 service 的日志中看到对这些请求的响应：

backend v1
backend v1
backend v1
backend v1

应用速率限制策略 (1:00)

假设我们不希望后端 service 接收这么多请求，我们可以将限速策略定义为具有以下字段的自定义资源：

• destination——后端 service，接收请求的service；",sans-serif;>
• sources——前端 service，发出请求的客户端列表，每个客户端都实施了速率限制。此demo我们只定义一个source。",sans-serif;>
• rate——速率限制。此处为每分钟 10 个请求，或者每 6 秒钟 1 个请求。",sans-serif;>

apiVersion: specs.smi.nginx.com/v1alpha1
kind: RateLimit
metadata:
name: backend-rate-limit
namespace: default
spec:
destination:
kind: Service
name: backend-svc
namespace: default
sources:
  - kind: Deployment
name: frontend
namespace: default
name: 10rm
rate: 10r/m
burst: 0
delay: nodelay

我们运行以下命令，以启用速率限制策略：

$ kubectl create -f rate-limit.yaml

在前端 service 的日志中，我们发现每 6 个请求中有 5 个被拒绝，并显示以下消息：

head>title>503 Service Temporarily Unavailabletitlehead>
body>
center>503 Service Temporarily Unavailablecenter>
hr>center>nginx/1.19.5center>
body>
html>

将速率限制应用到所有客户端 (2:32)

速率限制仅适用于 sources字段中指定的客户端（前端 service）。sources字段未指定的其他客户端则不受速率限制，后端 service 依然会接受接受大量的未限制发送速率的客户端请求。我们可以通过在 bash批量发送请求来查看；sources字段未指定的其他客户端每个请求都会收到表示成功的 backend v1 响应。

怎么将速率限制应用到所有客户端？我们可以通过两种方法实现。第一种是将所有客户端的名称添加到 sources字段中。在客户端较多的情况下，会相对复杂。第二种更为简单，删除 sources字段，这样程序会识别所有客户端并加入速率限制策略。我们可以通过运行以下命令来编辑策略：

$ kubectl edit ratelimits.specs.smi.nginx.com backend-rate-limit

保存编辑好的策略后，我们再次从 bash发出请求，发现其中超过速率限制的请求被拒绝，并显示如上所示的格式化的 503错误。

允许突发请求 (3:43)

我们还可以将其他几个字段添加到策略中以自定义速率限制。我们知道有些应用是“突发流量”，这时它们会快速连续地发送多个请求。为此，我们可以添加 burst字段。比如我们将burst字段设置为3，这意味着后端 service 会在每 6 秒钟内接受多个额外的请求。超出此范围的请求均将被拒绝。",sans-serif;>

delay字段用于控制如何将被允许的突发请求反馈到后端 service。如果没有该字段（即默认情况下），突发请求会根据速率限制排队处理，并与新请求交错发送。如果要立即处理突发请求，我们可以将 delay字段的值设置为nodelay。

您还可以将 delay字段设置为整数。例如，如果我们将其设置为 3 并将burst字段增加到 5，那么在每 6 秒钟内，当发出 5 个或以上突发请求时，其中 3 个立即发送，2 个排队等待，其余将被拒绝。",sans-serif;>

我们设置 burst: 3和delay: nodelay，在日志中观察效果。可以看到，在拒绝请求之前接受了三个额外的请求：",sans-serif;>

backend v1
backend v1
backend v1
backend v1

head>title>503 Service Temporarily Unavailabletitlehead>
body>
center>503 Service Temporarily Unavailablecenter>
hr>center>nginx/1.19.5center>
body>
html>
…

取消速率限制 (6:30)

运行以下命令，禁用速率限制策略并接受所有请求：

$ kubectl delete -f rate-limit.yml

使用NGINX Service Mesh 进行速率限制

有关突发参数和延迟参数的详细信息，请参阅参考文档。有关其他流量管理模式的探讨，请阅读我们的博文《如何通过高级流量管理提高 Kubernetes 的弹性》。

您还可以观看以下 NGINX Service Mesh 功能演示视频：

• 如何使用 NGINX Service Mesh 进行流量分割
• 如何使用 NGINX Service Mesh 实施安全访问控制

NGINX Service Mesh 完全免费，您可立即下载并在 10 分钟内完成部署！有关使用方法，请查看我们的文档，并通过GitHub 告诉我们您的使用体验。