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