这个是一个很重要的模块，在项目启动之初，我们希望以实时计算的方式，一边采集各个应用系统的资源使用情况 + 接口耗时 + 业务正确率，一边向 gatling 发送流量干预信号，以做到自动保护系统的目的。由于时间关系，我们并未实现这一方案。取而代之的是人肉查看实时监控界面的方式，人为去干预 gatling 的流量下发情况。
如果实施过全链路压测的项目，大家都会有一个共同的感受：做基础的组件容易，让核心业务去完成相关的升级与验证工作很难。原因只有一个：需要用全链路压测的公司，业务规模都很大，涉及的团队会特别多。梳理理清楚庞大的业务，让所有的业务团队一起发力，本身就是一件很难的事情。
我们把链路压测的实施分为以下几个阶段：
基础中间件开发，各种框架升级开发，压测器研究与脚本开发。
业务升级与线下验证（人工点击，数据落影子库）
业务升级与线上验证（人工点击，数据落影子库）
数据工厂数据准备。
小流量下发验证（用 gatling 下发，数据落影子库）
大流量量压测与系统扩容
第 2、3、5 阶段，需要借助业务测试同学的力量；第 4 阶段，需要借助业务开发同学的力量；第 6 阶段，则需要借助业务团队 + 运维同学的力量。
由于每个阶段人员都不太一样，所以需要每一个阶段都组织不同成员的虚 拟小组，借助各个团队的力量完成相应的工作。
正常来说，在大促之前做压测，目的一般是给扩容 / 优化做方向性的指导。
假设我们双十一需要扩大 20 倍的容量以应对高峰，那我一定不会一开始 就拿 20 倍的流量去压我们的系统，因为这样做的话，所有的系统都会在一瞬间就挂掉，这样没有任何意义。我们的做法是，阶段性的爬坡打流量，然后把系统的能力一段一段提升上去。
例如：
第一天，我们会以日常流量的最高峰为起始流量，然后爬坡到一个流量高峰 A，记为第一天的目标。在压测之前先做一次扩容。在压测中，碰到了某个瓶颈了，通过增加该系统的机器来提升能力。
第二天，我们以 A 为起始流量，然后再次爬坡到 B。同样压测前做扩容 + 压测中碰到瓶颈加机器。
以此类推，一直到最终流量达到目标流量为止。
每一天的压测，也需要以慢慢爬坡的方式提升流量。在爬坡的某个高度稳定 5 分钟，然后再次爬坡。稳定时间 5 分钟，爬坡时间 30 秒。
发现并解决这个问题，本身就是压测的目的之一。
正常来说，非核心链路，在大促来临时不会扩大多少容量。当压测的压力增大时，很容易通过系统报警查到。