高速微伺服器怎麼設置

⑴ 生產級基於SpringCloud微服務架構性能優化實戰，建議收藏

本文將從 Tomcat性能優化，SpringCloud開啟重試機制，Zuul網關性能參數優化，Ribbon性能參數優化，Feign與Hystrix性能優化等 五個方面分享在生產環境如何做好SpringCloud性能優化。

一般基於SpringCloud的微服務能夠脫離傳統的tomcat，獨立跑起來，SpringBoot功不可沒，其原理是SpringBoot內嵌了tomcat（當然可以換成其他servlet容器，如jetty），能夠以java -jar形式就能跑起來。

所以針對每個springboot服務，我們需要對tomcat的一些參數進行優化，以下是樓主項目組優化的tomcat參數配置，供大家參考。

tomcat參數說明：

maxThreads，acceptCount參數應用場景

場景一

場景二

場景三

maxThreads調優

一般說伺服器性能要從兩個方面說起：

1、cpu計算型指標

2、io密集型指標

所以大部分情況下，tomcat處理io型請求比較多，比如常見的連資料庫查詢數據進行介面調用。

另外，要考慮tomcat的並發請求量大的情況下，對於伺服器系統參數優化，如虛擬機內存設置和linux的open file限制。

maxThreads設置多大合適？

我們知道線程過多，會導致cpu在線程切換時消耗的時間隨著線程數量的增加越來越大；線程太少，伺服器的請求響應吞吐量會急劇下降，所以maxThreads的配置絕對不是越大越好。

實際情況是設置maxThreads大小沒有最優解，要根據具體的伺服器配置，實際的應用場景不斷的調整和優化。

acceptCount設置多大合適？

盡量與maxThreads的大小保持一致 ， 這個值應該是主要根據應用的訪問峰值與平均值來權衡配置的。

當使用URL進行路由時，則需要對zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis參數控制超時時間。

請求連接的超時時間

請求處理的超時時間

對所有操作請求都進行重試

對當前實例的重試次數，針對同一個服務實例，最大重試次數（不包括首次調用）

對下個實例的重試次數，針同其它的服務實例，最大重試次數（不包括首次server）

注意Hystrix斷路器的超時時間需要大於ribbon的超時時間，不然不會觸發重試

Feign和Ribbon在整合了Hystrix後，首次調用失敗的問題？

目前樓主的強烈做法是： 禁用Hystrix的超時時間，設為false

還有一種是官方提倡的是 設置超時時間。

在實際的項目中親測，這種方式也有不好的地方， 如請求時間超過5s會出現請求數據時有時無的情況 ，給用戶的感覺是 系統不穩定，要求整改 。

另外，禁用hystrix，官方不推薦 。

hystrix超時設置原則

問題：一個http請求，如果feign和ribbon都配置了重試機制，異常情況下一共會請求多少次？

請求總次數 n 為feignClient和ribbon配置參數的笛卡爾積：

n(請求總次數) = feign(默認5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)

其中+1是代表ribbon本身默認的請求。

其實二者的重試機制相互獨立，並無聯系。但是因為用了feign肯定會用到ribbon，所以feign的重試機制相對來說比較雞肋，一般會關閉該功能。ribbon的重試機制默認配置為0，也就是默認是去除重試機制的，建議不要修改。

⑵ Spring微服務灰度發布（熱部署）的實現（二）

接著上篇說，我們微服務中用到的nepxion discovery主要採用了三種灰度發布方式，一種是web圖形化界面發布，二是zuul過濾器灰度發布，三是業務參數策略灰度發布。下面將重點介紹三種方式的實現。

一、web圖形化界麵灰度發布

因為我們項目用到了eureka注冊中心，所以選擇web圖形化界麵灰度發布比較合適。

1） 首先需要建立一個discovery控制台工程console, 埠為2222，控制台工程負責web圖形化界面請求的處理，運行console工程。

2） 下載discovery ui,地址：https://github.com/Nepxion/DiscoveryUI，運行discovery UI，埠為8090

3）瀏覽器中輸入localhost:8090,即可打開控制台，如下

注意：全鏈路灰度發布需要在「配置中心」下才可用。灰度發布配置中心，負責存儲全鏈路灰度發布規則，並將規則推送到各個微服務中。而配置中心可用nacos，redis等，Discovery 中提供了相應配置中心的插件包。

二、zuul網關過濾器灰度發布

通過網關過濾器傳遞Http Header的方式傳遞全鏈路灰度路由規則。下面代碼只適用於Zuul和Spring Cloud Gateway網關，Service微服務不需要加該方式。

三、業務參數在策略類中自定義灰度路由規則

通過策略方式自定義灰度路由規則。下面代碼既適用於Zuul和Spring Cloud Gateway網關，也適用於Service微服務，同時全鏈路中網關和服務都必須加該方式

上面說了具體灰度規則發布方式，那究竟怎麼定義灰度規則呢？？

規則是基於XML或者Json為配置方式，存儲於本地文件或者遠程配置中心，可以通過遠程配置中心修改的方式達到規則動態化。其核心代碼參考discovery-plugin-framework以及它的擴展、discovery-plugin-config-center以及它的擴展和discovery-plugin-admin-center等，規則示例

XML示例（Json示例見discovery-springcloud-example-service下的rule.json）

黑/白名單的IP地址注冊的過濾規則

微服務啟動的時候，禁止指定的IP地址注冊到服務注冊發現中心。支持黑/白名單，白名單表示只允許指定IP地址前綴注冊，黑名單表示不允許指定IP地址前綴注冊。規則如何使用，見示例說明

最大注冊數的限制的過濾規則

微服務啟動的時候，一旦微服務集群下注冊的實例數目已經達到上限（可配置），將禁止後續的微服務進行注冊。規則如何使用，見示例說明

黑/白名單的IP地址發現的過濾規則

微服務啟動的時候，禁止指定的IP地址被服務發現。它使用的方式和「黑/白名單的IP地址注冊的過濾規則」一致

版本訪問的灰度發布規則

版本權重的灰度發布規則

全局版本權重的灰度發布規則

區域權重的灰度發布規則

全局區域權重的灰度發布規則

網關端全鏈路路由策略的灰度發布規則

注意 路由策略的入口有三個（以{"discovery-springcloud-example-a":"1.0", "discovery-springcloud-example-b":"1.0", "discovery-springcloud-example-c":"1.0;1.2"}）為例：

其作用的優先順序為外界傳入>網關Filter指定>配置中心或者本地rule.xml配置

您可以根據自己需求，自由定義灰度發布規則，靈活實現微服務的灰度發布。

源碼位置：https://github.com/Nepxion/Discovery

⑶ 微服務架構是什麼

微服務架構是一項在雲中部署應用和服務的新技術。

大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。

微服務架構相關介紹：

微服務可以在「自己的程序」中運行，並通過「輕量級設備與HTTP型API進行溝通」。關鍵在於該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。

在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程的架構。

微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。

如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。

服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常復雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。