DevOps架构下微服务性能测试实践
微服务架构下的性能测试挑战
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/141320ec862dqpus86bfts.png微服务是实现DevOps的重要架构
1.微服务3S原则https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/143440kvtsm1aldcay0pjb.png2.DevOps核心点https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/143508ezlyqmdefivvfvwn.png
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/1415569gjfboo78ldqifgb.png
[*]亿级用户的平台
[*]单服务业务随时扩容
[*]服务之间存在相互调用关系
[*]版本更新快,上线周期短
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/141628j48vdhyphahkw9ns.png
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/141727oorevbane7fmfl4y.png
单服务流量激增时扩容
调用链条变长,调用关系更加复杂
微服务拆分导致故障点增多
▼ ▼ ▼
单服务变更性能影响如何评估?
性能瓶颈在各微服务间漂移,如何做好性能测试?
应对突发流量需求,扩容能否解决问题,如何扩容?
服务实例数量众多,如何收集信息,快速定位性能问题?
微服务性能保障解决方案设计
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/141758fulgthv8boc9qzii.png
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/141815bsfg4rwgculb6zgh.png
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/141839vm0djfwt8shxaxth.png
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/141855ojaajspb0sqs87uh.png
[*]关键设计1:模块化管理,事务灵活组合与复用
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/141934qtqsxcahzsw3gekr.png
[*]关键设计2:应用与资源一体化编排
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/142008juaajx2lfaxohd6i.png
性能测试实施策略
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/1421089tdmuuwquaxcv2il.png
[*]单服务接口测试(契约)
验证单服务的各个接口能力基线以及组合接口的能力基线,服务间遵循契约化原则,大部分问题屏蔽在集成之前
[*]全链路测试(SLA)
验证整个系统之上全链路场景以及多链路组合场景的性能,优化链路中性能不足的服务
[*]伸缩能力验证(面向现网运维)
验证单服务的水平扩容能力,验证既定模型下的多链路组合场景的资源模型
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/142141wj0gxfxxg6njzgiq.png
在微服务架构下,自动化仍然是提升效率,看护质量的重要手段,每个微服务独立快速迭代上线,更加要求微服务的性能不劣化
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/142200tnmvdqcideniirof.png
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/1422242bp9ddcv4haxk2zu.png
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/1422391qzbpavgviq7qlog.png
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/142312zdacjaxb5ka2o5px.png
[*]存在部分响应超时:
a) 服务器繁忙,如某个服务节点CPU利用率高
b) 网络IO超过VM/EIP带宽
c) 等待后端微服务、数据库的超时时间设置过长
[*]TPS未随着并发数增长而上升:
a) 系统性能到达瓶颈,持续并发加压过程中响应时延增加(可观察响应区间统计)
b) 可通过进一步加压是否会出现非正常响应验证
[*]运行一段时间后全部响应超时或者检查点校验不通过:
a) 大压力导致系统中某个微服务奔溃
b) 后端数据库无响应
[*]TP90响应时延较短,TP99时延高:
a) 系统性能接近瓶颈
b) 可通过进一步加压是否会出现非正常响应验证
https://forum-img.huaweicloud.com/data/attachment/forum/201811/08/142416zolqbsjxb0frlnyx.png
[*]扩容:链路中的某一应用可能出现cpu使用率较高或者连接池资源不够用(rpc、jdbc、redis连接池等)但本身对于拿到连接的请求处理又很快,这一类需要横向扩展资源。
[*]应用逻辑优化:比如存在慢sql、 逻辑的不合理如调用db或者redis次数过多、没有做读写分离造成写库压力过大。
[*]超时时间的合理设置:对于应用之间的rpc调用或者应用与其他基础组件之间的调用,均需要设置合理的超时时间,否则过长的等待将造成整个链路的故障。
[*]缓存的应用:请求尽可能从前端返回,而不是每一个都要让后端应用处理后再返回,减轻后端应用及数据库压力,提高系统吞吐能力。
[*]限流:对于超出承载能力的QPS或并发,可以进行拦截并直接返回提示页面。
[*]降级:对于非核心链路上的应用,允许故障关闭而不影响核心链路。
页:
[1]