Envoy 可以作为 Sevice Mesh 微服务框架中的代理实现方案，Rainbond 内置的微服务框架同样基于 Envoy 实现。本文所描述的全局限速实践也是基于 Envoy 已有的方案所实现。
Envoy 全局限速
尽管分布式熔断器在大多数情况下控制分布式系统中的吞吐量非常有效，但有时它的效果并不是很好，这时候便需要全局限速。最常见的情况是当大量主机转发到少量主机并且平均请求延迟很短时（例如，发送给数据库服务器的连接/请求）。若目标主机成为备机，则下游主机将压垮上游集群。在这种情况下，很难对每个下游主机配置足够严格的熔断器，使得系统可以平稳运行，同时，当系统开始出现故障时，仍然可以防止级联故障。对于这种情况，全局限速是一个很好的解决方案。
Envoy 全局限速方案需要基于一个全局 RLS（rate limit service）服务实现，RLS 被设计为一种为不同类型应用提供不同限速场景的 Go/gRPC 服务。
构建全局限速服务
一种开箱即用的全局限速服务已经被纳入 Rainbond 内置的开源应用商店中，用户可以基于以下操作一键安装速率限制服务。
- 访问内置的开源应用商店
选择左侧的 应用市场 标签页，在页面中切换到 开源应用商店 标签页，搜索关键词 速率限制** 即可找速率限制服务。
- 一键安装
点击速率限制服务右侧的 安装 可以进入安装页面，填写简单的信息之后，点击 确定 即可开始安装，页面自动跳转到拓扑视图。
参数说明：
等待几分钟后，速率限制服务就会安装完成，并运行起来。
全局限速配置
通过在 Rate-limit-service 组件中编辑配置文件 /data/ratelimit/config/config.yaml，可以配置全局限速标准。
默认配置内容如下：
domain: limit.common
descriptors:
- key: remote_address
rate_limit:
unit: second
requests_per_unit: 10
# Black list IP
- key: remote_address
value: 50.0.0.5
rate_limit:
unit: second
requests_per_unit: 0
在这一段配置中，定义了面向域名 domain 实现每秒允许 10 个请求通过的限速配置。
面向客户端 IP 为 50.0.0.5 的情况，则实现每秒允许 0 个请求通过的限速配置，用户可以理解为黑名单配置。
更多配置示例可以参见 GitHub - envoyproxy/ratelimit: Go/gRPC service designed to enable generic rate limit scenarios from different types of applications.
引用全局限速服务
需要被限速的服务组件需要满足以下条件：
-
安装并配置 服务综合网络治理插件
-
依赖
Rate-limit-service
Rainbond 通过插件机制扩展业务的运维能力，通过安装 服务综合网络治理插件 ，可以在被限速业务的网络入口处扩展治理能力。服务综合网络治理插件 本质上扩展了 Envoy 能力，通过调用 Rate-limit-service ，实现全局限速功能。
确保 OPEN_LIMIT(是否开启限流) 选项为 YES，
LIMIT_DOMAIN(对应限流规则的域名) 与上文中全局限流配置中的 domian 一致。至此，完成了被限速服务一侧的配置。
验证
为了验证限速是否生效，引入 Locust 压力测试工具，向被限速业务不断生成访问请求。
应用默认全局限速策略后，被限速业务在 40 RPS 的情况下限制了 74% 左右的总访问数。
被拒绝的访问，得到了 429 返回码，并提示 Too Many Requests，这是服务限速的标准返回模式。
被限速业务所安装的 服务综合网络治理插件 支持动态配置。这意味着在不停止服务的情况下，只需要将 OPEN_LIMIT(是否开启限流) 选项为 NO 并更新配置 ，即可关闭服务限速，访问错误数将下降至 0。
全局限速生效于被限速业务的网络入口，这意味着无论请求来自 Rainbond 部署的其他微服务组件，还是来自网关以外的外部访问，其请求都会被限速。
总结
全局限速是一种在突发流量激增场景中保护微服务的有效手段，Rainbond 内置的微服务框架支持符合 RLS 规范的 Envoy 服务限速方案。配置起来很简单，并且支持动态变更，本文中的示例力争以直观的方式为大家展现了全局限速在 Rainbond 体系中的配置实践。