我仍然记得 2013 年夏天，当时我正在运行一个项目，整个应用程序中的 1 个 URL 导致服务器宕机。问题很简单——一个机器人决定以非常高的速度索引我们的站点，并且该机器人创建了数百万个 URL 组合，绕过了我的整个缓存层，它们都访问了我的应用程序服务器。好吧，我们在应用程序中有一个非常高的缓存率（95% 左右）并且应用程序服务器层不是为高负载设计的（它是 Adobe AEM 5.6 并且进行搜索和制作页面的逻辑计算量非常大）。那年早些时候，我们想处理 Dog-Pile 效应的情况，我们曾谈到要进行某种限制。在谈话开始时，每个人都对节流的想法皱眉（除了 2 个人）。
在 2012 年秋天 ，Ravi Pal 建议我们在适当的位置进行错误处理，这样系统就不会掉到头上，而是可以优雅地降级。当我们在 2013 年遇到这个问题时，我才意识到他的建议的严重性。
现在我在另一个平台上工作，当我提出节流的想法时，它再次遭到反对。一个人在一次会议上居然嘲笑我。另一个人建议我们希望通过“自动缩放”而不是节流来处理这种情况。我们在 AWS 云上拥有我们的基础设施，我不是专家，但专家告诉我可以在大约 10 分钟内按原样复制服务器（我们将很快对此进行基准测试）。
我是一位雄心勃勃的架构师，尽管我控制了进入我网站的流量。我不再生活在那种幻想之下。
这可能是一系列帖子，但今天我想开始展示 您别无选择 ，无论您是否喜欢，系统都会为您限制流量。
基准概述
- 使用 Spring Boot 构建的简单 Web 应用程序
- 一个 Spring MVC REST 控制器 ，它将接受一些 HTTP 请求并在诱导延迟后发回 OK 响应
- jMeter模拟负载
- 一个 自定义插件 （对这些插件的大喊大叫）来生成阶梯式负载并捕获自定义增强图形
- 用于托管网站的 Tomcat 8.x – 使用 Spring Boot 在内存中启动。没有完成定制
第一组——好的
测试计划
该线程组将模拟对我们的应用程序服务器的一致请求流。一个经常发生的典型场景。
服务器性能
正如预期的那样？是的。
正如您在下面看到的，该图表显示应用程序服务器运行正常。 15 分钟内的所有请求都符合“单用户模型”，即 1 秒请求响应时间。
第二组——突发性高流量
测试计划
该测试计划是一种分步方法，它试图模拟一种情况，在这种情况下，活动将在短时间内开始点击某个页面（或一组页面）。这是我们在我们的网站向全世界开放的行业中最常见的用例。
这个线程组不是 OOTB，我下载了一个 插件
服务器性能
那么我们期望发生什么？根据我的服务器有多少 juice（线程、cpu 周期等），我的服务器可能会或可能不会处理请求。鉴于我在本地笔记本电脑上运行所有内容，如果我的本地机器可以处理 600 个线程，那将会很有趣。
我们看到我的笔记本电脑无法真正处理 600 个线程。那么Tomcat是做什么的呢？
它节流。
好人的变化如何表现
测试计划
我运行第一个测试计划，然后执行高流量计划（引入 30 秒延迟）。
影响
下图显示了 Good One 是如何受到影响的。虽然 The Good One 的流量没有一点变化，但它仍然受到影响，因为其他因素引入了峰值。
请去告诉 JVM 你不喜欢节流
下一个是什么
您实际上只有 3 个选择（我们将在另一篇文章中研究每个选择的详细信息）。