淺談springcloud gateway 連接?；顔栴}
項目中使用了springcloud gateway作為網(wǎng)關，上游與負載均衡服務器連接。
近期通過監(jiān)控系統(tǒng)觀察，發(fā)現(xiàn)網(wǎng)關與上游負載均衡服務器保持的TCP連接有300+，初步懷疑是調用方未釋放連接
用如下方法進行分析：
1）周期性采集當前建立的連接及端口數(shù)據(jù)
首先是每隔10分鐘連續(xù)采集2兩個小時，發(fā)現(xiàn)在兩個小時之內新出現(xiàn)的端口不到12個，再逐步縮短采樣周期，到最后每秒采集一次，分析發(fā)現(xiàn)每秒種建立一個連接，同時關閉一個連接，當仍存在300+連接，這些連接對應的端口稱為不活躍端口，記錄下這300+不活躍端口。
2）為了進一步分析，用whireshark抓包
發(fā)現(xiàn)絕大部分情況下都是正常的連接和關閉，但這300+個不活躍端口對應的連接上沒有任何數(shù)據(jù)，這300+個不活躍對應的連接稱為不活躍連接。同步趕緊上馬接口調用實時監(jiān)控功能，發(fā)現(xiàn)實際的調用數(shù)量卻非常少（每分鐘不足10個）。
3）與上游的負載均衡工程師一起檢查
從負載均衡服務器看到的活躍連接也是個位數(shù)，并且并未找到在網(wǎng)關上的不活躍端口。也就是說在負載均衡服務器已經(jīng)已經(jīng)拆除了與網(wǎng)關上的不活躍連接對應的連接。咨詢負載均衡工程師，負載均衡設備對于1超過1個小時的不活躍連接會主動拆除。
經(jīng)過以上分析，確定是外部系統(tǒng)經(jīng)過負載均衡設備與網(wǎng)關建立連接后，并未進行任何操作，但網(wǎng)關會一直維護這個連接，導致網(wǎng)關的連接數(shù)持續(xù)上升。
為解決這個問題，需要首先回顧一下傳統(tǒng)的TCP長連接維護機制
針對長連接的維護，傳統(tǒng)的TCP服務采用心跳來維持，比如服務端每分鐘發(fā)送一個心跳報文，并啟動計數(shù)器并設置為1，客戶端收到后回應一個報文，服務端收到回復報文后重置計數(shù)器，如果為收到應答，則一分鐘再發(fā)送一個心跳報文，同時計數(shù)器加1，連續(xù)發(fā)送三個心跳報文并且未收到映帶，則服務端則認為客戶端已經(jīng)失聯(lián)，會主動拆除這個連接，以避免不必要的資源占用。
我們現(xiàn)在使用的springcloud gateway，顯然很難直接修改源碼增加以上的心跳機制，所以我又想到了操作系統(tǒng)協(xié)議棧的連接保活機制。
TCP協(xié)議棧的?；顧C制與應用層的長連接維護機制類似（當然，應用層的TCP長連接維護機制就是從協(xié)議棧的保護機制學習來的'&'），只不過是在協(xié)議棧層面完成，這樣避免了應用層實現(xiàn)負載的長連接維護
?；顧C制如下：
1）服務器端判斷一個連接在指定的時間內
（缺省為2小時）沒有任何數(shù)據(jù)，則發(fā)送一個探測報文，并啟動定時器
2）如果客戶端在正常運行并且網(wǎng)絡可達
則客戶端則回復一個響應報文，服務端認為客戶端正常，則重新開始計時。
如果客戶端主機崩潰或網(wǎng)絡不可達，服務端將收不到應答，定時器超時后（一般為75秒），服務端將再次發(fā)送探測報文，如此連續(xù)發(fā)送若干次（一般為10次），如果均未收到應答，則服務端將主動關閉連接。
當然，如果中間有任何一次服務端收到應答，則認為連接正常，不再發(fā)送探測報文。
使用如下命令可以查看以上?；顣r間、發(fā)送探測報文的間隔和次數(shù)：
#sysctl -a|grep keepalive net.ipv4.tcp_keepalive_time = 7200（單位為秒） net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75 （單位為秒）
關于?；顓?shù)中兩個小時的時間設置存在爭議，通常人們希望這個值可以小很多，比如分鐘級，但?；铋g隔時間是系統(tǒng)級別的變量，如果改變該值會影響所有使用該功能的用戶。
所以，Host Requirements RFC提出一個實現(xiàn)方式，?；铋g隔是可配置的，但缺省不小于兩個小時，并且需要應用程序設置才啟用。
如果使用協(xié)議棧的?；罟δ埽敲慈笔〉膬蓚€小時的時間還是太長，如果縮短這個時間會有什么影響，并無把握。
所以還是先想其他辦法，從網(wǎng)上看到可以通過以下代碼修改網(wǎng)關對長連接的維護辦法，以下代碼是設置?；顣r間為3分鐘，如果3分鐘內連接上沒有數(shù)據(jù)，網(wǎng)關將主動關閉連接：
配置文件：
server:
netty:
idie-timeout: 300
@Configuration
public class NettyConfig {
@Bean
publiWebServerFactoryCustomizer<NettyReactiveWebServerFactory> idleTimeoutCustomizer(
@Value("${server.netty.idle-timeout}") Duration idleTimeout) {
return factory -> factory.addServerCustomizers(
server -> server.tcpConfiguration(
tcp->tcp.bootstrap(
bootstrap->bootstrap.childHandler(new ChannelInitializer<Channel>() {
@Override
protected void initChannel(Channel channel) {
channel.pipeline().addLast(
new IdleStateHandler(0, 0, idleTimeout.toNanos(), NANOSECONDS) {
private final AtomicBoolean closed = new AtomicBoolean();
@Override
protected void channelIdle(
ChannelHandlerContext ctx, IdleStateEvent evt) {
if (closed.compareAndSet(false, true)) {
ctx.close();
}
}
}
);
}
}))));
}
}
系統(tǒng)上線后，通過監(jiān)控系統(tǒng)發(fā)現(xiàn)網(wǎng)關連接數(shù)并未持續(xù)增長，剛松一口氣，線上業(yè)務系統(tǒng)頻頻報錯，請求網(wǎng)關失敗，趕緊安排網(wǎng)絡抓包，然后馬上回退恢復業(yè)務。
然后對網(wǎng)絡抓包進行分析，截圖如下：
從抓包結果來看，客戶端和網(wǎng)關經(jīng)過3次握手后，建立了連接，但后面的建立SSL的過程中，網(wǎng)關返回了400 Bad Request，所以導致業(yè)務系統(tǒng)請求失?。I(yè)務系統(tǒng)使用https請求網(wǎng)關），懷疑是上面的代碼中的配置覆蓋了配置文件中SSL的相關配置，所以導致SSL連接未建立。
我們優(yōu)秀的工程師，本著鍥而不舍的精神對gateway進行源碼分析，經(jīng)過對代碼的分析，發(fā)現(xiàn)確實是這個配置覆蓋了原有的SSL配置，導致SSL配置未生效所致，所以對以上代碼進行改寫，具體如下：
@Configuration
public class NettyConfig {
@Bean
publiWebServerFactoryCustomizer<NettyReactiveWebServerFactory> idleTimeoutCustomizer(
@Value("${server.netty.idle-timeout}") Duration idleTimeout) {
return factory -> factory.addServerCustomizers(
server -> server.tcpConfiguration(
tcp->tcp.bootstrap(bootstrap->{
//增加如下代碼，從而可保持原有配置并追加?；?
BootstrapHandlers.updateConfiguration(bootstrap, "IdleStateHandler",
(connectionObserver, channel) ->{
channel.pipeline().addLast(new IdleStateHandler(0, 0,
idleTimeout.toNanos(), NANOSECONDS) {
private final AtomicBoolean closed = new AtomicBoolean();
@Override
protected void channelIdle(ChannelHandlerContext ctx,
IdleStateEvent evt) {
if (closed.compareAndSet(false, true)) {
ctx.close();
}
}
});
});
return bootstrap;
}
)));
}
}
進行測試驗證，一切OK！
以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。
相關文章
這篇文章主要介紹了java如何遍歷對象中的所有屬性(字段)和類型問題，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2023-07-07
今天給大家?guī)淼氖顷P于Mybatis的相關知識,文章圍繞著Mybatis插件模塊展開,文中有非常詳細的介紹及代碼示例,需要的朋友可以參考下2021-06-06
springboot3.4和mybatis plus的版本問題的解決
本文主要介紹了springboot3.4和mybatis plus的版本問題的解決,主要由于Spring Boot 3.4與MyBatis-Plus版本不匹配導致分頁功能問題,下面就來解決這個問題,感興趣的可以了解一下2025-03-03
這篇文章主要介紹了SpringBoot中請求參數(shù)綁定及使用詳解,在Web應用程序中，請求參數(shù)綁定是非常重要的操作,Spring?Boot框架使得請求參數(shù)綁定變得非常簡單，通過使用注解和預定義的類可以輕松地實現(xiàn)此操作,需要的朋友可以參考下2023-08-08
Java開發(fā)實例之圖書管理系統(tǒng)的實現(xiàn)
圖書管理的功能大體包括：增加書籍、借閱書籍、刪除書籍、查看書籍列表、退出系統(tǒng)、查找書籍、返還書籍這些，本文主要給大家介紹該系統(tǒng)的數(shù)據(jù)庫語句，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2021-10-10
在Java編程中繼承是基礎,但父類轉換為子類時需謹慎,正確的轉換要求父類引用實際指向子類對象,錯誤轉換可能引發(fā)ClassCastException,解決方案包括使用instanceof關鍵字檢查、利用泛型避免轉換、以及通過多態(tài)性避免直接轉換,感興趣的可以了解一下2024-11-11
Apache RocketMQ 是一個常用的開源消息中間件,它提供了強大的有序消息處理能力,這里我們會探討 RocketMQ 是如何保證消息的有序性的,包括其設計原理和相關的源碼實現(xiàn),需要的朋友可以參考下2024-04-04
這篇文章主要介紹了Spring MVC的文件上傳和下載以及攔截器的使用實例，具有一定的參考價值，有興趣的可以了解一下2017-08-08
關于Spring Bean實例過程中使用反射和遞歸處理的Bean屬性填充問題
本文帶領大家一起學習下在Spring Bean實例過程中如何使用反射和遞歸處理的Bean屬性填充，需要在類 AbstractAutowireCapableBeanFactory 的 createBean 方法中添加補全屬性方法，具體操作方法跟隨小編一起學習下吧2021-06-06
SpringBoot基于redis自定義注解實現(xiàn)后端接口防重復提交校驗
本文主要介紹了SpringBoot基于redis自定義注解實現(xiàn)后端接口防重復提交校驗，文中通過示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2022-01-01