fail fast

快速失败

系统响应慢、请求超时、并发量一大就崩溃，这些偶然出现的问题，通常问题原因非常复杂，是大多数业务系统在开发设计之初都会忽略的问题。从改善用户体验和维护系统稳定性的角度，建议从架构设计之初，就规划快速失败能力。快速失败能力核心涵盖超时检测和错误重试两个机制。

错误检测

常见的错误检测措施包括：

• 客户端熔断机制。这个机制在服务治理能力规划里面已经有描述。

• 客户端容错机制。这个机制在服务治理能力规划里面已经有描述，即通常说的微服务重试。客户端容错只对网络错误等进行重试，主要解决的是实例不可用问题。业务端的重试，特别的对于超时请求的重试，需要从业务发起方进行，最好的策略是从小程序等发起。

• 设置较小的请求超时时间。对于HTTP Client的超时时间，建议在3s~30s之间，不能太长，也不能太短。太长会导致故障场景自动恢复时间变长，太短会导致超时错误率增加。具体值需要结合业务的平均时延决定，比如业务平均时延100ms，建议设置5s，业务平均时延200ms，建议设置10s。

  • RestTemplate的HTTP Client超时设置

    spring.cloud.servicecomb:
      httpclient:
        connectTimeoutInMilliSeconds: 1000
        readTimeoutInMilliSeconds: 30000

  • Feign的HTTP Client超时设置

    feign:
      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等需要提供重试能力，增加重试策略和重试次数设置能力。