目前的设计方案
1.1.控制计数：
在目前的项目中，有很多接口需要对访问方进行权限访问控制。目前设计方案是：利用redis集群来存储每个访问控制点的访问计数信息。Key值为=PlatformId（接入平台方）+InterfaceId（系统接口）+dayTime（日期时间），value值为当天每个时段的访问次数统计列表。
1.2.控制规则：
通过页面配置并制定控制规则、业务系统在启动时加载控制规则，并访问redis获取控制次数,然后在业务系统中做逻辑判断完成，ACL控制做请求拦截处理。
目前的痛点：
2.1.在大数据量高并发时，由于业务系统是集的并且是并发处理，会出现瞬间redis单点的qps峰值达到13w/s。出现这种情况的原因是Platform+InterfaceId+Day作为key的设计，会造成一个接入方的请QPS过大时直接映射到后端的redis的单点请求上，没有利用到redis的集群效应。
2.2.当前的访问控制功能和业务代码紧密耦合在一起，无法做到单独对访问控制功能进行水平扩展，造成管理与优化不便。
结构图：
初步解决思路：
4.1. 减少redis的访问量、并将redis的key值做细分使其能均匀分布到所在redis集群上.
4.2. 对ACL访问控制功能进行服务化处理，做成无状态支持水平扩展。
4.3. 引入异步处理逻辑、将ACL服务与业务方分离。后续ACL服务的变动对业务系统无感知。
4.4.实现预先计算功能，在做redis汇总统计时现在ACL系统中做分组预计算，减少更新redis的频率。
4.5.延迟检测控制，ACL访问控制目的主要是对一些过量请求进行拦截处理，非一定要保证实时性和一致性。通过延迟统计策略实现高吞吐量的处理能力。
4.6.通知拦截机制，业务方不需要做任何拦截控制统计和分析，只需要接受ACL系统通知并执行通知动作即可。
具体实施细则：
5.1. 所有配置信息统一由配置中心管理，ACL和Service（服务系统）都到zk上注册和订阅服务。
5.2. Service方发送统计消息到MQ上，ACL去订阅该TOPIC来消费
5.3. ACL在自身内存中做初步预处理计算，并定时刷新到redis集群做聚合运算。
5.4. 启动定时服务扫描所有控制规则，检测到需要拦截的规则后，创建广播消息，发送到MQ上。
5.5. Service方订阅广播消息，发现消息后，解析并在内存中对满足规则的访问进行拦截控制。
5.6. 配置中心信息变更时，通过广播推送给所有订阅方，订阅方获取消息后到服务提供方来拉取信息并更新自身内存信息。
结构图如下：
目前该项目的重构方案正在实施，后续实施效果待更新第二版。
本文出自 “海上雪鹰” 博客，请务必保留此出处http://mickelz.blog.51cto.com/4276333/1839565
原文地址：http://mickelz.blog.51cto.com/4276333/1839565
