23年的时候公司因调用企业微信接口超限，导致业务问题。架构组经过协商后决定上一个限流服务。
限流这块自然而然就落到我负责的网关这块，小公司我一个人负责api网关这块。
之前基于istio 给公司上线了一个本地的限流(我给公司开发了一个devops管理工具，可以用来管理k8s、istio、jenkins、gitlab等)，但是这个功能不能满足复杂规则的要求，所以找到了ratelimit项目。
项目地址：https://github.com/envoyproxy/ratelimit.git
限流流程如下图所示
配置说明
domain: <unique domain ID>
descriptors:
- key: <rule key: required>
value: <rule value: optional>
rate_limit: (optional block)
name: (optional)
replaces: (optional)
- name: (optional)
unit: <see below: required>
requests_per_unit: <see below: required>
shadow_mode: (optional)
detailed_metric: (optional) # 控制平面不做支持
descriptors: (optional block)
注释里的 控制平面是我基于go-control-palne SDK开发 一个envoy配置管理工具 忽略即可，detailed_metric 这个配置项在我开发控制平面时还没有添加到go-control-plane SDK中 。
domain: 必填，它与envoy上的ratelimitfilter做唯一匹配 descriptors: 描述具体配置
key: 规则键，envoy网关上的路由限流触发规则要与之匹配
value: 具体的值 例如请求头中的值 rate_limit: 速率规则，
unit: 单位， 秒、分钟、小时、天
requests_per_unit: 次数
replaces: 替换，该限流规则替换指定限流规则，使其被替换规则无效，仅本规则生效
shadow_mode: 阴影模式，即始终返回“OK” ,但会记录
detailed_metric：控制平面暂不支持
descriptors: 子项，配置复杂规则
标签：envoy,istio,ratelimit,限流,规则,optional From： https://www.cnblogs.com/pjjwpc/p/18047351