当发现这个问题的时候，一定要坚决要求业务方做系统改造，把非核心系 统的强依赖去掉。解耦的技术有很多，需要根据不同的业务规则来选择方案。比如：业务降级、通过中间件解耦、异步化等。
一般来说，在压测的过程中，当碰到压测流量不能再升高的时候，会有很多原因，我们碰到的情况有以下几种：
下游的某些服务化工程的能力达到瓶颈了，导致网关 RT 值升高，拖累整个集群的 QPS 上不去。
网关应用自身的能力达到瓶颈。
中间件 /DB 能力达到瓶颈。
job 的能力达到瓶颈，导致数据处理不够及时。
流量集中的页面，消耗了集群大量资源，如：店铺首页、商品详情页等。
针对 2、3、4 这样的情况，我们的选择是毫不犹豫地加机器，代码优化的性价比较低。
针对第 1 种情况，需要做一些分析，如果这样的能力是在系统设计者的预期之内的，可以选择加机器，如果完全超乎意料的，一定需要通过程序优化来提升能力，否则加了资源，可能还是瓶颈。
针对第 5 种情况，一定要做的事情是静态化。因为这些流量集中页面，一般都是展示性质的。不管如何做应用内的优化，获得的能力提升远不如做静态化的收益大。
全链路压测的方案有赞只是初试牛刀，我们已经看到了这个方案在提升 + 验证集群处理能力方面巨大的价值。当前，这个方案做得还较粗糙，存在一些问题：
压测只能在夜间做。
压测中需要有很多业务开发人员陪同。
链路规划复杂度太高。
压测控制台的稳定性还不够高。
水位检测与流量干预是通过肉眼观察监控来实现。
后续我们团队会继续投入大量精力去完善整个方案。希望可以将压测方案变成：
线上测试链路的机器人，实时检测线上系统的正确性，同时没有脏数据干扰。
测试同学手里的工具，做到流量压测常规化，开发同学不用陪同。
压测可以在白天进行，晚上熬夜毕竟不利于健康。
链路规划图形化，并与数据工厂结合，完成数据的准备工作。
通过水位检测与流量干预来保护系统，让业务系统不会被压崩溃。