很多用户使用SLB 7层监听的时候发现请求没有到达后端,SLB直接响应了503状态码。
什么是503状态码？
503状态码的定义可以参考rfc7231,如下图所示翻译过来就是503意味着服务器过载导致无法响应请求，在SLB上就相当于已经达到了SLB的规格上限，导致SLB无法继续处理请求所以直接响应503状态码给客户端。
为何控制台看QPS远没达到规格上限却也返回503？
SLB性能保障型规格,这里以slb.s1.small 规格举例，此规格的qps是1000，但是使用的时候SLB控制台的qps明明没到1000为何也会有503呢？
因为SLB的监控数据的最小单位是1分钟，也就是1分钟才会统计一个数据点，所以控制台显示的qps其实是1分钟内的平均值，是1分钟内的所有请求除以60秒计算出来的，这跟真实qps是有所差别的，因为这样计算的话会有削峰填谷的效果，比如真实业务里面1分钟内某几秒的请求量特别大，其他时间请求量比较小，一平均之后qps就会看上去没有多大，但是slb是根据秒级的qps限制的，所以如果几秒钟超过qps上限那就会出现503状态码。
下面通过一个简单的测试进一步描述下控制台显示qps的逻辑。
通过AB压测5000请求并发5，通过下图可以看到281，这里的qps计算方法是：总的请求5000/总请求时间17.785秒=281 QPS
在控制台查看此时qps只与79，控制台计算方法是：5000请求/60秒 =83 跟下列图标是比较接近的。 
如何判断秒级qps超过规格？
那如果是SLB返回了503状态码，怎么确定秒级qps呢。 可以开通SLB 7层访问日志。开通以后如下图所示35分0秒到35分59秒一共是5000个请求，在18秒到19秒之间的1秒内的请求qps达到了 734QPS,所以秒级qps跟控制台看到的79 qps 是相差比较大的。 
真实业务场景也是非常类似的，有些业务某几秒的请求量会特别大，导致触发了秒级的qps上限从而响应503，这种情况就需要提升SLB规格来避免这种情况。
