絡(luò)編程新選擇：輕量AIO框架smart-socket的實(shí)戰(zhàn)解析)
做 Java 服務(wù)端的人十有八九會(huì)在某個(gè)階段撞上網(wǎng)絡(luò)通信這堵墻。用原生 Socket 寫 demo 很爽但連接一多就痛苦聽(tīng)過(guò) Netty 的大名打開(kāi)文檔又是一片汪洋。其實(shí)很多項(xiàng)目并沒(méi)有那么復(fù)雜的網(wǎng)絡(luò)訴求你只是想把消息從 A 點(diǎn)送到 B 點(diǎn)然后處理一下業(yè)務(wù)。smart-socket 就看準(zhǔn)了這個(gè)空子——一套基于 Java AIO 的輕量通信框架核心接口只有兩個(gè)一個(gè)管協(xié)議編解碼一個(gè)管業(yè)務(wù)消息處理。我第一次看到這個(gè)項(xiàng)目時(shí)嘀咕過(guò)這也太簡(jiǎn)化了吧真跑起來(lái)一個(gè) Demo 之后反而覺(jué)得這種克制才是框架該有的樣子。這篇文章就聊聊它的設(shè)計(jì)思路、上手方式和我在實(shí)際使用中踩過(guò)的坑。1. smart-socket 解決的不是新問(wèn)題而是老問(wèn)題的體感問(wèn)題1.1 三種原生姿勢(shì)BIO、NIO、AIOJava 天生提供了三種網(wǎng)絡(luò)編程姿勢(shì)首先是最原始的 BIOBlocking IO。ServerSocket配多線程每來(lái)一個(gè)客戶端就 new 一個(gè)線程代碼非常直白accept 一個(gè)連接然后 read 等數(shù)據(jù)業(yè)務(wù)處理完寫回。問(wèn)題是連接數(shù)一上來(lái)線程數(shù)跟著爆炸。一個(gè)線程默認(rèn)棧大小 1MB一萬(wàn)個(gè)連接就是 10GB 級(jí)別的內(nèi)存開(kāi)銷這還沒(méi)算線程切換的 CPU 成本。所以 BIO 只適合幾十個(gè)連接的教學(xué)級(jí) demo生產(chǎn)環(huán)境基本不敢用。然后是 NIONon-blocking IO也就是Selector多路復(fù)用。一個(gè)線程可以同時(shí)管理成千上萬(wàn)個(gè)通道通過(guò)SelectionKey感知可讀、可寫事件。思路沒(méi)問(wèn)題但代碼寫起來(lái)很考驗(yàn)人要處理ByteBuffer的游標(biāo)、翻轉(zhuǎn)、compact還要自己維護(hù)每個(gè)連接的消息狀態(tài)尤其是半包粘包問(wèn)題稍不注意就是線上事故。這就是為什么后來(lái) Netty 能火——它把 NIO 的復(fù)雜度包裝得很好。AIOAsynchronous IO是 JDK 1.7 才正式提供的。它的思路更進(jìn)一步你發(fā)起一個(gè)異步讀然后給一個(gè)回調(diào)操作系統(tǒng)完成讀之后自動(dòng)調(diào)用你的回調(diào)。理論上開(kāi)發(fā)者不用再反復(fù)檢查事件狀態(tài)代碼可以寫得像順序執(zhí)行一樣自然。但 AIO 的 API 并不算友好AsynchronousSocketChannel配合CompletionHandler用起來(lái)有不少細(xì)節(jié)而且這么多年過(guò)去了國(guó)內(nèi)生態(tài)里真正把 Java AIO 封裝到能直接用于生產(chǎn)的框架并不多。smart-socket 比較早地看到了這個(gè)空白。1.2 Netty 雖好但有些項(xiàng)目背不動(dòng)一說(shuō) Java 網(wǎng)絡(luò)框架繞不開(kāi) Netty。Netty 確實(shí)強(qiáng)大Pipeline、EventLoop、ByteBuf、各種編解碼器幾乎覆蓋了你能想到的一切場(chǎng)景。但它的問(wèn)題也很現(xiàn)實(shí)學(xué)習(xí)成本高。你需要理解責(zé)任鏈機(jī)制知道ChannelHandler的生命周期還得熟悉 Netty 自己那套緩沖區(qū) API。即便只是寫一個(gè)簡(jiǎn)單的 TCP 客戶端也要配置bossGroup、workerGroup、NioEventLoopGroup代碼結(jié)構(gòu)天然比兩個(gè)接口要復(fù)雜。更關(guān)鍵的是依賴。新版 Netty 拆成了很多模塊引入一個(gè)完整的傳輸層可能要連帶好幾個(gè)包雖然 Maven 會(huì)自動(dòng)搞定但對(duì)于一些追求最小依賴、或者還在用老舊項(xiàng)目結(jié)構(gòu)的人來(lái)說(shuō)也是一種心理負(fù)擔(dān)。另外Netty 的抽象層級(jí)很高很多小項(xiàng)目根本用不到它的高級(jí)特性卻要為這些特性付出理解和排查問(wèn)題的成本。還有一部分團(tuán)隊(duì)寧愿自己寫 NIO 封裝也不上 Netty原因倒不是 Netty 不好而是不上框架意味著整個(gè)代碼庫(kù)自己可控。但自己封裝 NIO 的坑前面已經(jīng)說(shuō)過(guò)緩沖區(qū)管理、事件注冊(cè)、連接生命周期、寫半包每一個(gè)細(xì)節(jié)都要小心。與其這樣不如找一個(gè)輕量級(jí)的輪子把核心邏輯控制在自己手里。1.3 為什么偏偏選了 AIO回到 smart-socket 的選擇為什么基于 AIO而不是繼續(xù)站在 Netty 那條 NIO 賽道上我的理解是作者的目標(biāo)不是做一個(gè)大而全的通用網(wǎng)絡(luò)框架而是做一個(gè)夠用、順手、能快速落地的通信框架。AIO 在這方面的優(yōu)勢(shì)很明顯回調(diào)模型比事件循環(huán)更好理解代碼寫起來(lái)更像同步邏輯新手也能很快跟下來(lái)。從性能角度講Java AIO 在 Linux 上的底層實(shí)現(xiàn)其實(shí)還是 epoll 加線程池模擬天然會(huì)比純 NIO 多一層線程調(diào)度開(kāi)銷因此單機(jī)極限性能不一定壓得過(guò)極致調(diào)優(yōu)的 Netty。但 smart-socket 的定位本來(lái)就不是為了刷百萬(wàn)并發(fā)而是為了覆蓋幾千到幾萬(wàn)連接、消息量中等、開(kāi)發(fā)效率優(yōu)先的常見(jiàn)場(chǎng)景。在這個(gè)區(qū)間里AIO 無(wú)論是代碼可讀性還是維護(hù)成本都有它的獨(dú)特價(jià)值。另外AIO 有真正的異步 IO 內(nèi)核支持。在 Windows 上對(duì)應(yīng) IOCP是真正的異步完成端口在 Linux 上雖然是模擬但結(jié)合內(nèi)存復(fù)用和合理線程模型表現(xiàn)也很穩(wěn)。尤其在做遠(yuǎn)程控制、物聯(lián)網(wǎng)接入、小規(guī)模即時(shí)通信這類場(chǎng)景時(shí)感知非常明顯代碼簡(jiǎn)單了出問(wèn)題的地方也就少了。2. 兩個(gè)接口完成通信核心抽象值得學(xué)2.1 Protocol管好字節(jié)流和對(duì)象的邊界smart-socket 的核心抽象就是兩個(gè)接口Protocol是第一個(gè)。它定義了一條消息在網(wǎng)絡(luò)上怎么變成 Java 對(duì)象以及 Java 對(duì)象怎么變成要發(fā)送的字節(jié)流。為什么需要它因?yàn)?TCP 是面向字節(jié)流的底層的ByteBuffer里沒(méi)有消息的概念你必須自己決定消息從哪里開(kāi)始、到哪里結(jié)束?？唇涌诘姆椒ň兔靼琢恕ecode方法接收一個(gè)ByteBuffer返回一個(gè)解碼后的對(duì)象如果數(shù)據(jù)不夠組成一條完整消息就返回null框架會(huì)把剩余數(shù)據(jù)留著繼續(xù)等后續(xù)字節(jié)。encode方法正好相反把業(yè)務(wù)對(duì)象轉(zhuǎn)換成byte[]框架負(fù)責(zé)發(fā)送。這層抽象把協(xié)議和業(yè)務(wù)徹底分開(kāi)了想換協(xié)議格式的時(shí)候只需要換一個(gè)Protocol實(shí)現(xiàn)類。以最常見(jiàn)的換行符協(xié)議為例客戶端發(fā)送的每條消息以\n結(jié)尾服務(wù)端收到數(shù)據(jù)后需要掃描緩沖區(qū)里的換行符。找到就解析出一條消息并把讀過(guò)的數(shù)據(jù)消費(fèi)掉沒(méi)找到就返回null等待更多數(shù)據(jù)。這個(gè)邏輯放在decode里非常自然網(wǎng)絡(luò)包怎么切、粘包怎么處理都集中在一個(gè)類里而不是散落在業(yè)務(wù)代碼中。2.2 MessageProcessor業(yè)務(wù)邏輯的家MessageProcessor是第二個(gè)核心接口也是業(yè)務(wù)代碼主要待的地方。它有兩個(gè)方法process負(fù)責(zé)處理解碼后的完整消息stateEvent負(fù)責(zé)監(jiān)聽(tīng)連接狀態(tài)變化。process的參數(shù)里面有一個(gè)AioSession這是 smart-socket 抽象出來(lái)的會(huì)話對(duì)象可以用來(lái)向這個(gè)連接寫回?cái)?shù)據(jù)也可以主動(dòng)關(guān)閉連接。stateEvent這個(gè)設(shè)計(jì)容易被忽略但實(shí)際價(jià)值很高。連接何時(shí)建立、何時(shí)關(guān)閉、讀寫異常從哪里拋出都會(huì)通過(guò)狀態(tài)機(jī)回調(diào)到這個(gè)方法里。你可以在里面做資源清理、日志記錄也可以針對(duì)某些異常狀態(tài)做重連。相比 Netty 里事件和異常分散在各種handler方法中smart-socket 用一個(gè)方法把它收斂起來(lái)反而更容易維護(hù)。這兩個(gè)接口合起來(lái)覆蓋了通信框架最核心的兩件事數(shù)據(jù)怎么解析、解析完怎么處理。連接怎么建立、線程怎么調(diào)度、緩沖區(qū)怎么復(fù)用這些細(xì)節(jié)框架全包了。我第一次寫的時(shí)候最大的感受是終于不用在每個(gè)類里都關(guān)心ByteBuffer的生命周期了。2.3 最少代碼實(shí)現(xiàn)一個(gè)自定義協(xié)議舉一個(gè)最小可用的例子。假設(shè)協(xié)議很簡(jiǎn)單一行字符串以換行符分隔。先寫Protocol實(shí)現(xiàn)public class LineProtocol implements ProtocolString { Override public byte[] encode(String msg, AioSession session) { return (msg \n).getBytes(StandardCharsets.UTF_8); } Override public String decode(ByteBuffer buffer, AioSession session) { // 在緩沖區(qū)里找換行符 for (int i buffer.position(); i buffer.limit(); i) { if (buffer.get(i) \n) { int limit buffer.limit(); byte[] bytes new byte[i - buffer.position()]; buffer.get(bytes); buffer.get(); // 消費(fèi)換行符 buffer.limit(limit); return new String(bytes, StandardCharsets.UTF_8); } } return null; // 數(shù)據(jù)不完整繼續(xù)等待 } }再寫業(yè)務(wù)處理類public class EchoProcessor implements MessageProcessorString { Override public void process(AioSession session, String msg) { // 收到消息原樣返回 session.write(echo: msg); } Override public void stateEvent(AioSession session, StateMachine state, Throwable throwable) { // 可以在這里打印狀態(tài)日志 System.out.println(state: state); } }這樣就完成了核心邏輯。不需要額外繼承什么ChannelInitializer也不需要配置ChannelPipeline一個(gè)協(xié)議類一個(gè)業(yè)務(wù)類剩下的交給框架。2.4 輕的本質(zhì)框架只做連接管理對(duì)比同樣做 TCP 通信的另一個(gè)方案你會(huì)更明白 smart-socket 的輕在哪里。Netty 里有ChannelInboundHandler、ChannelOutboundHandler、MessageToMessageDecoder、LengthFieldBasedFrameDecoder等等每一個(gè)概念都有存在的理由但你真的只需要回顯一行字符串的時(shí)候這些概念都是理解成本。smart-socket 的哲學(xué)是框架負(fù)責(zé)連接生命周期和底層 IO你負(fù)責(zé)協(xié)議和業(yè)務(wù)。它沒(méi)有把功能做大而是把連接管理、會(huì)話保持、消息回調(diào)這些公共部分做好把最大的靈活性留給Protocol和MessageProcessor兩個(gè)接口。實(shí)際用下來(lái)這個(gè)抽象非常適合中小項(xiàng)目也很適合團(tuán)隊(duì)里新同學(xué)快速上手。3. 3 分鐘跑起一個(gè) Demo服務(wù)端與客戶端完整代碼3.1 引入依賴與版本選擇在 Maven 項(xiàng)目里使用 smart-socket 很簡(jiǎn)單。舊版 1.x 系列在中央倉(cāng)庫(kù)的坐標(biāo)是org.smartboot.socket:smart-socket引入核心包后就能直接用。如果是新項(xiàng)目我更建議先去 GitHub 倉(cāng)庫(kù)看一眼當(dāng)前最新的 release 版本因?yàn)?smart-socket 2.0 之后做過(guò)模塊化重構(gòu)包名和入口類都有調(diào)整直接照抄老博客的代碼可能會(huì)編譯不過(guò)。這里我們以社區(qū)常見(jiàn)的 1.x API 為例代碼結(jié)構(gòu)是dependency groupIdorg.smartboot.socket/groupId artifactIdsmart-socket/artifactId version1.5.5/version /dependency如果你用的是新版 2.x入口類應(yīng)該換成SmartServer之類的名字但Protocol和MessageProcessor這兩個(gè)核心設(shè)計(jì)思路還是延續(xù)的。學(xué)習(xí)的時(shí)候先抓住接口版本差異只是外包裝問(wèn)題。3.2 服務(wù)端怎么啟動(dòng)用上一節(jié)寫的LineProtocol和EchoProcessor服務(wù)端啟動(dòng)只需要幾行代碼public class ServerDemo { public static void main(String[] args) { AioQuickServerString server new AioQuickServerString() .setHost(0.0.0.0) .setPort(8088) .setProtocol(new LineProtocol()) .setProcessor(new EchoProcessor()); server.start(); System.out.println(server started on 8088); } }這里的AioQuickServer是 1.x 里的服務(wù)端啟動(dòng)類鏈?zhǔn)秸{(diào)用非常順手。start()方法會(huì)啟動(dòng)底層線程組并開(kāi)始監(jiān)聽(tīng)端口。注意主線程在調(diào)用start()后不會(huì)阻塞如果你寫的是獨(dú)立程序需要在最后加一個(gè)CountDownLatch.await()或者Thread.sleep(Long.MAX_VALUE)否則程序會(huì)直接跑完退出。setHost這一步容易被忽略。不設(shè)置時(shí)默認(rèn)綁定本地所有網(wǎng)卡如果只想對(duì)某個(gè)內(nèi)網(wǎng) IP 提供服務(wù)可以顯式指定。端口選擇避開(kāi)常用服務(wù)端口比如 8080、3306 這些避免沖突。3.3 客戶端怎么連接客戶端代碼更簡(jiǎn)單除了啟動(dòng)類是AioQuickClient其他結(jié)構(gòu)幾乎一樣public class ClientDemo { public static void main(String[] args) throws Exception { AioQuickClientString client new AioQuickClientString() .setHost(127.0.0.1) .setPort(8088) .setProtocol(new LineProtocol()) .setProcessor(new EchoProcessor()); AioSession session client.start(); // 發(fā)送一條消息 session.write(hello smart-socket); System.out.println(send done); // 等待回調(diào)實(shí)際項(xiàng)目中可以用 CountDownLatch Thread.sleep(3000); client.shutdown(); } }client.start()會(huì)返回一個(gè)AioSession通過(guò)session.write()就可以向服務(wù)端發(fā)數(shù)據(jù)。write是異步的多次連續(xù)調(diào)用不需要顯式排隊(duì)框架內(nèi)部會(huì)處理寫半包和緩沖區(qū)排隊(duì)。這里讓線程睡 3 秒是為了等服務(wù)端回顯的echo: hello smart-socket被客戶端process收到并打印出來(lái)。3.4 運(yùn)行起來(lái)看現(xiàn)象先啟動(dòng)服務(wù)端再啟動(dòng)客戶端輸出大致是這樣的服務(wù)端: server started on 8088 state: NEW_SESSION state: ENABLE_READ 收到消息: hello smart-socket 客戶端: state: NEW_SESSION state: ENABLE_READ 收到消息: echo: hello smart-socket注意stateEvent里的NEW_SESSION和ENABLE_READ狀態(tài)這是 smart-socket 狀態(tài)機(jī)的一部分。NEW_SESSION表示連接剛剛建立ENABLE_READ表示框架開(kāi)始監(jiān)聽(tīng)這個(gè)連接的可讀事件。你可以在NEW_SESSION里做連接級(jí)初始化比如綁定用戶信息到AioSession的屬性里后面process時(shí)直接取出來(lái)用。整個(gè)流程走下來(lái)你會(huì)發(fā)現(xiàn)完全沒(méi)有接觸ByteBuffer的翻轉(zhuǎn)操作也沒(méi)有管理過(guò)線程池。協(xié)議解析、連接管理、消息分發(fā)都被框架吃掉了剩下的事情非常直覺(jué)。4. 扒一扒 AIO 原理回調(diào)到底是咋回事4.1 點(diǎn)餐叫號(hào)模型理解異步回調(diào)Java AIO 的異步回調(diào)模型用吃飯來(lái)類比最清楚。BIO 相當(dāng)于去柜臺(tái)點(diǎn)餐餐沒(méi)做好就站在柜臺(tái)前一直等直到拿到餐才走期間什么也干不了。NIO 相當(dāng)于每隔幾秒去窗口瞄一眼看餐好了沒(méi)有沒(méi)好在旁邊干點(diǎn)別的但你必須自己反復(fù)檢查。AIO 則像餐廳給的叫號(hào)器你點(diǎn)完單回座位該干嘛干嘛餐好了叫號(hào)器會(huì)響你聽(tīng)到聲音再去取餐。對(duì)應(yīng)到代碼里AsynchronousSocketChannel.read方法接收一個(gè)CompletionHandlerInteger, Object其中completed方法在數(shù)據(jù)讀完之后被回調(diào)failed方法在出錯(cuò)時(shí)被回調(diào)。相比 NIO 里你需要自己去注冊(cè)O(shè)P_READ事件然后在select返回后再逐一檢查哪些通道有數(shù)據(jù)AIO 把什么時(shí)候讀這個(gè)問(wèn)題委托給了操作系統(tǒng)和回調(diào)機(jī)制。理解了這個(gè)模型你就知道為什么 smart-socket 的抽象能這么干凈?？蚣艿讓訜o(wú)非是在completed回調(diào)里調(diào)用你傳入的Protocol.decode把解出來(lái)的對(duì)象再交給MessageProcessor.process。這中間的緩沖區(qū)和線程調(diào)度細(xì)節(jié)框架內(nèi)部已經(jīng)封裝好了。4.2 smart-socket 在 AIO 之上做了什么原生 Java AIO 只提供了最基礎(chǔ)的通道操作直接用還是挺費(fèi)勁的。比如每次read都新建一個(gè)ByteBuffer在高頻消息下會(huì)產(chǎn)生大量?jī)?nèi)存分配再比如部分操作系統(tǒng)對(duì) AIO 的支持細(xì)節(jié)不同需要做兼容。smart-socket 在底層做了幾件關(guān)鍵的事情。第一是緩沖區(qū)的復(fù)用。連接內(nèi)部維護(hù)一個(gè)讀緩沖數(shù)據(jù)到了之后滾動(dòng)讀取而不是每次讀都開(kāi)新內(nèi)存。這在高連接數(shù)場(chǎng)景下非常關(guān)鍵能明顯減少 GC 壓力。第二是寫隊(duì)列管理。異步寫消息時(shí)如果連續(xù)write框架會(huì)把待發(fā)送數(shù)據(jù)排隊(duì)避免覆蓋和丟包。第三是線程模型封裝。底層回調(diào)由 AIO 線程池觸發(fā)但業(yè)務(wù)處理可以選在不同的執(zhí)行策略下運(yùn)行避免回調(diào)線程被業(yè)務(wù)代碼阻塞。這些優(yōu)化并不復(fù)雜但如果你自己用原生 AIO 寫至少要多寫幾百行代碼而且未必能考慮周全。框架的價(jià)值就在這里好的框架不只是抽象得好還把 80% 的邊界情況都處理掉了。4.3 性能體感與邊界用 smart-socket 壓測(cè)中低并發(fā)下性能表現(xiàn)很驚艷。我這里舉一個(gè)偏經(jīng)驗(yàn)的參考在 4 核 8G 的云服務(wù)器上一個(gè)簡(jiǎn)單的字符串消息服務(wù)保持幾千個(gè)長(zhǎng)連接消息長(zhǎng)度幾百字節(jié)單進(jìn)程每秒鐘能處理的消息數(shù)是幾萬(wàn)到十幾萬(wàn)量級(jí)具體數(shù)值視消息大小和業(yè)務(wù)處理時(shí)間而定。這個(gè)量級(jí)覆蓋絕大多數(shù)內(nèi)部系統(tǒng)、物聯(lián)網(wǎng)上報(bào)、監(jiān)控?cái)?shù)據(jù)轉(zhuǎn)發(fā)等場(chǎng)景。但要認(rèn)清它的邊界。如果目標(biāo)是幾十萬(wàn)連接、百萬(wàn) QPS 的互聯(lián)網(wǎng)網(wǎng)關(guān)smart-socket 就不太合適了。不是框架本身有硬傷而是 Java AIO 在 Linux 上的實(shí)現(xiàn)有天然開(kāi)銷加上框架刻意保持輕量、不做復(fù)雜分流面對(duì)極端性能場(chǎng)景時(shí)不如 Netty 調(diào)優(yōu)空間大。選型時(shí)一定先問(wèn)自己的場(chǎng)景連接數(shù)多少消息頻率多高需要哪些高級(jí)特性如果答案都比較中等smart-socket 是個(gè)非常舒服的選擇。5. 實(shí)戰(zhàn)避坑這些坑我替你踩過(guò)了5.1 粘包/半包要從 Protocol 層解決TCP 是流協(xié)議沒(méi)有消息邊界。一次read可能讀到半條消息也可能一次讀到好幾條消息這就是半包和粘包。我在一開(kāi)始寫LineProtocol的時(shí)候只處理了緩沖區(qū)里有換行符的情況但沒(méi)有處理一個(gè)緩沖區(qū)里有多個(gè)換行符的情況結(jié)果第一條消息正常第二條消息帶著殘留數(shù)據(jù)一起被解析直接亂碼。正確做法很簡(jiǎn)單在decode里用while循環(huán)掃描能解幾條就解幾條。smart-socket 的decode返回null時(shí)表示等更多數(shù)據(jù)返回對(duì)象時(shí)表示這條解析完了所以可以循環(huán)調(diào)用直到返回null。另外生產(chǎn)環(huán)境不建議用換行符做協(xié)議因?yàn)樗鼰o(wú)法表達(dá)二進(jìn)制數(shù)據(jù)。更好的是長(zhǎng)度頭協(xié)議前 4 字節(jié)表示消息體長(zhǎng)度后面跟著消息體。decode里先判斷緩沖區(qū)有沒(méi)有 4 字節(jié)再判斷有沒(méi)有完整消息體缺啥等啥邏輯非常清晰。5.2 回調(diào)線程里別做慢操作另一個(gè)容易踩的坑是在process方法里直接做耗時(shí)的操作比如查數(shù)據(jù)庫(kù)、調(diào)第三方接口、做復(fù)雜計(jì)算。這些操作會(huì)阻塞 AIO 回調(diào)線程導(dǎo)致后續(xù)所有連接的讀寫事件都不能及時(shí)響應(yīng)嚴(yán)重時(shí)整個(gè)服務(wù)卡住。框架本身提供了異步處理的能力但默認(rèn)情況下process是在 IO 回調(diào)線程里執(zhí)行的。我自己習(xí)慣是process里只做消息投遞把真正耗時(shí)的業(yè)務(wù)邏輯提交到獨(dú)立的業(yè)務(wù)線程池或者丟進(jìn)ExecutorService后立刻返回。這樣 IO 線程始終輕快連接讀寫不會(huì)受業(yè)務(wù)抖動(dòng)影響。如果業(yè)務(wù)邏輯必須同步處理也可以考慮調(diào)大 AIO 線程池的線程數(shù)但這不是根本解法。能用異步隊(duì)列解耦就盡量解耦這也是所有高性能服務(wù)端框架的通用原則。5.3 心跳與掉線檢測(cè)要自己補(bǔ)smart-socket 的設(shè)計(jì)目標(biāo)是輕所以很多高級(jí)功能不會(huì)內(nèi)置。比如心跳框架本身不提供自動(dòng)發(fā)送心跳包的機(jī)制你需要在自己的協(xié)議里定義心跳消息然后定期發(fā)送。不做心跳的后果是長(zhǎng)時(shí)間沒(méi)有數(shù)據(jù)交互的連接可能被中間網(wǎng)絡(luò)設(shè)備悄然斷開(kāi)而兩端都不知道。解決方案通常有兩層。第一層客戶端定時(shí)發(fā)送心跳消息第二層服務(wù)端在stateEvent里監(jiān)聽(tīng)異常斷開(kāi)或者利用空閑檢測(cè)邏輯主動(dòng)清理無(wú)效連接。如果你不想寫太多代碼也可以在業(yè)務(wù)里實(shí)現(xiàn)一個(gè)簡(jiǎn)單的超時(shí)機(jī)制每次收到消息記錄一下時(shí)間定期掃描最近沒(méi)活躍的連接直接調(diào)用session.close()關(guān)閉。核心原則是別讓框架替你想當(dāng)然通信類的?；钬?zé)任最終還是落在應(yīng)用層。5.4 注意 1.x 到 2.x 的 API 變化smart-socket 不是那種多年 API 紋絲不動(dòng)的項(xiàng)目1.x 到 2.x 經(jīng)歷了比較大的重構(gòu)。如果你在搜索引擎里找到的是老博客直接復(fù)制代碼到新版本可能會(huì)遇到AioQuickServer找不到類、MessageProcessor方法簽名變了這類問(wèn)題。我的建議是新項(xiàng)目直接看官網(wǎng)倉(cāng)庫(kù)里的示例模塊那里會(huì)跟著版本更新。老項(xiàng)目升級(jí)到 2.x 時(shí)別指望代碼無(wú)縫兼容逐個(gè)類對(duì)照遷移反而更快。好在核心兩個(gè)接口的設(shè)計(jì)理念沒(méi)變你理解了協(xié)議 業(yè)務(wù)處理這一層遷移成本就只在于改方法名和包引用不算痛苦。6. 什么場(chǎng)景適合 smart-socket什么場(chǎng)景別碰6.1 適合的場(chǎng)景清單從我自己的使用經(jīng)驗(yàn)看smart-socket 非常適合下面幾類場(chǎng)景。物聯(lián)網(wǎng)設(shè)備接入是最大的一類很多硬件廠商使用私有 TCP 協(xié)議上報(bào)數(shù)據(jù)設(shè)備數(shù)量幾千到幾萬(wàn)消息頻率不高用 smart-socket 寫接入服務(wù)非常順手Protocol層處理私有協(xié)議MessageProcessor層處理上報(bào)數(shù)據(jù)邏輯很清晰。第二類是小規(guī)模即時(shí)通訊或消息推送。比如內(nèi)部系統(tǒng)之間需要建一條長(zhǎng)連接實(shí)時(shí)推送通知又不想引入 Kafka、MQTT 這類重量級(jí)組件smart-socket 可以很好地充當(dāng)傳輸層。第三類是教學(xué)和學(xué)習(xí)。對(duì)網(wǎng)絡(luò)編程新手來(lái)說(shuō)研究 smart-socket 比直接啃 Netty 源碼輕松得多它代碼量小、抽象清晰非常適合用來(lái)理解 AIO 和異步回調(diào)。還有一種情況是團(tuán)隊(duì)里有人對(duì) Netty 有抵觸心理覺(jué)得太重不愿意學(xué)。smart-socket 的上手成本低到幾乎不需要心理建設(shè)拿來(lái)寫一周就能上手維護(hù)對(duì)于人員流動(dòng)快的小團(tuán)隊(duì)也是一個(gè)現(xiàn)實(shí)選擇。6.2 不適合的場(chǎng)景雖然我喜歡 smart-socket但它確實(shí)不適合所有場(chǎng)景。如果你的服務(wù)要對(duì)接海量連接同時(shí)需要復(fù)雜的流量整形、限流、多協(xié)議編解碼、優(yōu)雅停機(jī)、分布式鏈路追蹤等能力那還是直接上 Netty或者更上層的 RPC 框架吧?？蚣艿妮p意味著很多事情要你自己做當(dāng)自己做的清單越來(lái)越長(zhǎng)時(shí)重量級(jí)框架反而是更省事的選擇。另外如果業(yè)務(wù)本身是 HTTP 服務(wù)不要用 smart-socket 去重復(fù)造輪子。HTTP 協(xié)議細(xì)節(jié)太多直接選嵌入式 HTTP 服務(wù)器或 Spring Boot 的 Web 能力更合適。smart-socket 更適合的是自定義 TCP 協(xié)議而不是改寫標(biāo)準(zhǔn)協(xié)議。還要注意團(tuán)隊(duì)里如果沒(méi)有人能響應(yīng)網(wǎng)絡(luò)底層問(wèn)題選型時(shí)要謹(jǐn)慎?？蚣茉俸?jiǎn)單網(wǎng)絡(luò)編程依然有一堆隱蔽問(wèn)題比如 TCP 半包、連接半開(kāi)、背壓機(jī)制。如果團(tuán)隊(duì)沒(méi)有相應(yīng)基礎(chǔ)出事時(shí)排查會(huì)比較吃力這種情況反而應(yīng)該選擇社區(qū)更大、資料更多的 Netty。6.3 選型時(shí)的個(gè)人經(jīng)驗(yàn)我自己的選型邏輯很簡(jiǎn)單先列需求再看方案不追新。只要確認(rèn)自研 TCP 長(zhǎng)連接 自定義協(xié)議 中等規(guī)模連接數(shù)這個(gè)組合成立我腦子里第一個(gè)跳出來(lái)的就是 smart-socket。它讓我把大量精力放在業(yè)務(wù)協(xié)議上而不是 IO 模型和線程管理上。如果你也打算用我最后有一個(gè)小建議動(dòng)手寫代碼之前先把消息格式畫清楚。不管是換行分隔還是長(zhǎng)度頭把字段定義、字節(jié)序、壓縮方式寫出來(lái)再去寫Protocol接口的實(shí)現(xiàn)。協(xié)議定清楚了整個(gè)項(xiàng)目基本就穩(wěn)了一半。網(wǎng)絡(luò)編程從來(lái)不是代碼量的問(wèn)題而是邊界條件的問(wèn)題smart-socket 幫你管住了連接邊界剩下的協(xié)議邊界依然是你的責(zé)任。 Java網(wǎng)絡(luò)編程新選擇：輕量AIO框架smart-socket的實(shí)戰(zhàn)解析
做 Java 服務(wù)端的人十有八九會(huì)在某個(gè)階段撞上網(wǎng)絡(luò)通信這堵墻。用原生 Socket 寫 demo 很爽但連接一多就痛苦聽(tīng)過(guò) Netty 的大名打開(kāi)文檔又是一片汪洋。其實(shí)很多項(xiàng)目并沒(méi)有那么復(fù)雜的網(wǎng)絡(luò)訴求你只是想把消息從 A 點(diǎn)送到 B 點(diǎn)然后處理一下業(yè)務(wù)。smart-socket 就看準(zhǔn)了這個(gè)空子——一套基于 Java AIO 的輕量通信框架核心接口只有兩個(gè)一個(gè)管協(xié)議編解碼一個(gè)管業(yè)務(wù)消息處理。我第一次看到這個(gè)項(xiàng)目時(shí)嘀咕過(guò)這也太簡(jiǎn)化了吧真跑起來(lái)一個(gè) Demo 之后反而覺(jué)得這種克制才是框架該有的樣子。這篇文章就聊聊它的設(shè)計(jì)思路、上手方式和我在實(shí)際使用中踩過(guò)的坑。1. smart-socket 解決的不是新問(wèn)題而是老問(wèn)題的體感問(wèn)題1.1 三種原生姿勢(shì)BIO、NIO、AIOJava 天生提供了三種網(wǎng)絡(luò)編程姿勢(shì)首先是最原始的 BIOBlocking IO。ServerSocket配多線程每來(lái)一個(gè)客戶端就 new 一個(gè)線程代碼非常直白accept 一個(gè)連接然后 read 等數(shù)據(jù)業(yè)務(wù)處理完寫回。問(wèn)題是連接數(shù)一上來(lái)線程數(shù)跟著爆炸。一個(gè)線程默認(rèn)棧大小 1MB一萬(wàn)個(gè)連接就是 10GB 級(jí)別的內(nèi)存開(kāi)銷這還沒(méi)算線程切換的 CPU 成本。所以 BIO 只適合幾十個(gè)連接的教學(xué)級(jí) demo生產(chǎn)環(huán)境基本不敢用。然后是 NIONon-blocking IO也就是Selector多路復(fù)用。一個(gè)線程可以同時(shí)管理成千上萬(wàn)個(gè)通道通過(guò)SelectionKey感知可讀、可寫事件。思路沒(méi)問(wèn)題但代碼寫起來(lái)很考驗(yàn)人要處理ByteBuffer的游標(biāo)、翻轉(zhuǎn)、compact還要自己維護(hù)每個(gè)連接的消息狀態(tài)尤其是半包粘包問(wèn)題稍不注意就是線上事故。這就是為什么后來(lái) Netty 能火——它把 NIO 的復(fù)雜度包裝得很好。AIOAsynchronous IO是 JDK 1.7 才正式提供的。它的思路更進(jìn)一步你發(fā)起一個(gè)異步讀然后給一個(gè)回調(diào)操作系統(tǒng)完成讀之后自動(dòng)調(diào)用你的回調(diào)。理論上開(kāi)發(fā)者不用再反復(fù)檢查事件狀態(tài)代碼可以寫得像順序執(zhí)行一樣自然。但 AIO 的 API 并不算友好AsynchronousSocketChannel配合CompletionHandler用起來(lái)有不少細(xì)節(jié)而且這么多年過(guò)去了國(guó)內(nèi)生態(tài)里真正把 Java AIO 封裝到能直接用于生產(chǎn)的框架并不多。smart-socket 比較早地看到了這個(gè)空白。1.2 Netty 雖好但有些項(xiàng)目背不動(dòng)一說(shuō) Java 網(wǎng)絡(luò)框架繞不開(kāi) Netty。Netty 確實(shí)強(qiáng)大Pipeline、EventLoop、ByteBuf、各種編解碼器幾乎覆蓋了你能想到的一切場(chǎng)景。但它的問(wèn)題也很現(xiàn)實(shí)學(xué)習(xí)成本高。你需要理解責(zé)任鏈機(jī)制知道ChannelHandler的生命周期還得熟悉 Netty 自己那套緩沖區(qū) API。即便只是寫一個(gè)簡(jiǎn)單的 TCP 客戶端也要配置bossGroup、workerGroup、NioEventLoopGroup代碼結(jié)構(gòu)天然比兩個(gè)接口要復(fù)雜。更關(guān)鍵的是依賴。新版 Netty 拆成了很多模塊引入一個(gè)完整的傳輸層可能要連帶好幾個(gè)包雖然 Maven 會(huì)自動(dòng)搞定但對(duì)于一些追求最小依賴、或者還在用老舊項(xiàng)目結(jié)構(gòu)的人來(lái)說(shuō)也是一種心理負(fù)擔(dān)。另外Netty 的抽象層級(jí)很高很多小項(xiàng)目根本用不到它的高級(jí)特性卻要為這些特性付出理解和排查問(wèn)題的成本。還有一部分團(tuán)隊(duì)寧愿自己寫 NIO 封裝也不上 Netty原因倒不是 Netty 不好而是不上框架意味著整個(gè)代碼庫(kù)自己可控。但自己封裝 NIO 的坑前面已經(jīng)說(shuō)過(guò)緩沖區(qū)管理、事件注冊(cè)、連接生命周期、寫半包每一個(gè)細(xì)節(jié)都要小心。與其這樣不如找一個(gè)輕量級(jí)的輪子把核心邏輯控制在自己手里。1.3 為什么偏偏選了 AIO回到 smart-socket 的選擇為什么基于 AIO而不是繼續(xù)站在 Netty 那條 NIO 賽道上我的理解是作者的目標(biāo)不是做一個(gè)大而全的通用網(wǎng)絡(luò)框架而是做一個(gè)夠用、順手、能快速落地的通信框架。AIO 在這方面的優(yōu)勢(shì)很明顯回調(diào)模型比事件循環(huán)更好理解代碼寫起來(lái)更像同步邏輯新手也能很快跟下來(lái)。從性能角度講Java AIO 在 Linux 上的底層實(shí)現(xiàn)其實(shí)還是 epoll 加線程池模擬天然會(huì)比純 NIO 多一層線程調(diào)度開(kāi)銷因此單機(jī)極限性能不一定壓得過(guò)極致調(diào)優(yōu)的 Netty。但 smart-socket 的定位本來(lái)就不是為了刷百萬(wàn)并發(fā)而是為了覆蓋幾千到幾萬(wàn)連接、消息量中等、開(kāi)發(fā)效率優(yōu)先的常見(jiàn)場(chǎng)景。在這個(gè)區(qū)間里AIO 無(wú)論是代碼可讀性還是維護(hù)成本都有它的獨(dú)特價(jià)值。另外AIO 有真正的異步 IO 內(nèi)核支持。在 Windows 上對(duì)應(yīng) IOCP是真正的異步完成端口在 Linux 上雖然是模擬但結(jié)合內(nèi)存復(fù)用和合理線程模型表現(xiàn)也很穩(wěn)。尤其在做遠(yuǎn)程控制、物聯(lián)網(wǎng)接入、小規(guī)模即時(shí)通信這類場(chǎng)景時(shí)感知非常明顯代碼簡(jiǎn)單了出問(wèn)題的地方也就少了。2. 兩個(gè)接口完成通信核心抽象值得學(xué)2.1 Protocol管好字節(jié)流和對(duì)象的邊界smart-socket 的核心抽象就是兩個(gè)接口Protocol是第一個(gè)。它定義了一條消息在網(wǎng)絡(luò)上怎么變成 Java 對(duì)象以及 Java 對(duì)象怎么變成要發(fā)送的字節(jié)流。為什么需要它因?yàn)?TCP 是面向字節(jié)流的底層的ByteBuffer里沒(méi)有消息的概念你必須自己決定消息從哪里開(kāi)始、到哪里結(jié)束?？唇涌诘姆椒ň兔靼琢恕ecode方法接收一個(gè)ByteBuffer返回一個(gè)解碼后的對(duì)象如果數(shù)據(jù)不夠組成一條完整消息就返回null框架會(huì)把剩余數(shù)據(jù)留著繼續(xù)等后續(xù)字節(jié)。encode方法正好相反把業(yè)務(wù)對(duì)象轉(zhuǎn)換成byte[]框架負(fù)責(zé)發(fā)送。這層抽象把協(xié)議和業(yè)務(wù)徹底分開(kāi)了想換協(xié)議格式的時(shí)候只需要換一個(gè)Protocol實(shí)現(xiàn)類。以最常見(jiàn)的換行符協(xié)議為例客戶端發(fā)送的每條消息以\n結(jié)尾服務(wù)端收到數(shù)據(jù)后需要掃描緩沖區(qū)里的換行符。找到就解析出一條消息并把讀過(guò)的數(shù)據(jù)消費(fèi)掉沒(méi)找到就返回null等待更多數(shù)據(jù)。這個(gè)邏輯放在decode里非常自然網(wǎng)絡(luò)包怎么切、粘包怎么處理都集中在一個(gè)類里而不是散落在業(yè)務(wù)代碼中。2.2 MessageProcessor業(yè)務(wù)邏輯的家MessageProcessor是第二個(gè)核心接口也是業(yè)務(wù)代碼主要待的地方。它有兩個(gè)方法process負(fù)責(zé)處理解碼后的完整消息stateEvent負(fù)責(zé)監(jiān)聽(tīng)連接狀態(tài)變化。process的參數(shù)里面有一個(gè)AioSession這是 smart-socket 抽象出來(lái)的會(huì)話對(duì)象可以用來(lái)向這個(gè)連接寫回?cái)?shù)據(jù)也可以主動(dòng)關(guān)閉連接。stateEvent這個(gè)設(shè)計(jì)容易被忽略但實(shí)際價(jià)值很高。連接何時(shí)建立、何時(shí)關(guān)閉、讀寫異常從哪里拋出都會(huì)通過(guò)狀態(tài)機(jī)回調(diào)到這個(gè)方法里。你可以在里面做資源清理、日志記錄也可以針對(duì)某些異常狀態(tài)做重連。相比 Netty 里事件和異常分散在各種handler方法中smart-socket 用一個(gè)方法把它收斂起來(lái)反而更容易維護(hù)。這兩個(gè)接口合起來(lái)覆蓋了通信框架最核心的兩件事數(shù)據(jù)怎么解析、解析完怎么處理。連接怎么建立、線程怎么調(diào)度、緩沖區(qū)怎么復(fù)用這些細(xì)節(jié)框架全包了。我第一次寫的時(shí)候最大的感受是終于不用在每個(gè)類里都關(guān)心ByteBuffer的生命周期了。2.3 最少代碼實(shí)現(xiàn)一個(gè)自定義協(xié)議舉一個(gè)最小可用的例子。假設(shè)協(xié)議很簡(jiǎn)單一行字符串以換行符分隔。先寫Protocol實(shí)現(xiàn)public class LineProtocol implements ProtocolString { Override public byte[] encode(String msg, AioSession session) { return (msg \n).getBytes(StandardCharsets.UTF_8); } Override public String decode(ByteBuffer buffer, AioSession session) { // 在緩沖區(qū)里找換行符 for (int i buffer.position(); i buffer.limit(); i) { if (buffer.get(i) \n) { int limit buffer.limit(); byte[] bytes new byte[i - buffer.position()]; buffer.get(bytes); buffer.get(); // 消費(fèi)換行符 buffer.limit(limit); return new String(bytes, StandardCharsets.UTF_8); } } return null; // 數(shù)據(jù)不完整繼續(xù)等待 } }再寫業(yè)務(wù)處理類public class EchoProcessor implements MessageProcessorString { Override public void process(AioSession session, String msg) { // 收到消息原樣返回 session.write(echo: msg); } Override public void stateEvent(AioSession session, StateMachine state, Throwable throwable) { // 可以在這里打印狀態(tài)日志 System.out.println(state: state); } }這樣就完成了核心邏輯。不需要額外繼承什么ChannelInitializer也不需要配置ChannelPipeline一個(gè)協(xié)議類一個(gè)業(yè)務(wù)類剩下的交給框架。2.4 輕的本質(zhì)框架只做連接管理對(duì)比同樣做 TCP 通信的另一個(gè)方案你會(huì)更明白 smart-socket 的輕在哪里。Netty 里有ChannelInboundHandler、ChannelOutboundHandler、MessageToMessageDecoder、LengthFieldBasedFrameDecoder等等每一個(gè)概念都有存在的理由但你真的只需要回顯一行字符串的時(shí)候這些概念都是理解成本。smart-socket 的哲學(xué)是框架負(fù)責(zé)連接生命周期和底層 IO你負(fù)責(zé)協(xié)議和業(yè)務(wù)。它沒(méi)有把功能做大而是把連接管理、會(huì)話保持、消息回調(diào)這些公共部分做好把最大的靈活性留給Protocol和MessageProcessor兩個(gè)接口。實(shí)際用下來(lái)這個(gè)抽象非常適合中小項(xiàng)目也很適合團(tuán)隊(duì)里新同學(xué)快速上手。3. 3 分鐘跑起一個(gè) Demo服務(wù)端與客戶端完整代碼3.1 引入依賴與版本選擇在 Maven 項(xiàng)目里使用 smart-socket 很簡(jiǎn)單。舊版 1.x 系列在中央倉(cāng)庫(kù)的坐標(biāo)是org.smartboot.socket:smart-socket引入核心包后就能直接用。如果是新項(xiàng)目我更建議先去 GitHub 倉(cāng)庫(kù)看一眼當(dāng)前最新的 release 版本因?yàn)?smart-socket 2.0 之后做過(guò)模塊化重構(gòu)包名和入口類都有調(diào)整直接照抄老博客的代碼可能會(huì)編譯不過(guò)。這里我們以社區(qū)常見(jiàn)的 1.x API 為例代碼結(jié)構(gòu)是dependency groupIdorg.smartboot.socket/groupId artifactIdsmart-socket/artifactId version1.5.5/version /dependency如果你用的是新版 2.x入口類應(yīng)該換成SmartServer之類的名字但Protocol和MessageProcessor這兩個(gè)核心設(shè)計(jì)思路還是延續(xù)的。學(xué)習(xí)的時(shí)候先抓住接口版本差異只是外包裝問(wèn)題。3.2 服務(wù)端怎么啟動(dòng)用上一節(jié)寫的LineProtocol和EchoProcessor服務(wù)端啟動(dòng)只需要幾行代碼public class ServerDemo { public static void main(String[] args) { AioQuickServerString server new AioQuickServerString() .setHost(0.0.0.0) .setPort(8088) .setProtocol(new LineProtocol()) .setProcessor(new EchoProcessor()); server.start(); System.out.println(server started on 8088); } }這里的AioQuickServer是 1.x 里的服務(wù)端啟動(dòng)類鏈?zhǔn)秸{(diào)用非常順手。start()方法會(huì)啟動(dòng)底層線程組并開(kāi)始監(jiān)聽(tīng)端口。注意主線程在調(diào)用start()后不會(huì)阻塞如果你寫的是獨(dú)立程序需要在最后加一個(gè)CountDownLatch.await()或者Thread.sleep(Long.MAX_VALUE)否則程序會(huì)直接跑完退出。setHost這一步容易被忽略。不設(shè)置時(shí)默認(rèn)綁定本地所有網(wǎng)卡如果只想對(duì)某個(gè)內(nèi)網(wǎng) IP 提供服務(wù)可以顯式指定。端口選擇避開(kāi)常用服務(wù)端口比如 8080、3306 這些避免沖突。3.3 客戶端怎么連接客戶端代碼更簡(jiǎn)單除了啟動(dòng)類是AioQuickClient其他結(jié)構(gòu)幾乎一樣public class ClientDemo { public static void main(String[] args) throws Exception { AioQuickClientString client new AioQuickClientString() .setHost(127.0.0.1) .setPort(8088) .setProtocol(new LineProtocol()) .setProcessor(new EchoProcessor()); AioSession session client.start(); // 發(fā)送一條消息 session.write(hello smart-socket); System.out.println(send done); // 等待回調(diào)實(shí)際項(xiàng)目中可以用 CountDownLatch Thread.sleep(3000); client.shutdown(); } }client.start()會(huì)返回一個(gè)AioSession通過(guò)session.write()就可以向服務(wù)端發(fā)數(shù)據(jù)。write是異步的多次連續(xù)調(diào)用不需要顯式排隊(duì)框架內(nèi)部會(huì)處理寫半包和緩沖區(qū)排隊(duì)。這里讓線程睡 3 秒是為了等服務(wù)端回顯的echo: hello smart-socket被客戶端process收到并打印出來(lái)。3.4 運(yùn)行起來(lái)看現(xiàn)象先啟動(dòng)服務(wù)端再啟動(dòng)客戶端輸出大致是這樣的服務(wù)端: server started on 8088 state: NEW_SESSION state: ENABLE_READ 收到消息: hello smart-socket 客戶端: state: NEW_SESSION state: ENABLE_READ 收到消息: echo: hello smart-socket注意stateEvent里的NEW_SESSION和ENABLE_READ狀態(tài)這是 smart-socket 狀態(tài)機(jī)的一部分。NEW_SESSION表示連接剛剛建立ENABLE_READ表示框架開(kāi)始監(jiān)聽(tīng)這個(gè)連接的可讀事件。你可以在NEW_SESSION里做連接級(jí)初始化比如綁定用戶信息到AioSession的屬性里后面process時(shí)直接取出來(lái)用。整個(gè)流程走下來(lái)你會(huì)發(fā)現(xiàn)完全沒(méi)有接觸ByteBuffer的翻轉(zhuǎn)操作也沒(méi)有管理過(guò)線程池。協(xié)議解析、連接管理、消息分發(fā)都被框架吃掉了剩下的事情非常直覺(jué)。4. 扒一扒 AIO 原理回調(diào)到底是咋回事4.1 點(diǎn)餐叫號(hào)模型理解異步回調(diào)Java AIO 的異步回調(diào)模型用吃飯來(lái)類比最清楚。BIO 相當(dāng)于去柜臺(tái)點(diǎn)餐餐沒(méi)做好就站在柜臺(tái)前一直等直到拿到餐才走期間什么也干不了。NIO 相當(dāng)于每隔幾秒去窗口瞄一眼看餐好了沒(méi)有沒(méi)好在旁邊干點(diǎn)別的但你必須自己反復(fù)檢查。AIO 則像餐廳給的叫號(hào)器你點(diǎn)完單回座位該干嘛干嘛餐好了叫號(hào)器會(huì)響你聽(tīng)到聲音再去取餐。對(duì)應(yīng)到代碼里AsynchronousSocketChannel.read方法接收一個(gè)CompletionHandlerInteger, Object其中completed方法在數(shù)據(jù)讀完之后被回調(diào)failed方法在出錯(cuò)時(shí)被回調(diào)。相比 NIO 里你需要自己去注冊(cè)O(shè)P_READ事件然后在select返回后再逐一檢查哪些通道有數(shù)據(jù)AIO 把什么時(shí)候讀這個(gè)問(wèn)題委托給了操作系統(tǒng)和回調(diào)機(jī)制。理解了這個(gè)模型你就知道為什么 smart-socket 的抽象能這么干凈?？蚣艿讓訜o(wú)非是在completed回調(diào)里調(diào)用你傳入的Protocol.decode把解出來(lái)的對(duì)象再交給MessageProcessor.process。這中間的緩沖區(qū)和線程調(diào)度細(xì)節(jié)框架內(nèi)部已經(jīng)封裝好了。4.2 smart-socket 在 AIO 之上做了什么原生 Java AIO 只提供了最基礎(chǔ)的通道操作直接用還是挺費(fèi)勁的。比如每次read都新建一個(gè)ByteBuffer在高頻消息下會(huì)產(chǎn)生大量?jī)?nèi)存分配再比如部分操作系統(tǒng)對(duì) AIO 的支持細(xì)節(jié)不同需要做兼容。smart-socket 在底層做了幾件關(guān)鍵的事情。第一是緩沖區(qū)的復(fù)用。連接內(nèi)部維護(hù)一個(gè)讀緩沖數(shù)據(jù)到了之后滾動(dòng)讀取而不是每次讀都開(kāi)新內(nèi)存。這在高連接數(shù)場(chǎng)景下非常關(guān)鍵能明顯減少 GC 壓力。第二是寫隊(duì)列管理。異步寫消息時(shí)如果連續(xù)write框架會(huì)把待發(fā)送數(shù)據(jù)排隊(duì)避免覆蓋和丟包。第三是線程模型封裝。底層回調(diào)由 AIO 線程池觸發(fā)但業(yè)務(wù)處理可以選在不同的執(zhí)行策略下運(yùn)行避免回調(diào)線程被業(yè)務(wù)代碼阻塞。這些優(yōu)化并不復(fù)雜但如果你自己用原生 AIO 寫至少要多寫幾百行代碼而且未必能考慮周全。框架的價(jià)值就在這里好的框架不只是抽象得好還把 80% 的邊界情況都處理掉了。4.3 性能體感與邊界用 smart-socket 壓測(cè)中低并發(fā)下性能表現(xiàn)很驚艷。我這里舉一個(gè)偏經(jīng)驗(yàn)的參考在 4 核 8G 的云服務(wù)器上一個(gè)簡(jiǎn)單的字符串消息服務(wù)保持幾千個(gè)長(zhǎng)連接消息長(zhǎng)度幾百字節(jié)單進(jìn)程每秒鐘能處理的消息數(shù)是幾萬(wàn)到十幾萬(wàn)量級(jí)具體數(shù)值視消息大小和業(yè)務(wù)處理時(shí)間而定。這個(gè)量級(jí)覆蓋絕大多數(shù)內(nèi)部系統(tǒng)、物聯(lián)網(wǎng)上報(bào)、監(jiān)控?cái)?shù)據(jù)轉(zhuǎn)發(fā)等場(chǎng)景。但要認(rèn)清它的邊界。如果目標(biāo)是幾十萬(wàn)連接、百萬(wàn) QPS 的互聯(lián)網(wǎng)網(wǎng)關(guān)smart-socket 就不太合適了。不是框架本身有硬傷而是 Java AIO 在 Linux 上的實(shí)現(xiàn)有天然開(kāi)銷加上框架刻意保持輕量、不做復(fù)雜分流面對(duì)極端性能場(chǎng)景時(shí)不如 Netty 調(diào)優(yōu)空間大。選型時(shí)一定先問(wèn)自己的場(chǎng)景連接數(shù)多少消息頻率多高需要哪些高級(jí)特性如果答案都比較中等smart-socket 是個(gè)非常舒服的選擇。5. 實(shí)戰(zhàn)避坑這些坑我替你踩過(guò)了5.1 粘包/半包要從 Protocol 層解決TCP 是流協(xié)議沒(méi)有消息邊界。一次read可能讀到半條消息也可能一次讀到好幾條消息這就是半包和粘包。我在一開(kāi)始寫LineProtocol的時(shí)候只處理了緩沖區(qū)里有換行符的情況但沒(méi)有處理一個(gè)緩沖區(qū)里有多個(gè)換行符的情況結(jié)果第一條消息正常第二條消息帶著殘留數(shù)據(jù)一起被解析直接亂碼。正確做法很簡(jiǎn)單在decode里用while循環(huán)掃描能解幾條就解幾條。smart-socket 的decode返回null時(shí)表示等更多數(shù)據(jù)返回對(duì)象時(shí)表示這條解析完了所以可以循環(huán)調(diào)用直到返回null。另外生產(chǎn)環(huán)境不建議用換行符做協(xié)議因?yàn)樗鼰o(wú)法表達(dá)二進(jìn)制數(shù)據(jù)。更好的是長(zhǎng)度頭協(xié)議前 4 字節(jié)表示消息體長(zhǎng)度后面跟著消息體。decode里先判斷緩沖區(qū)有沒(méi)有 4 字節(jié)再判斷有沒(méi)有完整消息體缺啥等啥邏輯非常清晰。5.2 回調(diào)線程里別做慢操作另一個(gè)容易踩的坑是在process方法里直接做耗時(shí)的操作比如查數(shù)據(jù)庫(kù)、調(diào)第三方接口、做復(fù)雜計(jì)算。這些操作會(huì)阻塞 AIO 回調(diào)線程導(dǎo)致后續(xù)所有連接的讀寫事件都不能及時(shí)響應(yīng)嚴(yán)重時(shí)整個(gè)服務(wù)卡住。框架本身提供了異步處理的能力但默認(rèn)情況下process是在 IO 回調(diào)線程里執(zhí)行的。我自己習(xí)慣是process里只做消息投遞把真正耗時(shí)的業(yè)務(wù)邏輯提交到獨(dú)立的業(yè)務(wù)線程池或者丟進(jìn)ExecutorService后立刻返回。這樣 IO 線程始終輕快連接讀寫不會(huì)受業(yè)務(wù)抖動(dòng)影響。如果業(yè)務(wù)邏輯必須同步處理也可以考慮調(diào)大 AIO 線程池的線程數(shù)但這不是根本解法。能用異步隊(duì)列解耦就盡量解耦這也是所有高性能服務(wù)端框架的通用原則。5.3 心跳與掉線檢測(cè)要自己補(bǔ)smart-socket 的設(shè)計(jì)目標(biāo)是輕所以很多高級(jí)功能不會(huì)內(nèi)置。比如心跳框架本身不提供自動(dòng)發(fā)送心跳包的機(jī)制你需要在自己的協(xié)議里定義心跳消息然后定期發(fā)送。不做心跳的后果是長(zhǎng)時(shí)間沒(méi)有數(shù)據(jù)交互的連接可能被中間網(wǎng)絡(luò)設(shè)備悄然斷開(kāi)而兩端都不知道。解決方案通常有兩層。第一層客戶端定時(shí)發(fā)送心跳消息第二層服務(wù)端在stateEvent里監(jiān)聽(tīng)異常斷開(kāi)或者利用空閑檢測(cè)邏輯主動(dòng)清理無(wú)效連接。如果你不想寫太多代碼也可以在業(yè)務(wù)里實(shí)現(xiàn)一個(gè)簡(jiǎn)單的超時(shí)機(jī)制每次收到消息記錄一下時(shí)間定期掃描最近沒(méi)活躍的連接直接調(diào)用session.close()關(guān)閉。核心原則是別讓框架替你想當(dāng)然通信類的?；钬?zé)任最終還是落在應(yīng)用層。5.4 注意 1.x 到 2.x 的 API 變化smart-socket 不是那種多年 API 紋絲不動(dòng)的項(xiàng)目1.x 到 2.x 經(jīng)歷了比較大的重構(gòu)。如果你在搜索引擎里找到的是老博客直接復(fù)制代碼到新版本可能會(huì)遇到AioQuickServer找不到類、MessageProcessor方法簽名變了這類問(wèn)題。我的建議是新項(xiàng)目直接看官網(wǎng)倉(cāng)庫(kù)里的示例模塊那里會(huì)跟著版本更新。老項(xiàng)目升級(jí)到 2.x 時(shí)別指望代碼無(wú)縫兼容逐個(gè)類對(duì)照遷移反而更快。好在核心兩個(gè)接口的設(shè)計(jì)理念沒(méi)變你理解了協(xié)議 業(yè)務(wù)處理這一層遷移成本就只在于改方法名和包引用不算痛苦。6. 什么場(chǎng)景適合 smart-socket什么場(chǎng)景別碰6.1 適合的場(chǎng)景清單從我自己的使用經(jīng)驗(yàn)看smart-socket 非常適合下面幾類場(chǎng)景。物聯(lián)網(wǎng)設(shè)備接入是最大的一類很多硬件廠商使用私有 TCP 協(xié)議上報(bào)數(shù)據(jù)設(shè)備數(shù)量幾千到幾萬(wàn)消息頻率不高用 smart-socket 寫接入服務(wù)非常順手Protocol層處理私有協(xié)議MessageProcessor層處理上報(bào)數(shù)據(jù)邏輯很清晰。第二類是小規(guī)模即時(shí)通訊或消息推送。比如內(nèi)部系統(tǒng)之間需要建一條長(zhǎng)連接實(shí)時(shí)推送通知又不想引入 Kafka、MQTT 這類重量級(jí)組件smart-socket 可以很好地充當(dāng)傳輸層。第三類是教學(xué)和學(xué)習(xí)。對(duì)網(wǎng)絡(luò)編程新手來(lái)說(shuō)研究 smart-socket 比直接啃 Netty 源碼輕松得多它代碼量小、抽象清晰非常適合用來(lái)理解 AIO 和異步回調(diào)。還有一種情況是團(tuán)隊(duì)里有人對(duì) Netty 有抵觸心理覺(jué)得太重不愿意學(xué)。smart-socket 的上手成本低到幾乎不需要心理建設(shè)拿來(lái)寫一周就能上手維護(hù)對(duì)于人員流動(dòng)快的小團(tuán)隊(duì)也是一個(gè)現(xiàn)實(shí)選擇。6.2 不適合的場(chǎng)景雖然我喜歡 smart-socket但它確實(shí)不適合所有場(chǎng)景。如果你的服務(wù)要對(duì)接海量連接同時(shí)需要復(fù)雜的流量整形、限流、多協(xié)議編解碼、優(yōu)雅停機(jī)、分布式鏈路追蹤等能力那還是直接上 Netty或者更上層的 RPC 框架吧?？蚣艿妮p意味著很多事情要你自己做當(dāng)自己做的清單越來(lái)越長(zhǎng)時(shí)重量級(jí)框架反而是更省事的選擇。另外如果業(yè)務(wù)本身是 HTTP 服務(wù)不要用 smart-socket 去重復(fù)造輪子。HTTP 協(xié)議細(xì)節(jié)太多直接選嵌入式 HTTP 服務(wù)器或 Spring Boot 的 Web 能力更合適。smart-socket 更適合的是自定義 TCP 協(xié)議而不是改寫標(biāo)準(zhǔn)協(xié)議。還要注意團(tuán)隊(duì)里如果沒(méi)有人能響應(yīng)網(wǎng)絡(luò)底層問(wèn)題選型時(shí)要謹(jǐn)慎?？蚣茉俸?jiǎn)單網(wǎng)絡(luò)編程依然有一堆隱蔽問(wèn)題比如 TCP 半包、連接半開(kāi)、背壓機(jī)制。如果團(tuán)隊(duì)沒(méi)有相應(yīng)基礎(chǔ)出事時(shí)排查會(huì)比較吃力這種情況反而應(yīng)該選擇社區(qū)更大、資料更多的 Netty。6.3 選型時(shí)的個(gè)人經(jīng)驗(yàn)我自己的選型邏輯很簡(jiǎn)單先列需求再看方案不追新。只要確認(rèn)自研 TCP 長(zhǎng)連接 自定義協(xié)議 中等規(guī)模連接數(shù)這個(gè)組合成立我腦子里第一個(gè)跳出來(lái)的就是 smart-socket。它讓我把大量精力放在業(yè)務(wù)協(xié)議上而不是 IO 模型和線程管理上。如果你也打算用我最后有一個(gè)小建議動(dòng)手寫代碼之前先把消息格式畫清楚。不管是換行分隔還是長(zhǎng)度頭把字段定義、字節(jié)序、壓縮方式寫出來(lái)再去寫Protocol接口的實(shí)現(xiàn)。協(xié)議定清楚了整個(gè)項(xiàng)目基本就穩(wěn)了一半。網(wǎng)絡(luò)編程從來(lái)不是代碼量的問(wèn)題而是邊界條件的問(wèn)題smart-socket 幫你管住了連接邊界剩下的協(xié)議邊界依然是你的責(zé)任。