整理出這四個重要的參數，說起來很不易，來源于一次網絡故障事故後的調查，對于平時使用Spring Cloud Gateway(簡稱scg)來說這些參數幾乎很少會關注到，從網上也很少能看到講解的文章，表面上是SCG的問題，實則都是和SCG的底層網絡通信架構Netty有關系。
率先曝光一下這4個參數
System.setProperty("reactor.netty.pool.leasingStrategy", "lifo");
spring.cloud.gateway.httpclient.pool.max-idle-time=PT1S
spring.cloud.gateway.httpclient.connect-timeout=2000
spring.cloud.gateway.httpclient.response-timeout=PT30S
是不是略感陌生，平時的網關使用的都是預設配置，使用起來也沒有問題，因為使用了WebFlux異步非阻塞的架構，底層基于Netty，NIO的異步非阻塞的處理SOCKET，可以讓少量的線程處理大量的業務請求。
是以如果你使用端點監控去檢視網關的線程數，網關中暴露的線程數都不會很高
system_cpu_count{application="i5xforyou-service-gateway",} 4.0
jvm_threads_live_threads{application="i5xforyou-service-gateway",} 123.0
jvm_threads_states_threads{application="i5xforyou-service-gateway",state="new",} 0.0
jvm_threads_states_threads{application="i5xforyou-service-gateway",state="runnable",} 21.0
jvm_threads_states_threads{application="i5xforyou-service-gateway",state="blocked",} 0.0
jvm_threads_states_threads{application="i5xforyou-service-gateway",state="waiting",} 70.0
jvm_threads_states_threads{application="i5xforyou-service-gateway",state="timed-waiting",} 32.0
jvm_threads_states_threads{application="i5xforyou-service-gateway",state="terminated",} 0.0
事情的起源還是從一次網絡故障說起，由于機房網絡的LBC網關出現問題，導緻整體系統的内網網絡出現延遲，各服務内部調用，接口間調用以及連接配接資料庫等所有節點都發生了逾時，延遲擁塞，導緻外部回報使用者在頁面上卡死，所有服務都出現了延遲請求，請求調用非常慢，緻使整個系統出現了雪崩效應，故障持續了相當長的時間，而且找不到原因，隻知道網絡問題卻無從定位，也不知道何時恢複。從日志看網關報各種錯，CPU的負載也相當高，呈現忽高忽低的抖動的狀态。
scg中各種報錯，主要是 Connect reset by peer 和 Connection prematurely closed BEFORE response，
說來也巧，因為事故前上線給部分服務及網關加了Alibaba的Sentinel的的限流降級元件，其中就各配置設定了50%的流量分别到2個隔離的服務叢集中，雖然當時2個叢集都發生了網絡問題，因為同屬于一個網絡分區内，但是加了sentinel的這部分叢集的網關及服務的資源并沒有配置足夠，有問題的這部分scg，當時配置了8台，而沒有問題的scg配置了18台，後端服務的資源也是沒有按1:1的比例配足，最碰巧的是後來重新開機了後端服務及這8台scg, 也沒有恢複問題，而關掉了這8台網關請求居然恢複了。就是這種種的巧合以至于後來的百思不得其解及事故調查分析。甚至一度被懷疑是Sentinel把請求阻塞了，雖然事故原因是由于機房網絡引起的，但是重新開機網關服務恢複這一表象卻難以說服。最後可以解釋的原因就是故障最後網絡問題已經緩解，同時進入到8台scg的流量因為伴随着scg關閉，而流量都進入到了18台scg中。哪一部分叢集的資源比較充足。
和網關相關的調查及分析也就引出了這個4個重要的參數，首先要說明的是，這些參數的配置不會導緻真正發生網絡問題的時候能夠快速解決故障的問題，因為網絡故障是非常緻命及難易管控的，除非具備相應的容災處理方案，例如多機房雙活多活等，否則難易做到對業務的無損操作。是以這些參數的作用不能解決和杜絕網絡問題，隻能說是讓網關性能或者功能得到進一步優化的效果，進而快速定位問題并配合降級保護等政策使服務及scg網關可以得到一些保護。
首先我們調查了網關報錯，Connection prematurely closed BEFORE response，通過日志監控發現，報錯的出現都是在重新開機8台scg的期間發生的
時間點比較吻合，通過查找網上文章 https://blog.csdn.net/rickiyeat/article/details/107900585
裡面描述了報錯的問題及解決方法，雖然我們後端沒有使用tomcat，使用的undertow，但是原理應該是一樣的就是後端服務主動斷開了連接配接，因為當時懷疑是服務故障是以就重新開機了後端服務，而這時scg中的連接配接依然使用了和後端保持的連接配接，而請求發送的時候後端連接配接已經斷開而導緻的報錯。
請求報錯reactor.netty.http.client.PrematureCloseException
就會抛出Connection prematurely closed BEFORE response的異常
和這個相關的配置參數有2個：
spring.cloud.gateway.httpclient.pool.max-idle-time=PT1S # 這個參數的作用就是scg的空閑連接配接逾時回收時間
System.setProperty("reactor.netty.pool.leasingStrategy", "lifo"); #這個參數的作用是先使用後回收的連接配接，而不是先使用先回收的連接配接。是以這2個參數的配合使用，可以讓網關始終能夠取到一個比較新鮮的連接配接。而不會導緻後端連接配接中斷而Scg的連接配接取到的是一個是比較舊的并且很可能是一個後端已經主動斷開的連接配接。
還有2個重要的參數
spring.cloud.gateway.httpclient.connect-timeout=2000 # 全局的TCP連接配接逾時時間預設時間是45秒，是以也就是發生網絡故障的時候，連接配接時間要等待45秒，而網絡連接配接是同步阻塞的 ，The connect timeout in millis, the default is 45s. 是以就會導緻請求非常慢，從網關就卡死了。
spring.cloud.gateway.httpclient.response-timeout=PT30S #全局的響應逾時時間，網絡連結後，後端服務多久不傳回網關就報錯 The response timeout.
當網絡連接配接到達指定的時間，比如預設的45秒後，網關會報錯，日志中會顯示一個 connection timed out的500異常
這也就是當天日志顯示的大量的一個連接配接逾時的報錯
實際就是由于網絡連接配接發生了大量的逾時，而因為預設逾時時間是45秒，是以網關也一直在等待，理論上說，這個時間45秒還是比較長的，如果網絡連接配接問題調成2秒逾時，如果這期間大量的出現 connection reset by peer connection timed out，就可以斷定是網絡發生了抖動或者故障。
請求響應時間也同樣，如果後端服務30秒内仍然未傳回任何回複資訊就會直接逾時報錯，可以說正常響應超過1秒就已經難以忍受了。通過配置逾時時間，如果超過逾時時間，網關會直接報錯，
如果出現了，504 GATEWAY_TIMEOUT "Response took longer than timeout: "， Gateway Timeout 這樣的504錯誤，那麼就可以快速認定是由于後端服務問題導緻的請求響應逾時問題。
是以合理的配置對于快速定位分析問題能夠起到一定的促進作用。如果你還沒有配置，那麼就請留意這些參數的使用吧。