Zuul的併發性能優化
服務：zuul網關服務，erreka-client服務（10個實例）
一. 筆記本壓測和linux服務器壓測的性能差距
剛開始用zuul代理erreka-client的接口/test/java-user，此接口是裸接口，用ab壓測，tps纔是300多，來回壓，各種壓都上不去，懷疑是我部署的有問題，各種百度優化了許多參數，均無效果，看網上介紹zuul的tps都能上萬，難道我部署了假zuul，開始懷疑我的筆記本配置差，於是驗證了一把，在linux上裝了ab壓測工具，結果tps能到3萬，真實出乎意料啊！
二．壓測併發
於是壓測併發，將裸接口睡眠1s鍾，結果tps不到200，這個性能我接受不了啊！
嘗試一：直接壓測裸接口
直接壓測裸接口，也是不到200的tps，難道是什麼參數的限制嗎，關鍵是這個200，於是把zuul上暴露的參數，修改了個遍，只要與connection和thread有關的參數都調了一遍，測了幾十把，仍無效果。
嘗試二：把內置web容器tomcat換成undertow
壓測zuul網關，結果沒什麼效果啊
嘗試三：將eureka-client的實例數從10變成1，2，4，8測試性能
Eureka-client爲1時，tps時40多，這性能損失嚴重啊，裸接口都有190多，zuul真心垃圾啊。
Eureka-client爲2時，tps時80多，部署多個實例還是有效果的
Eureka-client爲4時，tps時180多。
Eureka-client爲8時，tps時180多，咋又是200的限制。
三．通過jvisiuml和jconsole監控線程排查問題
下面這張圖顯示http-nio-*線程會創建200個，這個是tomcat執行線程。
但是，這個是每個eureka-client實例tps不能突破200的原因
於是，將zuul這個線程數調整到1000,看下圖，說明配置成功，但是zuul的tps依舊不能突破200，肯定是其他影響的
於是通過jvisualvm查看這1000個執行線程狀態，發現並沒有滿負荷運行，阻塞時間較長
於是通過jstack查看這1000個線程執行的代碼棧，1000個線程9000多阻塞，估計是被鎖住了，於是查看這部分代碼，發現是有個http的連接池，池中沒有可用連接就會阻塞，直到池中有連接。那池中的連接數是多少呢，怎麼設置的呢，光看代碼是沒有用的，需要跟蹤代碼運行情況，但是服務跑在linux上，怎麼debug呢，在這裏不得不說eclipse的強大之處，遠程debug。
於是遠程debug代碼，看這部分的邏輯。但是spring-cloud的代碼進不去，於是將源碼拔下來，debug發現了問題，下面兩個參數在啓動的時候會被初始化，這個我設置成1000和10000，也是設置成功的，爲啥還是不行，於是繼續debug，發現運行的時候，池中的連接數又是50，尼瑪，這哪來的?
- zuul.host.max-per-route-connections=20
- zuul.host.max-total-connections=200
於是又多次debug，發現這個池會被初始化兩次，第一次是在啓動的時候，用的上面兩個參數，第二次是在請求的時候，用的下面兩個參數
- ribbon.MaxConnectionsPerHost=50
- ribbon.MaxTotalConnections=200
這個… 不就和我測試的結果一致嗎，單個實例通過代理只能跑40多，多個實例最多不到200，欣喜若狂，問題解決。