摘要：比如面向連接的功能包發(fā)送接收數(shù)量包發(fā)送接收速率錯(cuò)誤計(jì)數(shù)連接重連次數(shù)調(diào)用延遲連接狀態(tài)等。你要處理的，就是心跳超時(shí)的邏輯，比如延遲重連。發(fā)生異常后，可以根據(jù)不同的類型選擇斷線重連比如一些二進(jìn)制協(xié)議的編解碼紊亂問(wèn)題，或者調(diào)度到其他節(jié)點(diǎn)。

在java界，netty無(wú)疑是開(kāi)發(fā)網(wǎng)絡(luò)應(yīng)用的拿手菜。你不需要太多關(guān)注復(fù)雜的nio模型和底層網(wǎng)絡(luò)的細(xì)節(jié)，使用其豐富的接口，可以很容易的實(shí)現(xiàn)復(fù)雜的通訊功能。

和golang的網(wǎng)絡(luò)模塊相比，netty還是太過(guò)臃腫。不過(guò)java類框架就是這樣，屬于那種離了IDE就無(wú)法存活的編碼語(yǔ)言。

最新的netty版本將模塊分的非常細(xì)，如果不清楚每個(gè)模塊都有什么內(nèi)容，直接使用netty-all即可。

單純從使用方面來(lái)說(shuō)，netty是非常簡(jiǎn)單的，掌握ByteBuf、Channel、Pipeline、Event模型等，就可以進(jìn)行開(kāi)發(fā)了。你會(huì)發(fā)現(xiàn)面試netty相關(guān)知識(shí)，沒(méi)得聊。但Netty與其他開(kāi)發(fā)模式很大不同，最主要的就是其異步化。異步化造成的后果就是編程模型的不同，同時(shí)有調(diào)試上的困難，對(duì)編碼的要求比較高，因?yàn)閎ug的代價(jià)與業(yè)務(wù)代碼的bug代價(jià)不可同日而語(yǔ)。

但從項(xiàng)目來(lái)說(shuō)，麻雀雖小五臟俱全，從業(yè)務(wù)層到服務(wù)網(wǎng)關(guān)，以及各種技術(shù)保障，包括監(jiān)控和配置，都是需要考慮的因素。netty本身占比很小。

本文將說(shuō)明使用netty開(kāi)發(fā)，都關(guān)注哪些通用的內(nèi)容，然后附上單機(jī)支持100w連接的linux配置。本文并不關(guān)注netty的基礎(chǔ)知識(shí)。

網(wǎng)絡(luò)開(kāi)發(fā)中最重要的就是其通訊格式，協(xié)議。我們常見(jiàn)的protobuf、json、avro、mqtt等，都屬于此列。協(xié)議有語(yǔ)法、語(yǔ)義、時(shí)序三個(gè)要素。

我見(jiàn)過(guò)很多中間件應(yīng)用，采用的是redis協(xié)議，而后端落地的卻是mysql；也見(jiàn)過(guò)更多的采用mysql協(xié)議實(shí)現(xiàn)的各種自定義存儲(chǔ)系統(tǒng)，比如proxy端的分庫(kù)分表中間件、tidb等。

我們常用的redis，使用的是文本協(xié)議；mysql等實(shí)現(xiàn)的是二進(jìn)制協(xié)議。放在netty中也是一樣，實(shí)現(xiàn)一套codec即可(繼承Decoder或Encoder系列)。netty默認(rèn)實(shí)現(xiàn)了dns、haproxy、http、http2、memcache、mqtt、redis、smtp、socks、stomp、xml等協(xié)議，可以說(shuō)是很全了，直接拿來(lái)用很爽。

一個(gè)可能的產(chǎn)品結(jié)構(gòu)會(huì)是這樣的，對(duì)外提供一致的外觀，核心存儲(chǔ)卻不同：

文本協(xié)議在調(diào)試起來(lái)是比較直觀和容易的，但安全性欠佳；而二進(jìn)制協(xié)議就需要依賴日志、wireshark等其他方式進(jìn)行分析，增加了開(kāi)發(fā)難度。傳說(shuō)中的粘包拆包，就在這里處理。而造成粘包的原因，主要是由于緩沖區(qū)的介入，所以需要約定雙方的傳輸概要等信息，netty在一定程度上解決了這個(gè)問(wèn)題。

每一個(gè)想要開(kāi)發(fā)網(wǎng)絡(luò)應(yīng)用的同學(xué)，心里都埋了一顆重新設(shè)計(jì)協(xié)議的夢(mèng)想種子。但協(xié)議的設(shè)計(jì)可以說(shuō)是非常困難了，要深耕相應(yīng)業(yè)務(wù)，還要考慮其擴(kuò)展性。如沒(méi)有特別的必要，建議使用現(xiàn)有的協(xié)議。

