前言
我以为我写的动态扩容能够很好的解决大流量的问题，但又一次败在了现实面前。
通过后续分析，我们发现实际场景并不如想象中的那样，很多时候请求大都在那5秒内瞬间涌进来，也就是会突然有一个尖峰。而这个时候你的服务根本就没有迅速触发动态扩容，也就是没有迸发出最大的处理能力，接着就是大面积的502。
可以得出结论的是，之前的方式方法都不能适配这种方式。
那，应该如何做呢？
再说打压
我们很多时候打压是直接针对当前机器的打压，但却忽视了实际场景的打压。
当然，实际场景打压本身也是非常难做到的。
从用户层面分析，用户触达到实际机器的中间是需要经过很多层的，比如，现在服务绝大部分都是反向代理，在触达到真实服务器之前都需要经过nginx层。
每一层都会直接影响最终的结果。
这么一来，之前的打压结果就值得怀疑了。
调整打压策略
知道了问题，那我们如何去改进呢？
首先，能明确一点就是要尽可能的模拟用户的操作。
这么一来，我们需要梳理整个流程，可以分两部分来考虑：
- 用户层面到达我们服务的过程。
- 从我们的服务再到被真实服务处理的整个过程。
第一部分，情况非常复杂，而且对于打压来说意义不大，因为我们关注的是真实达到我们服务的那个量级。
所以，我们只要重点关注第二部分即可。
做法
两种方式：
- 直接使用域名请求
- 使用ip+Host模式
当然，最好是第二种，可以省去DNS查询时间。
整体分析
- 通过打点，发现从发送扩容消息到最后扩容成功的时间节点分别是：81，81，69，67，65
- 目前整体动态扩容的触发机制大致是：针对每个Worker，当单秒流量达到一个固定值就触发，然后15s内不再触发。
- 正常启动的话，是1Master + 2Workers
所以目前整个扩容机制是：2Workers => 4Workers => 6Workers => 7Workers 这么一个过程。
完成整个扩容过程大概要十几秒的时间，这太慢了。我们希望压缩到2秒这样的级别，那如何做呢？
实施方案
确定目标后，就差实现了，想过很多方式，但演算下来都不好。
终于在某一次的思想碰撞中，迸发出来。
具体就是，针对每个Worker：
- 阈值设置变小，从1600 => 1024。
- 把阈值调整成2048，如果达到了这个阈值，则再次触发扩容。
- 把阈值调整成3096，如果达到了这个阈值，则再次触发扩容。
- 30秒后重置阈值为1024。
核心一点就是：扩容的操作是和流量的增长保持一致。
打压结果
而结果也非常振奋人心，差不多2s内迅速达到了最大处理能力。
结语
看着问题解决了，困扰心中的忧虑也解除了。
而这篇文章也写了将近一个星期。写写停停，删删改改，直至完成。
每写一步都不容易，每一步都在思考，每一步都在用代码和打压来验证。