關於zuul,ribbon和hystrix的配置和說明
在使用spring cloud框架開發微服務時,會遇到zuul,ribbon,hystrix的配置,剛開始接觸到時候會有些懵逼,下面我講講這三者的作用和區別。
zuul:是gateway的核心,叫做路由。在一個專案中,有很多微服務,它們之間的相互呼叫就是通過zuul的設定才能實現的。
ribbon:負載均衡,spring cloud是一個分散式框架,所以ribbon是針對業務模組的多例項負載均衡的配置。
hystrix:熔斷器,當gateway呼叫具體的業務模組的時候,難免會受到網路,查詢效率等因素的影響,導致響應超時,這時候就需要配置hystrix了,以免執行緒一直佔用記憶體,導致記憶體溢位等問題,使得程式down掉。
關於這三個超時策略額問題,zuul和ribbon都有connect-timeout和socket-timeout的配置,當zuul.routes的配置走url的時候,
是zuul.host.connect-timeout-millis,zuul.host.socket-timeout-millis這兩個配生效,當zuul.routes的配置走serviceid的時候,是
ribbon.Readtimeout,ribbon.Sockettimeout生效。
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000這個配置是hystrix的熔斷時間,當請求時間超過這個時間,會自動熔斷,釋放記憶體。
ribbon的重試機制:當一個請求過來被分發到其中的一個例項處理,當這個例項出現問題無法響應或者響應超時的時候,繼續請求當前例項,或者請求其他例項,下面是ribbon重試的配置。
# hystrix的超時時間必須大於ribbon的超時時間 hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000 # 開啟重試 zuul.retryable=true spring.cloud.loadbalancer.retry.enabled=true # 請求連線的超時時間 ribbon.connectTimeout=2000 # 請求處理的超時時間 ribbon.readTimeout=5000 # 對當前例項的重試次數 ribbon.maxAutoRetries=1 # 切換例項的重試次數 ribbon.maxAutoRetriesNextServer=3 # 對所有操作請求都進行重試 ribbon.okToRetryOnAllOperations=true
關於hystrix的超時時間計算的問題說明,以上面的配置時間為例:
ribbon.connectTimeot是請求連線的時間,基本上都是很短的,所以這個請求的時間可以忽略不記,所耗費的時間基本上都是在請求的處理時間上。所以計算的公式是(1+maxAutoRetries+maxAutoRetriesNestServer)*5000,該計算公式會得出一個值,hystrix的超時時間最好要大於這個值,如果小於這個值的話,那麼配置重試就沒有意義了,因為當系統還在進行重試的時候,就把這一次的請求熔斷了。
最後,要使配置生效,專案需要匯入相應的依賴:
<dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId> <version>1.2.1.RELEASE</version> </dependency>