做Netty開(kāi)發(fā)，連接管理功能是非常重要的。通信質(zhì)量、系統(tǒng)狀態(tài)，以及一些黑科技功能，都是依賴連接管理功能。
無(wú)論是作為服務(wù)端還是客戶端，netty在創(chuàng)建連接之后，都會(huì)得到一個(gè)叫做Channel的對(duì)象。我們所要做的，就是對(duì)它的管理，我習(xí)慣給它起名叫做ConnectionManager。

管理類會(huì)通過(guò)緩存一些內(nèi)存對(duì)象，用來(lái)統(tǒng)計(jì)運(yùn)行中的數(shù)據(jù)。比如面向連接的功能：包發(fā)送、接收數(shù)量；包發(fā)送、接收速率；錯(cuò)誤計(jì)數(shù)；連接重連次數(shù)；調(diào)用延遲；連接狀態(tài)等。這會(huì)頻繁用到j(luò)ava中concurrent包的相關(guān)類，往往也是bug集中地。

但我們還需要更多，管理類會(huì)給予每個(gè)連接更多的功能。比如，連接創(chuàng)建后，想要預(yù)熱一些功能，那這些狀態(tài)就可以參與路由的決策。通常情況下，將用戶或其他元信息也attach到連接上，能夠多維度的根據(jù)條件篩選一些連接，進(jìn)行批量操作，比如灰度、過(guò)載保護(hù)等，是一個(gè)非常重要的功能。

管理后臺(tái)可以看到每個(gè)連接的信息，篩選到一個(gè)或多個(gè)連接后，能夠開(kāi)啟對(duì)這些連接的流量錄制、信息監(jiān)控、斷點(diǎn)調(diào)試，你能體驗(yàn)到掌控一切的感覺(jué)。

管理功能還能夠看到系統(tǒng)的整個(gè)運(yùn)行狀態(tài)，及時(shí)調(diào)整負(fù)載均衡策略；同時(shí)對(duì)擴(kuò)容、縮容提供數(shù)據(jù)依據(jù)。

應(yīng)用協(xié)議層的心跳是必須的，它和tcp keepalive是完全不同的概念。

應(yīng)用層協(xié)議層的心跳檢測(cè)的是連接雙方的存活性，兼而連接質(zhì)量，而keepalive檢測(cè)的是連接本身的存活性。而且后者的超時(shí)時(shí)間默認(rèn)過(guò)長(zhǎng)，完全不能適應(yīng)現(xiàn)代的網(wǎng)絡(luò)環(huán)境。

心跳就是靠輪訓(xùn)，無(wú)論是服務(wù)端，還是客戶端比如GCM等。保活機(jī)制會(huì)在不同的應(yīng)用場(chǎng)景進(jìn)行動(dòng)態(tài)的切換，比如程序喚起和在后臺(tái)，輪訓(xùn)的策略是不一樣的。

Netty內(nèi)置通過(guò)增加IdleStateHandler產(chǎn)生IDLE事件進(jìn)行便捷的心跳控制。你要處理的，就是心跳超時(shí)的邏輯，比如延遲重連。但它的輪訓(xùn)時(shí)間是固定的，無(wú)法動(dòng)態(tài)修改，高級(jí)功能需要自己定制。

在一些客戶端比如Android，頻繁心跳的喚起會(huì)浪費(fèi)大量的網(wǎng)絡(luò)和電量，它的心跳策略會(huì)更加復(fù)雜一些。

Java的優(yōu)雅停機(jī)通常通過(guò)注冊(cè)JDK ShutdownHook來(lái)實(shí)現(xiàn)。

Runtime.getRuntime().addShutdownHook();

一般通過(guò)kill -15進(jìn)行java進(jìn)程的關(guān)閉，以便在進(jìn)程死亡之前進(jìn)行一些清理工作。

注意：kill -9 會(huì)立馬殺死進(jìn)程，不給遺言的機(jī)會(huì)，比較危險(xiǎn)。

雖然netty做了很多優(yōu)雅退出的工作，通過(guò)EventLoopGroup的shutdownGracefully方法對(duì)nio進(jìn)行了一些狀態(tài)設(shè)置，但在很多情況下，這還不夠多。它只負(fù)責(zé)單機(jī)環(huán)境的優(yōu)雅關(guān)閉。

流量可能還會(huì)通過(guò)外層的路由持續(xù)進(jìn)入，造成無(wú)效請(qǐng)求。我的通常做法是首先在外層路由進(jìn)行一次本地實(shí)例的摘除，把流量截?cái)啵缓笤龠M(jìn)行netty本身的優(yōu)雅關(guān)閉。這種設(shè)計(jì)非常簡(jiǎn)單，即使沒(méi)有重試機(jī)制也會(huì)運(yùn)行的很好，前提是在路由層需要提前暴露相關(guān)接口。

netty由于其異步化的開(kāi)發(fā)方式，以及其事件機(jī)制，在異常處理方面就顯得異常重要。為了保證連接的高可靠性，許多異常需要靜悄悄的忽略，或者在用戶態(tài)沒(méi)有感知。

