壹般基於SpringCloud的微服務不需要傳統的tomcat就可以獨立運行，SpringBoot起著重要的作用。它的原理是tomcat嵌入在SpringBoot中(當然也可以用其他servlet容器代替，比如jetty)，它可以以java -jar的形式運行。
所以對於每壹個springboot服務，我們都需要對tomcat的壹些參數進行優化。以下是樓主項目組優化的tomcat參數配置，供大家參考。
Tomcat參數描述:
MaxThreads，acceptCount參數應用場景
第壹場
場景2
場景3
MaxThreads調整
壹般來說，服務器性能應該從兩個方面來討論:
1，cpu計算指標
2.io密集型指標
因此，在大多數情況下，tomcat處理更多的io類型的請求，比如帶有數據庫查詢數據的公共接口調用。
另外，在tomcat有大量並發請求的情況下，還要考慮服務器系統參數的優化，比如虛擬機內存設置、linux打開文件限制等。
maxThreads設置有多合適？
我們知道過多的線程會導致cpu在切換線程時花費越來越多的時間。如果線程太少，服務器的請求響應吞吐量會急劇下降，所以maxThreads的配置肯定不是越大越好。
實際情況是設置maxThreads大小沒有最優的方案，要根據具體的服務器配置和實際應用場景不斷調整優化。
acceptCount的設置有多合適？
盡量和maxThreads的大小保持壹致。這個值應該主要根據應用的峰值和平均訪問來衡量配置。
使用URL進行路由時，需要控制zuul . host . connect-time out-millis和zuul . host . socket-time out-millis參數的超時。
請求連接超時。
請求處理超時
重試所有操作請求。
當前實例的重試次數，同壹服務實例的最大重試次數(不包括第壹次調用)。
下壹個實例的重試次數和其他服務實例的重試次數以及最大重試次數相同(不包括第壹個服務器)。
請註意，Hystrix斷路器的超時需要大於ribbon的超時，否則將不會觸發重試。
Feign和Ribbon集成Hystrix後第壹次調用失敗。
目前樓主比較強勢的做法是禁用Hystrix的超時，設置為false。
還有官方提倡設置超時。
在實際工程中，這種方法也有壹些缺點。比如請求時間超過5s，會有偶爾的數據請求，給用戶的感覺是系統不穩定，需要整改。
此外，政府也不推薦使用hystrix。
Hystrix超時設置原則
問題:壹個http請求，如果feign和ribbon都配置了重試機制，那麽壹個* * *在異常情況下會請求多少次？
請求總數n是feignClient和ribbon配置參數的笛卡爾乘積:
n(請求總數)= feign(默認為5次)*(MaxAutoRetries+1)*(MaxAutoRetriesNextServer+1)
其中+1表示功能區本身的默認請求。
實際上，這兩種重試機制是相互獨立的，沒有聯系。但是因為feign肯定會用到ribbon，所以feign的重試機制相對來說比較瑣碎，壹般會關閉這個功能。Ribbon的重試機制默認配置為0，即默認移除重試機制，建議不要修改。