快速限流路径和慢速业务路径设计,提升web服务可用性

这是我的高吞吐http2服务器优化经验分享系列 第五篇博客。

背景

在web程序设计中，限流代码路径在业务代码路径之前执行，这是常识。

因此，将限流路径设计的尽可能快而准，对提升web服务可用性很有益。

推荐的快速限流路径

一个推荐的快速限流路径是这样的：

特别注意：这些代码应该尽可能快，最好在纳秒级时间完成判断

不要什么都自己做。

所有请求经过CDN，再到达源服务器。先从源头减少请求数，而且现代CDN支持配置限流，使得不需要使用自己的计算资源，也能实现限流。

先本机配置基于ip的限流

目的是防止极端情况，本机自行也能抗一定程度的大量请求。

这个时候也尽可能的快，因此任何HTTP响应头，Cookie都不要设置，在同ip快速大量访问时，可直接视为恶意攻击，除了403什么都不响应。

甚至直接在TLS握手时拒绝，但小心切勿将 CDN 的出口 IP 误判为攻击源，防止网站无法访问，因为CDN的ip大量访问很可能是正常的。

例如go语言的tls.Config就提供了GetCertificate挂钩，可以做到TLS握手时拒绝被限流的请求。

再配置基于可用资源的限流

CPU和内存等可用资源是有限的，如果检测到CPU占用100%或内存即将耗尽等情况，可以配置执行限流，响应503。

注意实践中流量比较可能是突发的，比如到时间特定电影开播，这时候视频服务器突然收到大量请求。

实践中，面对突发流量（如热门电影上线瞬间），立即猛烈限流（而非缓慢限流）往往是更有效的策略。

最后配置特定业务的限流

根据业务需求限流。

比如比较消耗数据库、比较消耗内存等的，限流限制强一些

返回静态文件的，可以没有那么强。