从上图可以看出，整个请求逻辑还是比较复杂的，在没有 Zuul 网关的情况下，Client 请求 Service 的时候，也有请求超时的可能。那么当增加了 Zuul 网关的时候，请求超时的可能就更明显了。
当请求通过 Zuul 网关路由到服务，并等待服务返回响应，这个过程中 Zuul 也有超时控制。Zuul 的底层使用的是 Hystrix + Ribbon 来实现请求路由。
因此，这里我们需要搞懂 Zuul、Hystrix、Ribbon 它们超时时间之间的关系，以及如何配置它们的超时时间。
注意：
Hystrix 默认情况下是线程池隔离，超时时间为 1000ms。
Ribbon 默认超时为 1000ms，发生超时会进行集群重试。注意：超时时间设置要小于 Hystrix，不然不会进行集群轮训重试。
Hystrix 的超时时间应该大于等于 Ribbon 的超时时间。原因是 Hystrix 是基于 Ribbon 发送请求后的响应情况来进行容错处理的。如果 Hystrix 的超时时间小于 Ribbon 的超时时间，可能会出现 Ribbon 还在等待服务响应，而 Hystrix 已经判定为服务超时并进行熔断等操作的情况。例如，Ribbon 的超时时间为 3 秒，Hystrix 的超时时间应该设置为 3 秒或者更长，这样才能保证 Hystrix 在 Ribbon 确定请求超时后再进行相应的容错处理。
Zuul 的请求超时时间应该大于等于 Ribbon 的超时时间。因为 Zuul 将请求路由到服务实例是通过 Ribbon 来实现的，当 Ribbon 等待服务实例响应超时时，这个超时应该在 Zuul 的整体请求超时范围内。例如，如果 Ribbon 的超时时间设置为 2 秒，Zuul 的超时时间至少应该设置为 2 秒或者更长。否则，可能会出现 Ribbon 还在等待服务响应，Zuul 却已经判定整个请求超时的情况。
Zuul 的超时时间应该大于等于 Hystrix 的超时时间。因为 Hystrix 是在 Zuul 内部对服务调用进行容错处理的一个环节。如果 Zuul 的超时时间小于 Hystrix 的超时时间，可能会出现 Zuul 已经判定整个请求超时，但是 Hystrix 还没来得及进行完整的容错处理（如统计信息收集、熔断状态更新等）的情况。
注意：为了保证系统的正常运行和容错机制的有效实施，在 Zuul 1.x 中，一般建议 Zuul 的超时时间≥ Hystrix 的超时时间 ≥ Ribbon 的超时时间。这些超时时间的合理设置可以根据实际的业务需求和服务性能来调整，以达到最佳的服务质量和容错效果。
配置 Zuul 超时时间：
zuul: host: # 当 Zuul 将请求路由到后端服务后，它会等待后端服务响应 # 如果超过 60 秒还没有收到响应，Zuul 就会认为请求超时并返回相应的错误信息 # 设置为60秒 socket-timeout-milliseconds: 60000
配置 Ribbon 超时时间：
# ribbon 相关配置 ribbon: # 重试次数，此处设置为2次 MaxAutoRetries: 2 MaxAutoRetriesNextServer: 1 # Ribbon 重试，true-开启 OkToRetryOnAllOperations: false # 读取超时时间，单位为毫秒，此处设置为 5 秒，默认 1000ms ReadTimeout: 1000 # 连接超时时间，单位为毫秒，此处设置为 2 秒，默认超时时间 1000ms ConnectTimeout: 2000 # 为所有服务配置统一规则，所有服务都使用轮训策略 NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule
配置 Hystrix 超时时间：
hystrix: dashboard: # 表示允许 Hystrix Dashboard 代理访问所有的流（streams） proxy-stream-allow-list: "*" command: default: execution: isolation: thread: # 线程池隔离，默认超时时间 1000ms timeoutInMilliseconds: 60000
点击下载/查看本教程相关资料或者源代码。
川公网安备51010802032098
