大促准备(四)限流配置
限流主要是针对非核心服务调用者进行的。
1、确定限流对象
原则上,大促核心链路上的服务都要配置限流,以免大促期间的流量超过预估值把服务器压垮。
同时还要考虑出口限流,主要是对db的限流,配置一个读写总流,以避免把服务器压垮。
2、确定限流实现方式
限流实现方式主要有两种:
- 对Facade包中inteface的方法配置限流
- 定义一个专门的service,这个service中的一个方法是就是一个限流内容。需要限流的服务内引入这个service,而后对这个service中的方法配置限流
方法1的好处是简单,缺点是限流配置可能会分散到多个文件甚至bundle中。
方法2的好处是集中管理,缺点是需要限流的服务要专门引入一个新的serivce,以后每加一个限流内容这个servcie都要进行下修改。
两种方法各有优劣,各个系统可根据自己的业务特点进行配置。
3、确定限流超量处理策略
限流处理的超量处理总体来说有两种策略:
- 不做处理
- 执行指定的动作:抛异常、跳转到指定页面、返回json或xml格式的报文
这两种策略的使用场景主要如下:
- 对于供用户直接访问的网页,最好直接跳转到指定页面,告知用户稍后再试;
- 对于ajax接口,可以返回json或xml格式的报文,客户端解析后使得用户有一个比较好的用户体验;
- 对于上游弱依赖的服务端服务,可以不做处理;但是对于强依赖的服务,最好抛出异常,而后在自己系统内部catch住该异常,再返回一个默认结果给到上游系统;或者自己系统内部可以有一个稍微复杂的设计,对异常进行统计,大于一定范围后可以自动进行熔断。
总体而言,超量之后执行指定动作要好于不做处理。
4、限流验证
配置完成后,就需要进行验证了,验证的方式主要是看日志,通过日志看
- 限流有没有生效
- 限流生效后有没有执行指定的动作
- 有没有误拦
通常而言,我们配置的限流值要比日常的流量值大好几倍的,正常情况下不会触发限流的,因而要触发限流通常有两种方法:
- 在开发或sit环境调小限流值
- 在线上或者预发环境进行压测
5、限流拦截监控
通过查看日志可以知道单机的限流拦截情况,但是一个系统通过会部署上百台服务器,如果要了解整个系统的拦截情况,手工一台台查看而后相加的方式显示是不可取的。
在支付宝中强大的xflush,因而可以利用xflush配置对应的监控,通过监控一目了然了解整个集群的限流情况,主要是配置三个数据:
- 限流总量
- 请求总量
- 拦截总量
然后把这个数据配置到一张报表中,这样就可以方便的在一张报表中了解系统整体限流情况。