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

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机型。下表为典型值举例。