最近社区老被刷，可能是网上曝出的库太多，由很多人去尝试来撞库，粗略统计一下，整个刷的请求量竟然占到了社区整体请求量的60-%-70%,这当然不能忍，最近正在研究Storm，经过一个周末的开发与部署，目前基于Storm的CC防火墙已经应用于社区，目前CC防火墙的限制还是比较低的，但是也有效的将刷的比例降低到了5%一下，下面来看一下技术上的设计。
当前我们社区的架构采用的是在全国各个机房搭建Squid进行静态资源缓存，动态请求透过Squid到后台的几个Nginx，由Nginx转发到后端的IIS与Tomcat，整体的社区一天动态PV在亿级别以上。
目前的防火墙支持动态设置每访问x次的y秒数，低于y秒数时就会对IP进行封锁，支持IP白名单与URL黑名单功能。
本次CC防火墙的架构采用Flume+Kafka+Strom+Zookeeper+Mysql实现，组件包括：Java编写的Storm服务端，Python编写的Client端，PHP编写的前台。
Flume :部署在所有的Nginx服务器上，将Nginx日志推送至Kafka中，
Kafka : 临时存储Nginx的log数据
Strom：从Kafka取数据并进行数据分析
Zookeeper ：存储CC防火墙的配置文件，并且所有部署在Squid上的客户端也注册在这个Zookeeper上。
Client：部署在每台Squid上，并且信息注册到Zookeeper的临时节点上，接收到封停指令后通过iptables封锁IP。
Strom拓扑如下：
KafkaSpOut：进行Kafka数据的读取，这里为了方便与简单，并且保证顺序性Kafka内只是用一个Partion。
LoFormatBolt : 收到KafkaSpout读取出的Nginx日志后进行格式化处理，并在此使用纯真库进行IP GEO匹配
IpAnalysis ： 几乎所有的逻辑都在这里实现，如IP的计数器，报警的匹配等等，为了可以动态调整防火墙的配置，配置文件保存在Zookeeper中，也是在这里Watch Zookeeper的节点，达到动态改变配置的。
BlockBolt ： 接收到IpAnalysis 发送的信息后，将异常的信息通过Thrift发送给各个Squid机器。
BlockReportBlot ： 做数据统计用的，对整体的作用不大
StoreBolt ： 数据库存储Bolt，拓扑上的IPStoreBolt，BlockStoreBolt，BlockReportStoreBolt 都是使用的这一个Bolt。
最终的组装
1 | builder.setSpout("kafkaSpout",kafkaSpout,1); |
下面来看一下防火墙的前端：
左上方可以设置防火前的配置，保存后实时生效，中上方可以查看当前已经上线的客户端，点击详情可以看到此客户端已经封停的IP格式，右上方可以看到曲线，地图，已经两个计数器信息
左下方显示最新的达到计数器的条目，右下方可以看到异常IP在客户端的封锁状况。
当前此版本还是开发版，待功能稍作完善后会考虑开源。
来看看上线后的效果，来刷我们的人80%来自于安徽，此人IP预估保守量至少在1W以上，估计都是肉鸡，而且一直在不间断的刷。
前面比较平缓的地方是CC防火墙开启后的效果，中间在19:38的时候临时关闭了一下，访问瞬间上升10倍，重新开启后访问量会瞬间降到原级别，目前测试遇到过最大的量为20W/分钟，CC开启后可以成功降低到6000-8000/分钟，25倍的效果。