guoxilin
作者guoxilin2021-07-02 17:12
高级非功能测试专家, 某科技公司

混沌工程测试指南-微服务接口超时

字数 3116阅读 5511评论 0赞 2

一、混沌工程目的及背景说明

    随着分布式系统日益庞大、服务间的依赖错综复杂且很难评估单个服务故障对整个系统的影响,并且请求链路长、监控告警不完善导致发现问题、定位问题难度增大,同时业务和技术迭代快,如何持续保障系统的稳定性受到很大的挑战。最近生产环境就出现模块配置与内部调用组件的超时时间设置为30秒,然而当下游链路在30秒后处理成功,而上游的网关认为下游处理30秒时还没返回就把连接断掉,导致本来正常的交易反而进入异常处理流程,未返回给商户信息 。另外在生产问题也听过因依赖下游服务超时,导致上游服务线程池被打爆 ,服务最终挂起;

因此本次混沌工程实验目的为:
1)针对可能上下游链路风险:通过超时故障注入,来发现发现上下游系统影响,顺便梳理影响链路。杜绝强依赖。
2)验证容错方案是否生效;当服务实例机器超时时,自动切流到正常机器。会隔离或者下线故障服务实例,防止后续请求路由到此服务实例。
实验场景:服务延时实验;
故障类型: 下游服务延时故障类型。
故障对象:应用服务- 创建订单
稳态指标要求:

1)当故障注入期间;故障注入相关节点处理能力会有明显下降,但集群中其他节点应能够正常提供服务;
2)过载请求不应导致连接耗尽、系统宕机问题。
3) 容错方案 生效, 会隔离或者下线此故障,防止后续请求路由到此故障服务实例。 
4) 故障解除后,系统处理能力恢复时长2分钟以内,处理能力恢复程度100%
5) 如有配置服务熔断策略/服务降级策略应生效。 
6) 可跟踪及时告警/不出现资损问题 

二、测试步骤步骤描述:
混沌实验过程
--找到注入对象,本次对象为创建订单
[root@df24d8287194 chaosblade-0.7.0]# jmap -histo 9|grep com.*
[root@df24d8287194 chaosblade-0.7.0]# ls
bin blade lib yaml
[root@df24d8287194 chaosblade-0.7.0]# jps
20785 Jps
9 Starter
1 、通过平台,执行如下命令初始化:
[root@df24d8287194 chaosblade-0.7.0]# ./blade prepare jvm --pid 9 {"code":200,"success":true,"result":"2985908e4fa1b501"}
2 、 选取一般交易日测试模型,以被测试系统最大处理能力的 50% 作为负载压力向被测试系统施压;
3、注入故障命令,微服务超时 30秒:
[root@df24d8287194 chaosblade-0.7.0]# ./blade c jvm delay --time 30000 --classname=com...order.manager.OrderManager --methodname=creatOrd --pid 9
{"code":200,"success":true,"result":"aacd8f82b6652631"}
3 、查看故障执行情况:
[root@df24d8287194 chaosblade-0.7.0]# ./blade status --type create
{
"code": 200,
"success": true,
"result": [
{
"Uid": "aacd8f82b6652631",
"Command": "jvm",
"SubCommand": "delay",
"Flag": " --classname=com...order.manager.OrderManager --methodname=creatOrd --pid=9 --time=30000",
"Status": "Success",
"Error": "",
"CreateTime": "2020-10-29T20:47:15.051971697+08:00",
"UpdateTime": "2020-10-29T20:47:15.521102994+08:00"
}
]
}

[root@df24d8287194 chaosblade-0.7.0]# ./blade d aacd8f82b6652631
{"code":200,"success":true,"result":{"Target":"jvm","Scope":"","ActionName":"delay","ActionFlags":{"classname":"com...order.manager.OrderManager","methodname":"creatOrd","pid":"9","time":"3000"},"ActionPrograms":null}}

[root@df24d8287194 chaosblade-0.7.0]# ./blade status --type prepare
{
"code": 200,
"success": true,
"result": [
{
"Uid": "2985908e4fa1b501",
"ProgramType": "jvm",
"Process": "",
"Port": "37268",
"Pid": "9",
"Status": "Running",
"Error": "",
"CreateTime": "2020-10-29T20:42:15.169186198+08:00",
"UpdateTime": "2020-10-29T20:42:28.477894872+08:00"
}
]
}
--恢复环境
[root@df24d8287194 chaosblade-0.7.0]# ./blade revoke 2985908e4fa1b501
{"code":200,"success":true,"result":"success"}
三、整体故障表现:
通用表现和特殊表现
1)植入超时故障后, 目标程序微服务延时 30 秒后,出现系统 部分 服务线程池占满,开始影响其他服务,此时系统 采取限流措施;
2)注入故障过程期间出现部分交易失败, 对吞吐量的影响整体交易处理能力下降三分之一。
3)故障节点能自动隔离
4)故障解除后能快速恢复;恢复程度100%
四、故障影响评估:
主要影响范围为 故障等级中 故障发生概率中
五、针对性优化建议:
1) 从"杜绝启动强依赖"这条原则出发,当下游出现异常时,应用应具备弱依赖能力的。 避免没有配置合适熔断或降级策略而被拖垮,线程池被打爆,full gc等导致服务不可用等情况。
2)超时设置满足漏斗原则,避免信息不一致。
3) 应能借助超时机制的引入,达到服务的质量会下降但不至于系统全面崩溃。 配置调用超时时间,不会长时间阻塞客户端请求。 达到配置的阈值后,走降级逻辑,如返回固定结果或切换到其他节点。
五、附录
1)故障注入实现方式说明
应用层的响应延迟、OOM等故障模拟手段主要通过ASM、JAVAAssist等JAVA字节码注入技术来实现,其可以模拟常见异常如下游服务超时,实例内存溢出;客户自定义异常,空指针异常,线程池满,连接池满等。在故障模拟命令下达之后,通过业务观察系统的表现是否符合预期。观察的点可以包括:系统监控、业务监控、是否触发报警等,可以通过云监控、业务实时监控服务 ARMS等云服务配合观察。 另外也可以通过模拟指定端口的网络延迟来模拟服务或网络故障,通常服务都有自己的侦听端口。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

2

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广