通常线上的服务是一种多对多的结构，服务多机器部署，服务依赖多服务，例如下图：服务A部署了N台服务，即Service-A-1，Service-A-2，至Service-A-N，Service-A-VIP是服务A的统一入口(注：虚拟IP技术，Virtual IP，简写VIP)；服务A可能依赖服务B、服务C、服务D等多个子服务；服务C与A一样同是一种多对多的结构，下面有子服务E、子服务F。
因此，我们在对上层的服务如服务A进行性能测试，就需要保证他依赖的子服务（服务B、服务C、服务D）能够正常使用。而标题中“性能资源摸底方案”是指如何巧妙安全地对线上上层服务进行极限性能摸底，并进行资源调优，合理分配服务器的数量。
安全QPS
首先需要介绍几个概念。在性能摸底时，我们部署一个新的服务Service-A-Test，它与线上的Service-A-1~N共享子服务B/C/D。需要强调的是，我们对 Service-A-Test性能测试，绝不能把他使用到的Service B/C/D给弄挂了。故将对Service-A-Test能压测的不影响 Service B/C/D正常运作的最大QPS定义为安全QPS，即：QPSsafe。
QPSsafe可以通过如下计算所得：
( QPSpeak - QPSperiod_max ) * N
其中，QPSpeak 是服务历史QPS峰值，QPSperiod_max是压测时间段峰值，因此我们再这个时间段，对服务A 压测QPSperiod_max - QPSpeak这么大的QPS，他的子服务是完全扛得住的， 而N为部署服务A的机器数。
进而，在对服务进行摸底时，只要压测QPS不超过安全QPS就不要告知下游的子服务。若对服务A压测，我们无需通知服务B/C/D的owner。
服务性能摸底
如图所示，我们需要对服务A进行性能摸底，可以按如下步骤操作
- 计算并确认安全QPS。
- 在一台机器上部署服务A（Service-A-Test），配置 Service-A-Test使用线上的服务B/C/D。
- 准备线上流程query做压测用，（因采用阶梯式压测，需要使得每个压测梯度间的query不一样，避免cache影响）
- 对 Service-A-Test进行压测，利用profiling等工具进行观察调优。
因为是探测摸底，这里可以改采用阶梯式压测。QPSmax为单机服务极限QPS, QPSstart为最开始的压测QPS, QPSend是最大的压测QPS，QPSstep为每次加的QPS大小，压测次数m。
QPSstart = QPSmax
QPSend = min( 3 * QPSmax, QPSsafe QPS)
QPSstep = ( QPSend - QPSstart ) / m
资源调优
资源利用率：QPSpeak/QPSmax，线上实际流量的最大QPS 除以 能够承受的最大QPS 为资源。
资源红线RAratio：机器资源利用阈值。如：单机房80%、双机房40%
单机设定为80%时，双机房为什么40%->因为在双机房的场景下，需要服务在挂掉一台的情况，另一台机器需要扛起两份的流量，所以预留一台的流量能力，故双机房为40%，以此可粗略计算三机房是80%/1.5 = 53.3%（不完全严谨正确）
可以按如下方式进行调优：
总结
面的性能摸底、资源调优方案既可以适用于日常的迭代，也可以直接作用于线上服务；我们重点关注主干服务，进行全局调优；方案机制确定后，可以定期压测，即时预警；机器资源分配可以按照上游宽松，下游收缩的原则。总结如下：
1、覆盖业务：拓扑主干，全局调优
2、适用场景：迭代流程、线上流程
3、执行周期：定期压测，及时预警
4、资源红线：上游宽松，下游收缩
来源：https://www.cnblogs.com/byonecry/p/8476781.html