轉自：https://blog.csdn.net/xx326664162/article/details/83625104
一、 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
#強制打開熔斷器，如果打開這個開關，那么拒絕所有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 修改為線程隔離方式