RESTAPI速率限制用户的最佳实践?

这一切都是通过外部WebServer完成的,它监听世界(我推荐nginx或lighttpd)。

关于速率限制,nginx可以限制,即每个IP 50 req/minute,整个页面都是503,您可以自定义。

关于预期的临时停机,在Rails世界中,这是通过special maintenance.html页面完成的。当Rails应用服务器停机时,有某种自动化创建或符号链接文件。我建议不要依赖于文件的存在,而是依赖于应用服务器的实际可用性。

但实际上,您可以在不丢失任何连接的情况下启动/停止服务。也就是说,您可以在不同的Unix Socket/IP端口上运行应用服务器的单独实例,并让Balancer(nginx/lighty/haproxy)也使用该新实例。然后关闭旧实例,所有客户机都只提供新实例。没有连接丢失。当然,这种情况并不总是可能的,这取决于您在新版本中引入的更改类型。

haproxy是一个平衡机唯一的解决方案。它可以非常有效地平衡对服务器场中应用服务器的请求。

对于相当大的服务,您最终得到的结果是:

• API.DOMAIN解析为Round Robin N Balancers
• 每个Balancer将静态内容的请求代理到M WebServer,动态内容的请求代理到P应用服务器。哦,你的RESTAPI没有静态文件,是吗?

对于非常小的服务(低于2K RPS),所有平衡都在一个两个WebServer内完成。

已经有了很好的答案-如果你不想自己实现限制器,也有类似3scale的解决方案。( http://www.3scale.net )它对API进行速率限制、分析等。它使用插件工作(请参见此处了解 ruby api plugin )它连接到3scale架构中。您也可以通过Varnish使用它,并让Varnish作为一个速率限制代理。

我建议在应用程序之外实现速率限制,否则高流量仍然会影响应用程序的运行。一个好的解决方案是将其作为Apache代理的一部分实现,类似于 mod_evasive