netty的異常會(huì)通過(guò)pipeline進(jìn)行傳播，所以在任何一層進(jìn)行處理都是可行的，但編程習(xí)慣上，習(xí)慣性拋到最外層集中處理。

為了最大限度的區(qū)別異常信息，通常會(huì)定義大量的異常類，不同的錯(cuò)誤會(huì)拋出不同的異常。發(fā)生異常后，可以根據(jù)不同的類型選擇斷線重連（比如一些二進(jìn)制協(xié)議的編解碼紊亂問(wèn)題)，或者調(diào)度到其他節(jié)點(diǎn)。

網(wǎng)絡(luò)應(yīng)用就該干網(wǎng)絡(luò)應(yīng)用的事，任何通訊都是昂貴的。在《Linux之《荒島余生》（五）網(wǎng)絡(luò)篇》中，我們談到百萬(wàn)連接的服務(wù)器，廣播一個(gè)1kb消息，就需要1000M的帶寬，所以并不是什么都可以放在網(wǎng)絡(luò)應(yīng)用里的。

一個(gè)大型網(wǎng)絡(luò)應(yīng)用的合理的思路就是值發(fā)送相關(guān)指令。客戶端在收到指令以后，通過(guò)其他方式，比如http，進(jìn)行大型文件到獲取。很多IM的設(shè)計(jì)思路就是如此。

指令模式還會(huì)讓通訊系統(tǒng)的擴(kuò)展性和穩(wěn)定性得到保證。增加指令可以是配置式的，立即生效，服務(wù)端不需要編碼重啟。

網(wǎng)絡(luò)應(yīng)用的流量一般都是非常大的，并不適合全量日志的開(kāi)啟。應(yīng)用應(yīng)該只關(guān)注主要事件的日志，關(guān)注異常情況下的處理流程，日志要打印有度。

網(wǎng)絡(luò)應(yīng)用也不適合調(diào)用其他緩慢的api，或者任何阻塞I/O的接口。一些實(shí)時(shí)的事件，也不應(yīng)該通過(guò)調(diào)用接口吐出數(shù)據(jù)，可以走高速mq等其他異步通道。

緩存可能是網(wǎng)絡(luò)應(yīng)用里用的最多的組件。jvm內(nèi)緩存可以存儲(chǔ)一些單機(jī)的統(tǒng)計(jì)數(shù)據(jù)，redis等存儲(chǔ)一些全局性的統(tǒng)計(jì)和中間態(tài)數(shù)據(jù)。

網(wǎng)絡(luò)應(yīng)用中會(huì)大量使用redis、kv、高吞吐的mq，用來(lái)快速響應(yīng)用戶請(qǐng)求。總之，盡量保持通訊層的清爽，你會(huì)省去很多憂慮。

單機(jī)支持100萬(wàn)連接是可行的，但帶寬問(wèn)題會(huì)成為顯著的瓶頸。啟用壓縮的二進(jìn)制協(xié)議會(huì)節(jié)省部分帶寬，但開(kāi)發(fā)難度增加。

和《LWP進(jìn)程資源耗盡，Resource temporarily unavailable》中提到的ES配置一樣，優(yōu)化都有類似的思路。這份配置，可以節(jié)省你幾天的時(shí)間，請(qǐng)收下！

更改進(jìn)程最大文件句柄數(shù)

ulimit -n 1048576

修改單個(gè)進(jìn)程可分配的最大文件數(shù)

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/*下的配置

打開(kāi)/etc/sysctl.conf，添加配置
然后執(zhí)行，使用sysctl生效

#單個(gè)進(jìn)程可分配的最大文件數(shù)
fs.nr_open=2097152

#系統(tǒng)最大文件句柄數(shù)
fs.file-max = 1048576

#backlog 設(shè)置
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 讀寫(xiě) Buffer 設(shè)置
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 連接追蹤設(shè)置
net.nf_conntrack_max=1000000
net.netfilter.nf_conntrack_max=1000000
net.netfilter.nf_conntrack_tcp_timeout_time_wait=30

#TIME-WAIT Socket 最大數(shù)量、回收與重用設(shè)置
net.ipv4.tcp_max_tw_buckets=1048576

# FIN-WAIT-2 Socket 超時(shí)設(shè)置
net.ipv4.tcp_fin_timeout = 15

netty的開(kāi)發(fā)工作并不集中在netty本身，更多體現(xiàn)在保證服務(wù)的高可靠性和穩(wěn)定性上。同時(shí)有大量的工作集中在監(jiān)控和調(diào)試，減少bug修復(fù)的成本。

深入了解netty是在系統(tǒng)遇到疑難問(wèn)題時(shí)能夠深入挖掘進(jìn)行排查，或者對(duì)苛刻的性能進(jìn)行提升。但對(duì)于廣大應(yīng)用開(kāi)發(fā)者來(lái)說(shuō)，netty的上手成本小，死挖底層并不會(huì)產(chǎn)生太多收益。

它只是個(gè)工具，你還能讓它怎樣啊。
0.jpeg