一、 Zuul 服务网关
服务网关 = 路由转发 + 过滤器
1、路由转发：接收一切外界请求，转发到后端的微服务上去；
2、过滤器：在服务网关中可以完成一系列的横切功能，例如权限校验、限流以及监控等，这些都可以通过过滤器完成（其实路由转发也是通过过滤器实现的）。
Spring Cloud Zuul包含了对Hystrix和Ribbon的依赖，下面将一一介绍
二、ribbon 参数配置
提供客户端的负载均衡功能，spring cloud的负载均衡都用到这个库。例如：fegin
它提供了超时重试的功能，配置如下：
ribbon:
ReadTimeout: 2000
ConnectTimeout: 1000
MaxAutoRetries: 1
MaxAutoRetriesNextServer: 1
ribbon.ConnectTimeout：该参数用来设置路由转发请求的时候，创建请求连接的超时时间。若出现路由请求连接超时，会自动进行重试路由请求，如果重试依然失败，Zuul会抛出异常。
ribbon.ReadTimeout：该参数用来设置路由转发请求的超时时间。它的处理与ribbon.ConnectTimeout相似，若出现路由请求连接超时，会自动进行重试路由请求，如果重试依然失败，Zuul会抛出异常。
MaxAutoRetries：最大自动重试次数
MaxAutoRetriesNextServer：最大自动重试下一个服务的次数
总的超时时间 = (1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout
如果超时了，但是熔断机制还没有超时，则zuul会异常
三、hystrix 参数配置
提供线程隔离和断路器的自我保护功能
断路器在超时会自动进行熔断，防止因某一服务的故障出现雪崩，可以设置熔断fallback
隔离策略：
- 线程隔离
- 信号量隔离
隔离策略都是控制线程数量的，只不过是控制的方式不同。 hystrix默认的隔离策略是thread，但是在zuul中，默认的hystrix隔离策略是semaphore
隔离策略和并发设置
隔离策略是THREAD（线程）：
设置线程池
hystrix.command.default.execution.isolation.strategy: THREAD
hystrix.threadpool.default.coreSize: 10
hystrix.threadpool.default.maximumSize: 10
hystrix.threadpool.default.maxQueueSize: -1 # 如该值为-1，那么使用的是SynchronousQueue，否则使用的是LinkedBlockingQueue。注意，修改MQ的类型需要重启。例如从-1修改为100，需要重启，因为使用的Queue类型发生了变化
如果想对特定的HystrixThreadPoolKey 进行配置，则将default 改为 HystrixThreadPoolKey 即可。
隔离策略是SEMAPHORE（信号量）
hystrix.command.default.execution.isolation.strategy: SEMAPHORE
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests: 10 # 默认值
如果想对指定的HystrixCommandKey 进行配置，则将default 改为HystrixCommandKey 即可。
超时设置：
用来设置thread和semaphore两种隔离策略的超时时间，默认值是1000。
hystrix:
command:
default:
execution:
timeout:
enabled: true
isolation:
thread:
timeoutInMilliseconds: 8000
不设置隔离策略，hystrix的超时也是生效的（我使用的是Hystrix1.4.2）
-
建议设置这个参数，在Hystrix 1.4.0之前，semaphore-isolated隔离策略是不能超时的，从1.4.0开始semaphore-isolated也支持超时时间了。
-
建议通过CommandKey设置不同微服务的超时时间,
hystrix.command.[CommandKey].execution.isolation.thread.timeoutInMilliseconds
这个超时时间要根据所对应的业务和服务器所能承受的负载来设置，要根据业务的平均响应时间设置，一般是大于平均响应时间的20%~100%,最好是根据压力测试结果来评估，这个值设置太大，会导致线程不够用而会导致太多的任务被fallback；设置太小，一些特殊的慢业务失败率提升，甚至会造成这个业务一直无法成功，在重试机制存在的情况下，反而会加重后端服务压力。
其他的设置：
#强制打开熔断器，如果打开这个开关，那么拒绝所有request
hystrix.command.default.circuitBreaker.forceOpen=false
四、 zuul 参数配置
超时设置
- 如果Zuul使用服务发现，则需要使用
ribbon.ReadTimeout和ribbon.SocketTimeout功能区属性配置这些超时。
zuul:
routes:
users:
path: /myusers/**
serviceId: users
- 如果通过指定URL配置了Zuul路由，则需要使用
zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis。
zuul:
routes:
users:
path: /myusers/**
url: http://example.com/users_service
这些简单的URL路由不会被执行为HystrixCommand，也不能使用Ribbon对多个URL进行负载平衡。
隔离策略设置
隔离策略：
- 线程隔离
- 信号量隔离
zuul:
ribbonIsolationStrategy: THREAD
并发设置：
当Zuul的隔离策略为SEMAPHORE时：
设置默认最大信号量：
zuul:
semaphore:
max-semaphores: 100 # 默认值
设置指定服务的最大信号量：
zuul:
eureka:
<commandKey>:
semaphore:
max-semaphores: 100 # 默认值
当Zuul的隔离策略为THREAD时
可为Hystrix配置独立线程池，如果不设置独立线程池，那么HystrixThreadPoolKey 是 RibbonCommand
五、Hystrix仪表盘 不显示线程的解决办法
zuul集成hystrix默认使用的是信号量隔离，不是线程隔离。
zuul.ribbon-isolation-strategy=THREAD 修改为线程隔离方式
参考：
Spring Cloud系列（二十五） Zuul配置Hystrix和Ribbon（Finchley.RC2版本）
Spring Cloud各组件调优参数
Hystrix semaphore和thread隔离策略的区别及配置参考
zuul 参数调优
Ribbon重试机制与Hystrix熔断机制的配置问题
spring cloud zuul 配置请求并发
SpringCloud踩坑记录
spring cloud项目性能调优系列一：网关zuul（1）
zuul 并发下的重试配置
Zuul超时问题，微服务响应超时，zuul进行熔断