稳定性测试报告要求

系统部署架构
降级设计
系统压测

系统部署架构

非设计架构

1. 必须使用SLB
2. 不能出现单点
3. RDS高可用，支持主备
4. 业务日志统一分析

降级设计

步骤：

1. 梳理功能模块，按照功能重要程度，用户侧更重要
2. 实现时尽量不要和业务耦合，确保开关高可用
3. 对优先级低的增加开关，可随时关闭低优先级功能，确保高优先级可用，因为往往低优先级会连带高优先级发生雪崩效应
4. 开关演练，要确保开关生效，要对生产环境下进行演练

系统压测

1. QPS：服务器每秒收到的请求次数
2. RT：接口的整体平均响应时间，峰值<=100ms
3. 总CPU利用率<=70%
4. 内存利用率<=80%
5. 峰值错误率（统计非200）<=0.1%
6. load：CPU负载，linux特有的指标，要求峰值load1（1分钟内）<CPU总核数-0.5，假设CPU 1s能处理100个请求，CPU队列有50个请求，则CPU负载为0.5，CPU队列有100个请求，则CPU负载为1。

步骤：

1. 梳理重要接口，重要场景，大流量接口
2. 制定测试方法，构造测试数据，如模拟的用户，评估压测流量，要求历史峰值的3倍
3. 执行压测，晚间低谷10：00以后，必须压线上环境，同时观察监控
4. 整理压测报告，QPS，RT等

系统常见问题梳理

1.慢SQL原因
错误：
SQL包含业务逻辑
多表联合查询，
索引设计不合理，where条件要加索引
使用like跳过索引
查询尽量精简，一个sql一张表
2.Redis，读写比高的场景多用，全局分布式锁，因为redis天然是单进程的
3.系统内部调用使用RPC，不要用HTTP
4.静态资源使用nginx，不要用tomcat
5.ECS比数据库更容易扩容，多用ECS（应用层）计算数据，比如排序
6.HTTP也是可以用连接池的，比如Aapche-HttpClient