全面的讲解SpringCloud中Zuul网关原理及其配置，看它就够了( 四 ) Zuul是springcloud中的微服务网关

五、Zuul网关的限流保护Zuul网关组件也提供了限流保护。当请求并发达到阀值，自动触发限流保护，返回错误结果。只要提供error错误处理机制即可。
Zuul的限流保护需要额外依赖spring-cloud-zuul-ratelimit组件。
com.marcosbarbero.cloudspring-cloud-zuul-ratelimit1.3.4.RELEASE5.1 全局限流配置使用全局限流配置， zuul会对代理的所有服务提供限流保护。
# 开启限流保护zuul.ratelimit.enabled=true# 60s内请求超过3次，服务端就抛出异常， 60s后可以恢复正常请求zuul.ratelimit.default-policy.limit=3zuul.ratelimit.default-policy.refresh-interval=60# 针对IP进行限流，不影响其他IPzuul.ratelimit.default-policy.type=origin5.2 局部限流配置使用局部限流配置， zuul仅针对配置的服务提供限流保护。
# 开启限流保护zuul.ratelimit.enabled=true# hystrix-application-client服务60s内请求超过3次，服务抛出异常。 zuul.ratelimit.policies.hystrix-application-client.limit=3zuul.ratelimit.policies.hystrix-application-client.refresh-interval=60# 针对IP限流。 zuul.ratelimit.policies.hystrix-application-client.type=origin5.3 限流参数简介
文章插图
六、Zuul网关性能调优：网关的两层超时调优使用Zuul的spring cloud微服务结构图：
文章插图
从上图中可以看出。整体请求逻辑还是比较复杂的，在没有zuul网关的情况下， app client请求app service的时候，也有请求超时的可能。那么当增加了zuul网关的时候，请求超时的可能就更明显了。
当请求通过zuul网关路由到服务，并等待服务返回响应，这个过程中zuul也有超时控制。 zuul的底层使用的是Hystrix+ribbon来实现请求路由。结构如下：
文章插图
zuul中的Hystrix内部使用线程池隔离机制提供请求路由实现，其默认的超时时长为1000毫秒。 ribbon底层默认超时时长为5000毫秒。如果Hystrix超时，直接返回超时异常。如果ribbon超时，同时Hystrix未超时， ribbon会自动进行服务集群轮询重试，直到Hystrix超时为止。如果Hystrix超时时长小于ribbon超时时长， ribbon不会进行服务集群轮询重试。
那么在zuul中可配置的超时时长就有两个位置：Hystrix和ribbon 。具体配置如下：
# 开启zuul网关重试zuul.retryable=true# hystrix超时时间设置# 线程池隔离，默认超时时间1000mshystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=8000# ribbon超时时间设置：建议设置比Hystrix小# 请求连接的超时时间: 默认5000msribbon.ConnectTimeout=5000# 请求处理的超时时间: 默认5000msribbon.ReadTimeout=5000# 重试次数：MaxAutoRetries表示访问服务集群下原节点（同路径访问）；MaxAutoRetriesNextServer表示访问服务集群下其余节点（换台服务器）ribbon.MaxAutoRetries=1ribbon.MaxAutoRetriesNextServer=1# 开启重试ribbon.OkToRetryOnAllOperations=trueSpring-cloud中的zuul网关重试机制是使用spring-retry实现的。工程必须依赖下述资源：
org.springframework.retryspring-retry来源：www.cnblogs.com/jing99/p/11696192.html