-
Notifications
You must be signed in to change notification settings - Fork 223
fail fast
chengyouling edited this page Feb 26, 2024
·
3 revisions
系统响应慢、请求超时、并发量一大就崩溃,这些偶然出现的问题,通常问题原因非常复杂,是大多数业务系统在开发设计之初都会忽略的问题。从改善用户体验和维护系统稳定性的角度,建议从架构设计之初,就规划快速失败能力。快速失败能力核心涵盖超时检测和错误重试两个机制。
常见的错误检测措施包括:
-
客户端熔断机制。这个机制在服务治理能力规划里面已经有描述。
-
客户端容错机制。这个机制在服务治理能力规划里面已经有描述,即通常说的微服务重试。客户端容错只对网络错误等进行重试,主要解决的是实例不可用问题。业务端的重试,特别的对于超时请求的重试,需要从业务发起方进行,最好的策略是从小程序等发起。
-
设置较小的请求超时时间。对于HTTP Client的超时时间,建议在3s~30s之间,不能太长,也不能太短。太长会导致故障场景自动恢复时间变长,太短会导致超时错误率增加。具体值需要结合业务的平均时延决定,比如业务平均时延100ms,建议设置5s,业务平均时延200ms,建议设置10s。
-
RestTemplate的HTTP Client超时设置
spring.cloud.servicecomb: httpclient: connectTimeoutInMilliSeconds: 1000 readTimeoutInMilliSeconds: 30000
-
Feign的HTTP Client超时设置
2021.0.x分支对应配置:
feign: client: config: default: connectTimeout: 1000 readTimeout: 30000
2022.0.x/2023.0.x分支对应配置:
spring: cloud: openfeign: client: config: default: connectTimeout: 1000 readTimeout: 30000
-
Spring Cloud Gateway的Http Client超时设置
spring: cloud: gateway: httpclient: connect-timeout: 1000 response-timeout: 30s
-
-
-
单个业务非并发场景下的时延,控制在500ms以下。耗时请求,即平均时延>=500s的请求,采用异步的方式,将请求放到独立的线程池处理。
-
配置合理的线程池队列大小,及时丢弃过多的排队请求。如果框架允许,建议设置排队超时时间,和请求链路超时检测能力。
- 微服务具备针对网络错误进行重试的功能,即客户端容错。但这个不是快速失败必须具备的,更多的是考虑实例下线等场景的失败率。最佳的重试策略建议从应用发起方进行。 小程序、web端的javascript等需要提供重试能力,增加重试策略和重试次数设置能力。
-
使用Spring Cloud Huawei功能
-
使用服务治理
-
生态集成
-
迁移改造问题
-
配置参考
-
优秀实践
-
常见问题