1.压测方案设计
压测环境
压测环境可以简单的分为模块级压测和链路级压测,它们的主要特点和区别如下:
模块级压测
1.应用场景:比较变更前后的性能,看性能是否有劣化;定位模块本身的性能瓶颈。
2.环境要求:不要求与线上环境完全一致,只需要保证变更前后两次的压测在同一个环境即可。
3.业界方案:维护一套固定的线下环境,进行周期性、常态的压测。
链路级压测
1.应用场景:做整条链路的容量评估;评估系统整体可用性。
2.环境要求:要求尽量与线上环境保持一致,这样的压测数据才是有借鉴意义的。
3.业界方案:使用线上环境,根据不同的隔离方式使用不同的方案:
a.不做流量隔离,压测流量和业务流量共存,由于没有做隔离,只能在低峰期压测。
b.逻辑隔离,通过流量调度或者分流方式,将压测流量打到一个压测环境去。压测流量和业务流量在同一个机房 跑,但并不会打到同一个业务实例。
C.物理隔离,利用异地多活的特性,将业务流量从一个机房初出,留下一个空机房做压测。
第一种方案是最接近线上真实环境的,但是存在着一些安全风险;后两种方案安全性高很多,但是没有完全利用整 个线上架构,存在一定程度上的失真。
线上压测怎么保证安全性?
1.流量隔离,如上述方法做流量隔离。但是只做流量隔离是不够的,即使是物理隔离,也会对线上数据进行修改, 所以还要做数据隔离。
2.压测流量经过中间件时进行打标,做压测标记,比如http流量可以配置一个特殊的header。
3.在业务集群对流量标记进行数据隔离,比如对压测流量产生的日志写到另一个路径(有的系统会对日志做一些分 析统计);存储/缓存方面将压测流量产生的数据存储到影子表,正常流量访问正常表;
4.消息屏蔽,如果消息队列无法识别出压测消息,则会造成线上消息堆积,影响线上流量,所以需要对压测消息进 行屏蔽。
5.对不支持压测的第三方服务进行mock。
压测发展趋势
现有痛点:
1.需要随时观察监控,需要oncall待命
2.安全性不足
3.方案复杂,代价大
未来发展趋势:
1.智能化
2.无人值守