架构师才需要知道的知识：如何做容量预估和调优 _架构

为了构建高并发、高可用的系统架构，压测、容量预估必不可少，在发现系统瓶颈后，需要有针对性地扩容、优化。结合楼主的经验和知识，本文做一个简单的总结，欢迎探讨。
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异步调用示例：

首先，需要配置consumer.xml，指定接口是异步调用：<dubbo:reference id="xxxService" interface="com.xxx.xxxService" async=true />
然后，在代码中通过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、强依赖、弱依赖