Kong的流量控制组件测试和应用(二)

Response Ratelimiting，响应速率限制插件，基于自定义响应消息头进行速率限制。这也是一种限流的插件和Rate Limiting相似，但是有一定的区别。Response Rate Limiting是由后端服务控制频率的减少，而Rate Limiting是由Kong网关来完成的。如下两张对比图详细展示了这种差别：

我们来测试该插件，首先在kong的管理平台上增加该插件：

可以看到该插件的元素和Rate Limiting有些类似的地方，如limit by和policy这个我就不再解释，如果路由或者服务上没有应用认证的插件（如base-auth,key-auth）,kong会使用client ip的维度统计。Redis的配置参数和Rate Limiting也一致。。唯一差别的是在header name和limits的设置。Limits的配置如
{
“visited”:{
“day”:10,
“minite”:2,
……
}
}
默认后端服务会接收到 X-Ratelimit-Remaining- visited请求头，表示还有剩余多少次访问，其中visited是我们定义的limit的名字。我们可以设置x-kong-limit作为回应，表示在剩余值的基础上减少多少。如 x-kong-limit: visited =2，表示减少2；x-kong-limit: visited =0，表示不减少；
我们使用POSTMAN来测试一下：

发现调用http://118.25.142.21:8000/axax路由服务时消息头出现了两个参数：
A：X-RateLimit-Limit-visited-day
B：X-RateLimit-Remaining-visited-day
A代表通过该插件设置的一天最大访问量：10次。
B代表通过调用计算扣减后还剩余的一天访问次数：10次，因为后端服务未进行返回报文扣减，所以即使调用之后剩余次数还是10次，因此我们可以看到限流次数扣减的决定权现在在后端服务中。为什么会出现这种情况呢，我们大致可以分析一下，存在服务调用时后端程序处理错误的情况，这种情况按理不应该计算在限流的阀值之内，或当满足某类业务场景和业务规则时才进行限流，因此由后端程序决定步长的减少也是合理的。
原理我们了解之后，后端服务需要做一些改造才能完成该功能测试，即设置返回报文的消息头中，通过set_header("x-kong-limit ", “visited =1”)来设置本次调用的减少步长。 那么我们来试验一下，首先这个后端API是通过我们的API开发平台自动生成的，那么同样我们可以先下载生成的源码，按要求修改后再部署回去。
第一步: 登录API开发平台下载源码包：

第二步:打开源码包增加Response的Header设置。API开发平台生成的源码是基于Springbot和Swagger集成的，增加Header返回修改如下：

第三步 本地先POSTMAN测试一下再部署到平台，结果正常.

第四步：通过API管理平台对WAR包进行远程服务器部署

第五步：测试远程http://118.25.142.21/amam/api/userpri 返回消息是否包含x-kong-limit。

经过测试无问题。最后我们再来看调用网关路由后的地址：

可以看到X-RateLimit-Remaining-visited-day已经减少了一次，变成了9次了，接下来我们再调用10次，出现429错误如下图：

整个测试和验证完毕，该功能和插件均无问题。