为了构建高并发、高可用的零碎架构，压测、容量预估必不可少，在发现零碎瓶颈后，须要有针对性地扩容、优化。联合楼主的教训和常识，本文做一个简略的总结，欢送探讨。

1、QPS 保障指标

一开始就要明确定义 QPS 保障指标，以此来推算所需的服务、存储资源。可依据历史同期 QPS，或者平时峰值的 2 到 3 倍估算。

压测指标示例：

• qps 达到多少时，服务的负载失常，如均匀响应工夫、95 分位响应工夫、cpu 使用率、内存使用率、生产提早低于多少
• 不要让任何一个环节成为瓶颈，需思考服务实例、数据库、Redis、ES、Hbase 等资源

2、服务留神点

2.1、服务 qps 下限

服务 qps 下限 = 工作线程数 * 1/ 均匀单次申请解决耗时

次要关注以下几点：

（1）工作线程数，对 qps 起到了间接影响。

dubbo 工作线程数配置举例：
<dubbo:protocol name="dubbo" threadpool="fixed" threads="1000" />

（2）cpu 使用率：跟服务是 I / O 密集型，还是计算密集型无关。

• I/ O 密集型：调用多个上游服务，自身逻辑较简略，cpu 使用率不会很高，因而服务实例的个数不必很多
• 计算密集型：自身逻辑很简单，有较重的计算，cpu 使用率可能飙升，因而可适当多部署一些服务实例

（3）网络带宽：

• 对于大量的小申请，根本无需思考
• 如果申请内容较大，多个并发可能打满网络带宽，如上传图片、视频等。

以理论压测为准。或者在线上调整权重，疏导较多流量拜访 1 台实例，记录达到阈值时的 qps，可估算出单实例的最大 qps。

2.2、超时工夫设置

漏斗型 ：从上到下，timeout 工夫倡议由大到小设置，也即底层 / 上游服务的 timeout 工夫不宜设置太大；否则可能呈现底层 / 上游服务线程池耗尽、而后拒绝请求的问题（抛出 java.util.concurrent.RejectedExecutionException 异样）
起因是上游服务曾经 timeout 了，而底层 / 上游服务仍在执行，上游申请源源不断打到底层 / 上游服务，直至线程池耗尽、新申请被回绝，最坏的状况是产生级联的雪崩，上游服务也耗尽线程池，无奈响应新申请。
具体 timeout 工夫，取决于接口的响应工夫，可参考 95 分位、或 99 分位的响应工夫，稍微大一些。
dubbo 超时工夫示例：在服务端、客户端均可设置，举荐在服务端设置默认超时工夫，客户端也可笼罩超时工夫；
<dubbo:service id="xxxService" interface="com.xxx.xxxService" timeout=1000 />
<dubbo:reference id="xxxService" interface="com.xxx.xxxService" timeout=500 />

2.3、异步并行调用

如果多个调用之间，没有程序依赖关系，为了进步性能，可思考异步并行调用。
dubbo 异步调用示例：

1. 首先，须要配置 consumer.xml，指定接口是异步调用：
   <dubbo:reference id="xxxService" interface="com.xxx.xxxService" async=true />

2. 而后，在代码中通过 RpcContext.getContext().getFuture()获取异步调用后果 Future 对象：

    // 调用 1 先执行
    interface1.xxx();
   
    // 调用 2、3、4 无程序依赖，可异步并行执行
    interface2.xxx();
    future2 = RpcContext.getContext().getFuture();
    interface3.xxx();
    future3 = RpcContext.getContext().getFuture();
    interface4.xxx();
    future4 = RpcContext.getContext().getFuture();
   
    // 获取调用 2、3、4 的执行后果
    result2 = future2.get();
    result3 = future3.get();
    result4 = future4.get();
    // 此处会阻塞至调用 2、3、4 都执行实现，取决于执行工夫最长的那个
    handleResult2(result2);
    handleResult3(result3);
    handleResult4(result4);
   
    // 调用 5 最初执行，会阻塞至前序操作都实现
    interface5.xxx();

2.4、强依赖、弱依赖

• 强依赖调用：决不能跳过，失败则抛异样、疾速失败
• 弱依赖调用：决不能阻塞流程，失败可疏忽

2.5 降级

• 粗粒度：开关管制，如对整个非关键性能降级，暗藏入口
• 细粒度：调用上游接口失败时，返回默认值

2.6 限流

超过的局部间接抛限流异样，万不得已为之。

3、存储资源留神点

3.1、放大倍数：1 次外围操作，对应的资源读写次数、接口调用次数

例如：1 次外围操作，查了 3 次缓存、写了 1 次缓存、查了 2 次数据库、写了 1 次数据库、发了 1 次 MQ 音讯、调了上游服务 A 的接口；

则对于读缓存放大倍数为 3，写缓存放大倍数为 1，读数据库放大倍数为 2，写数据库放大倍数为 1，MQ 放大倍数为 1，调用上游服务 A 的放大倍数为 1。针对写放大倍数，须要独自思考主库是否扛得住放大倍数的 qps。
需关注：

• 读、写的放大倍数，要离开思考，因为分布式架构通常是一主多从，一主须要撑持所有的写 QPS，多从能够撑持所有的读 QPS
• DB 读放大倍数、DB 写放大倍数
• Redis 读放大倍数、Redis 写放大倍数
• MQ 放大倍数
• 接口调用放大倍数等

3.2、存储资源 QPS 估算

存储资源的 QPS 下限，跟机器的具体配置无关，8C32G 机型的 QPS 下限当然要高于 4C16G 机型。下表为典型值举例。