Ratelimit 服务限流常见问题
1、限流规则不生效
与用户确认清楚现象，可能会是以下几种状况：
· 限流监控曲线为空
· 曲线停滞在0水平上
· 超上限的请求没有被拦截
再确认用户的打开姿势，可能会是以下几种：
· 用户自己编写的应用程序间做调用
· 使用官方demo（比如consumer和provider）互相调用
· 使用工具（例如curl/浏览器/fiddler等）构造rest请求发起调用
排障点：
· 对于用户自己编写的程序调用的情况，需要确认用户正确集成了限流sdk，见官网文档
· 对于工具调用的情况，要确认请求得到了正确的应答，这能排除网络问题和请求包非法问题
· 确认规则是否正确下发到ratelimit-master，登录到ratelimit-master主机上执行以下命令（花括号里的变量需要替换）能得到生效规则列表，同时也能知道ratelimit-master是否健康；如果列表为空或反馈问题中的规则没有出现在列表中，则到控制台页面检查规则配置
curl -m 5 -i -X GET "http://localhost:6666/rule/{appid}/{namespace id}/{service name}"
· 确认被调服务是否有实例，登录到ratelimit-master主机上执行以下命令，如果输出的列表是空但控制台微服务详情页面有实例，则检查ratelimit-master config目录下配置文件中的的
userconsul地址和token是否配置正确
curl -m 5 -i -X GET "http://localhost:6666/instance/{appid}/{namespace id}/{service name}"
· 检查sdk是否有请求到ratelimit-master，ratelimit-master如果开启了debug log正常情况下会输出类似以下内容，最后的
rate detail部分就是吐给sdk的限流配额；或到被调服务实例机器上用tcpdump -iany port 7000 -Annlps0抓包查看，关注ratelimit-master回包是否报错或rate为空，或查看ratelimit-master的debug日志，比如实例172.16.16.34连上ratelimit-master就会产生类似以下日志
- 05/27 10:45:02.482 DEBUG handler.go:132 - recv sync rate request, service provider-demo , token [172.16.16.34] , instance 172-16-16-34 , rate detail {[{rate-m2vz8vpl 151 49}]}
- 05/27 10:45:02.482 DEBUG handler.go:152 - 172-16-16-34 final quota: map[rate-m2vz8vpl:100]
· 监控数据上报异常检查，通过查看log中
barad.go的行是否有ERROR来确认，监控地址从consul中barad.report.trace.url取的，可以通过以下命令将配置内容load到本地查看
curl -i -m 3 "http://localhost:8500/v1/kv/config/application/data?raw" > config.dump 2>/dev/null
2、运营端显示ratelimit-master服务器异常
登录到ratelimit-master主机上，检查限流服务进程是否存在，若不存在，tail -n 10 ratelimit.log查看日志文件尾部是否有CRITICAL记录（log文件位置config目录下的yml配置文件中有指定）。
如果CRITICAL记录的message为ip address no found，表示程序无法自选取注册的服务地址，需要显式在配置文件中添加server.netinterface: [有效网口名]配置项来指定绑定的网口名，以网口名eth0为例：
server:
netinterface: eth0
3、限流监控曲线视图为空
用浏览器Network工具查看GetMonitorData的回包，如果回包中有status: 500，则登录到oss模块上查看tsf-metric.log，如果在MetricsService.java:161出现了NullPointException，执行curl -XGET http://10.0.0.10:9201/_cat/indices查看是否有以tsf@为前缀的index，若无，则检查以下上报地址参数：
curl -i -m 3 "http://localhost:8500/v1/kv/config/application/data?raw" | grep barad.report.trace.url
4、限流次数或比例不准确
可以通过ratelimit-master的debug日志观察到sdk执行限流情况，sdk会每秒执行一次上报，上报内容在日志中的打印形式为rate detail { [ { }, ... ] }，接着server回复sdk一个新的配额quota: map[ ...]
05/27 10:45:02.482 DEBUG handler.go:132 - recv sync rate request, service provider-demo , token [172.16.16.34] , instance 172-16-16-34 , rate detail {[{rate-m2vz8vpl 151 49}]}
05/27 10:45:02.482 DEBUG handler.go:152 - 172-16-16-34 final quota: map[rate-m2vz8vpl:100]
目前限流存在以下已知问题：
· sdk定期上报使用的spring Scheduled触发，但其实现受制于连接池问题，可能导致sdk上报周期间隔超过一秒
· sdk设计为上报最近一秒的流量情况，但统计起止时间点和上报做了绑定，当Scheduled没有精确工作时，就会导致上报的统计数据失准
· 现在控制台上展示的总请求数是经ratelimit-master对多条限流规则的统计数据求和而来，就会导致一条被多于一个限流规则放通的请求在统计时被乘以多次，导致页面上总请求数失准
公有云运维
· 程序在包发布，依赖L5agent和consul client
· 配置文件详解（广州为例）：
1. server:
2. address: 0.0.0.0:7000 # 服务监听地址
3.
4.
5. mysql:
6. address: 10.59.xx.xx:14145 # cdb实例地址
7. user: tsf_ratelimit # db账号名
8. password: Tcdn@2007 # db账户密码
9. db: tsf_ratelimit # db库名
10.
11.
12.consul:
13. address: 127.0.0.1:8500 # consul client 地址
14.
15.
16.userconsul:
17. address: 100.121.xx.xx:80 # tsf-consul-access 地址
18. token: oss-acae2d9cb7fd # acl-token 与 oss 一致
19.
20.
21.redis:
22. l5mod: 64468609 # redis L5 sid的mod
23. l5cmd: 589824 # redis L5 sid的cmd
24. password: TSF-data:TSF_data_redis # redis 密码
25. connectioncount: 100 # 连接数上限
26. readtimeout: 100ms # 读超时
27.
28.
29.barad:
30. address: gz.receiver.barad.tencentyun.com # 云监控地址
31.
32.
33.log:
34. file: ./log/ratelimit.log # 日志文件
35. level: debug # 日志等级
· 限流sdk在公有云VPC环境会用
169.254.0.x:7000这个地址来访问ratelimit-master，由tsf-resource将ratelimit-master的地址与VPC中的地址关联（调用vpc oss接口实现），所以需要为ratelimit-master申请一个支撑TGW四层规则，然后将这个四层地址配置到运营端【基础模块管理】的tsf-ratelimit-master的vip vport上· CDB实例与账号与
tsf-ratelimit必须是同一个· redis在北京上海广州用的CKV+，由于上海金融没有CKV+集群，在公有云上购买了redis实例，然后请成都数据库团队帮忙开通了支撑环境L5路由，redis实例也是所有tsf模块共享