<h3 id="背景"><a href="https://fankeke.github.io/#%E8%83%8C%E6%99%AF" class="headerlink" title="背景"></a>背景</h3><p>由于某些服务的流量过大，为保护其后端服务，需要在接入层Nginx对某些服务流量进行截流。本系统可以提供按照百分比对指定域名的制定URI进行截流的功能</p>
接口
管理员可以轻松在管理接口进行配置，接口接口大致如下
实现
采用nginx＋Lua的实现整个系统的截流功能，大致架构图如下：
管理员在接口上写入数据，管理端服务会将数据放入redis集群，各个nginx节点，会定时从redis集群拉取截流数据。
服务接入
为了对达到快速方便的截流目的，默认是每个服务都接入截流系统，而不需要进行nginx配置文档的修改。
access_by_lua_file “/etc/nginx/hlb-lua/access_lua/online_access.lua”; （1）
server {
server_name server1;
}
server {
server_name server2;
}
server {
server_name server3;
}
server {
server_name server4;
}
这样能够到达全自动化的截流：
1 不需要在每个服务配置中做添加任何字段，也就意味着完全不用reload Nginx
2 针对某个服务下的某个路径进行截流，只需在管理端接口上输入数据即可完成
性能测试
由于默认所有流量经过截流检测系统，需要比较造成的性能影响。计算截流逻辑的耗时。每组数据共采集5000条请求的日志，用ab实现压测，计算其在截流逻辑处的平均耗时。共测试10组数据
由压测结果来看，截流逻辑耗时稳定在20us以下。
灾难测试
截流系统依赖redis集群，考虑到集群的挂掉后对整改系统的影响，需要进行灾难测试。灾难测试分为两部分，分别是对管理端的影响和对Nginx节点的影响。
说明：由于所有截流数据缓存在集群的一个分片上，故灾难测试在该分片上进行。下面说的分片特指存放截流数据的分片
结论：从结论看出，截流系统对于redis集群的故障能够做到有损提供服务，做到高可用。
接口设计
设置(修改）降级策略
curl www.admin.com/degrade/admin/?action=set -d ‘{“deg_servername”:”xx”,”deg_location”:”yy”,”deg_percent”:”100”}’
删除降级策略
curl www.admin.com/degrade/admin/?action=del -d ‘{“deg_servername”:”xx”,”deg_location”:”yy”}’
查看查看降级策略
curl www.admin.com/degrade/admin/?action=get -d ‘{“deg_servername”:”xx”,”deg_location”:”yy”}’