在java界,netty無疑是開發網路應用的拿手菜。你不需要太多關注複雜的nio模型和底層網路的細節,使用其豐富的介面,可以很容易的實現複雜的通訊功能。
和golang的網路模組相比,netty還是太過臃腫。不過java類框架就是這樣,屬於那種離了IDE就無法存活的編碼語言。
最新的netty版本將模組分的非常細,如果不清楚每個模組都有什麼內容,直接使用netty-all
即可。
單純從使用方面來說,netty是非常簡單的,掌握ByteBuf、Channel、Pipeline、Event模型等,就可以進行開發了。你會發現面試netty相關知識,沒得聊。但Netty與其他開發模式很大不同,最主要的就是其非同步化。非同步化造成的後果就是程式設計模型的不同,同時有除錯上的困難,對編碼的要求比較高,因為bug的代價與業務程式碼的bug代價不可同日而語。
但從專案來說,麻雀雖小五臟俱全,從業務層到服務閘道器,以及各種技術保障,包括監控和配置,都是需要考慮的因素。netty本身佔比很小。
本文將說明使用netty開發,都關注哪些通用的內容,然後附上單機支援100w連線的linux配置。本文並不關注netty的基礎知識。協議開發
網路開發中最重要的就是其通訊格式,協議。我們常見的protobuf、json、avro、mqtt等,都屬於此列。協議有語法、語義、時序三個要素。
我見過很多中介軟體應用,採用的是redis協議,而後端落地的卻是mysql;也見過更多的採用mysql協議實現的各種自定義儲存系統,比如proxy端的分庫分表中介軟體、tidb等。
我們常用的redis,使用的是文字協議;mysql等實現的是二進位制協議。放在netty中也是一樣,實現一套codec即可(繼承Decoder或Encoder系列)。netty預設實現了dns、haproxy、http、http2、memcache、mqtt、redis、smtp、socks、stomp、xml等協議,可以說是很全了,直接拿來用很爽。
一個可能的產品結構會是這樣的,對外提供一致的外觀,核心儲存卻不同:
文字協議在除錯起來是比較直觀和容易的,但安全性欠佳;而二進位制協議就需要依賴日誌、wireshark等其他方式進行分析,增加了開發難度。傳說中的粘包拆包,就在這裡處理。而造成粘包的原因,主要是由於緩衝區的介入,所以需要約定雙方的傳輸概要等資訊,netty在一定程度上解決了這個問題。每一個想要開發網路應用的同學,心裡都埋了一顆重新設計協議的夢想種子。但協議的設計可以說是非常困難了,要深耕相應業務,還要考慮其擴充套件性。如沒有特別的必要,建議使用現有的協議。
連線管理功能
做Netty開發,連線管理功能是非常重要的。通訊質量、系統狀態,以及一些黑科技功能,都是依賴連線管理功能。
無論是作為服務端還是客戶端,netty在建立連線之後,都會得到一個叫做Channel
的物件。我們所要做的,就是對它的管理,我習慣給它起名叫做ConnectionManager
。
管理類會通過快取一些記憶體物件,用來統計執行中的資料。比如面向連線的功能:包傳送、接收數量;包傳送、接收速率;錯誤計數;連線重連次數;呼叫延遲;連線狀態等。這會頻繁用到java中concurrent包
的相關類,往往也是bug集中地。
但我們還需要更多,管理類會給予每個連線更多的功能。比如,連線建立後,想要預熱一些功能,那這些狀態就可以參與路由的決策。通常情況下,將使用者或其他元資訊也attach到連線上,能夠多維度的根據條件篩選一些連線,進行批量操作,比如灰度、過載保護等,是一個非常重要的功能。
管理後臺可以看到每個連線的資訊,篩選到一個或多個連線後,能夠開啟對這些連線的流量錄製、資訊監控、斷點除錯,你能體驗到掌控一切的感覺。
管理功能還能夠看到系統的整個執行狀態,及時調整負載均衡策略;同時對擴容、縮容提供資料依據。
心跳檢測
應用協議層的心跳是必須的,它和tcp keepalive是完全不同的概念。
應用層協議層的心跳檢測的是連線雙方的存活性,兼而連線質量,而keepalive
檢測的是連線本身的存活性。而且後者的超時時間預設過長,完全不能適應現代的網路環境。
GCM
等。保活機制會在不同的應用場景進行動態的切換,比如程式喚起和在後臺,輪訓的策略是不一樣的。
Netty內建通過增加IdleStateHandler
產生IDLE
事件進行便捷的心跳控制。你要處理的,就是心跳超時的邏輯,比如延遲重連。但它的輪訓時間是固定的,無法動態修改,高階功能需要自己定製。
在一些客戶端比如Android,頻繁心跳的喚起會浪費大量的網路和電量,它的心跳策略會更加複雜一些。
邊界
優雅退出機制
Java的優雅停機通常通過註冊JDK ShutdownHook來實現。
Runtime.getRuntime().addShutdownHook();
複製程式碼
一般通過kill -15
進行java程式的關閉,以便在程式死亡之前進行一些清理工作。
注意:kill -9 會立馬殺死程式,不給遺言的機會,比較危險。
雖然netty做了很多優雅退出的工作,通過EventLoopGroup
的shutdownGracefully
方法對nio進行了一些狀態設定,但在很多情況下,這還不夠多。它只負責單機環境的優雅關閉。
流量可能還會通過外層的路由持續進入,造成無效請求。我的通常做法是首先在外層路由進行一次本地例項的摘除,把流量截斷,然後再進行netty本身的優雅關閉。這種設計非常簡單,即使沒有重試機制也會執行的很好,前提是在路由層需要提前暴露相關介面。
異常處理功能
netty由於其非同步化的開發方式,以及其事件機制,在異常處理方面就顯得異常重要。為了保證連線的高可靠性,許多異常需要靜悄悄的忽略,或者在使用者態沒有感知。
netty的異常會通過pipeline進行傳播,所以在任何一層進行處理都是可行的,但程式設計習慣上,習慣性拋到最外層集中處理。
為了最大限度的區別異常資訊,通常會定義大量的異常類,不同的錯誤會丟擲不同的異常。發生異常後,可以根據不同的型別選擇斷線重連(比如一些二進位制協議的編解碼紊亂問題),或者排程到其他節點。
功能限制
指令模式
網路應用就該幹網路應用的事,任何通訊都是昂貴的。在《Linux之《荒島餘生》(五)網路篇》中,我們談到百萬連線的伺服器,廣播一個1kb訊息,就需要1000M的頻寬,所以並不是什麼都可以放在網路應用裡的。
一個大型網路應用的合理的思路就是值傳送相關指令
。客戶端在收到指令以後,通過其他方式,比如http,進行大型檔案到獲取。很多IM的設計思路就是如此。
指令模式還會讓通訊系統的擴充套件性和穩定性得到保證。增加指令可以是配置式的,立即生效,服務端不需要編碼重啟。
穩定性保證
網路應用的流量一般都是非常大的,並不適合全量日誌的開啟。應用應該只關注主要事件的日誌,關注異常情況下的處理流程,日誌要列印有度。
網路應用也不適合呼叫其他緩慢的api,或者任何阻塞I/O的介面。一些實時的事件,也不應該通過呼叫介面吐出資料,可以走高速mq等其他非同步通道。
快取可能是網路應用裡用的最多的元件。jvm內快取可以儲存一些單機的統計資料,redis等儲存一些全域性性的統計和中間態資料。
網路應用中會大量使用redis、kv、高吞吐的mq,用來快速響應使用者請求。總之,儘量保持通訊層的清爽,你會省去很多憂慮。單機支援100萬連線的Linux配置
單機支援100萬連線是可行的,但頻寬問題會成為顯著的瓶頸。啟用壓縮的二進位制協議會節省部分頻寬,但開發難度增加。
和《LWP程式資源耗盡,Resource temporarily unavailable》中提到的ES配置一樣,優化都有類似的思路。這份配置,可以節省你幾天的時間,請收下!
作業系統優化
更改程式最大檔案控制程式碼數
ulimit -n 1048576
複製程式碼
修改單個程式可分配的最大檔案數
echo 2097152 > /proc/sys/fs/nr_open
複製程式碼
修改/etc/security/limits.conf檔案
* soft nofile 1048576
* hard nofile 1048576
* soft nproc unlimited
root soft nproc unlimited
複製程式碼
記得清理掉/etc/security/limits.d/*下的配置
網路優化
開啟/etc/sysctl.conf
,新增配置
然後執行,使用sysctl
生效
#單個程式可分配的最大檔案數
fs.nr_open=2097152
#系統最大檔案控制程式碼數
fs.file-max = 1048576
#backlog 設定
net.core.somaxconn=32768
net.ipv4.tcp_max_syn_backlog=16384
net.core.netdev_max_backlog=16384
#可用知名埠範圍配置
net.ipv4.ip_local_port_range='1000 65535'
#TCP Socket 讀寫 Buffer 設定
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.optmem_max=16777216
net.ipv4.tcp_rmem='1024 4096 16777216'
net.ipv4.tcp_wmem='1024 4096 16777216'
#TCP 連線追蹤設定
net.nf_conntrack_max=1000000
net.netfilter.nf_conntrack_max=1000000
net.netfilter.nf_conntrack_tcp_timeout_time_wait=30
#TIME-WAIT Socket 最大數量、回收與重用設定
net.ipv4.tcp_max_tw_buckets=1048576
# FIN-WAIT-2 Socket 超時設定
net.ipv4.tcp_fin_timeout = 15
複製程式碼
總結
netty的開發工作並不集中在netty本身,更多體現在保證服務的高可靠性和穩定性上。同時有大量的工作集中在監控和除錯,減少bug修復的成本。
深入瞭解netty是在系統遇到疑難問題時能夠深入挖掘進行排查,或者對苛刻的效能進行提升。但對於廣大應用開發者來說,netty的上手成本小,死挖底層並不會產生太多收益。
它只是個工具,你還能讓它怎樣啊。 0.jpeg