准备阶段
流量规划
- 计算峰值pv公式
( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) - 举例
比如2亿的流量,峰值pv应该为9259的qps
环境部署
oa申请机器和其他资源
内部沟通工具找基础设施负责人进行测试环境的搭建
- dba
- 缓存运维
- 消息中间件韵味
- 系统运维
- 其他中间件运维
- 测试hosts调整
测试代码调整
- 最新的代码上新开测试代码分支
- profile配置
- 代码内外部接口屏蔽(比如发短信等接口)
- 测试域名修改
压测阶段
单机开发压测
- 工具Vegeta
- 制作压测流量文件
- 观察服务器情况(应用,缓存,数据库)
服务器调优
- 优先找运维调整
- 一般为limit问题,内核问题,net配置,正常应该都解决了.
- 如果有特殊情况请找运维一起解决
中间件调优
- 可以自己调的优先自己调,搞不定再找运维协助
代码调优
- findbug
- codereview
- 调优:
- 将所有exception和system.out改为log4j
- log4j打印前判断日志级别
- 是否可以加本地缓存
- 是否可以加分布式缓存
- 是否可以单例
- 是否可以异步
- 是否可以多线程
- 是否可以加nignx反向代理缓存
- 是否可以加cdn
- 是否可以去事务
- 是否可以乐观锁
- 是否可以快速失败
- 是否可以去synchronized
- 是否可以改synchronized为reentrantlock伙readwritelock
- 是否可以改new为clone
- 是否可以减少递归
- 是否可以减少循环
- 是否可以用ThreadLocal共享数据
- 是否可以优化sql是否可以优化索引
- 是否可以优化表设计
- 是否可以分库分表
测试压测
- loadruner
- 录制脚本,修改脚本
- 设定参数,给出结果
容量规划
- 压测的单机qps
- 计算需要的机器数
- 机器:峰值时间每秒QPS / 单台机器的QPS = 需要的机器
- 比如峰值9000,单台测试的qps为900,那么就需要10台机器
集群压测
- 机器扩容
- 继续压测,找出瓶颈,循环优化
代码合并测试
- 优化后的代码合并
- 回归测试
故障预案
高可用
- 数据库mha方案
- redis主从+haproxy方案
- mq镜像+haproxy方案
- 双机房方案
- 降级方案设计,配合zookeeper做通知,做到一键降级
- 应急脚本与流程,提供wiki
监控
- 服务器硬件监控
- cpu,内存,硬盘等
- 中间件监控 (数据库,缓存,mq,zookeeper,tomcat等)
- 端口监控 http端口(80),https端口(443),数据库端口(3306)等
- 域名监控 各应用域名,多地ping监控
- 应用监控 curl或wget或类似的方式确保应用的监控地址返回200
- 业务监控 curl或wget或类似的方式确保业务的监控地址返回200
- 流量监控 对流量日志进行统计,监控流量的变化情况正常
报警
- 内部沟通工具报警 工作时间及时响应
- 短信报警 随时响应
- 邮件报警 内容较多时发邮件
演练
- 对所有流程的故障进行模拟制造
- 检验所有的预案快速顺利执行