Netty那點事(一)概述

xz43發表於2016-05-24

Netty和Mina是Java世界非常知名的通訊框架。它們都出自同一個作者,Mina誕生略早,屬於Apache基金會,而Netty開始在Jboss名下,後來出來自立門戶netty.io。關於Mina已有@FrankHui的Mina系列文章,我正好最近也要做一些網路方面的開發,就研究一下Netty的原始碼,順便分享出來了。

Netty目前有兩個分支:4.x和3.x。4.0分支重寫了很多東西,並對專案進行了分包,規模比較龐大,入手會困難一些,而3.x版本則已經被廣泛使用。本系列文章針對netty 3.7.0 final。3.x和4.0的區別可以參考這篇文章:http://www.oschina.net/translate/netty-4-0-new-and-noteworthy?print

起:Netty是什麼

大概用Netty的,無論新手還是老手,都知道它是一個“網路通訊框架”。所謂框架,基本上都是一個作用:基於底層API,提供更便捷的程式設計模型。那麼"通訊框架"到底做了什麼事情呢?回答這個問題並不太容易,我們不妨反過來看看,不使用netty,直接基於NIO編寫網路程式,你需要做什麼(以Server端TCP連線為例,這裡我們使用Reactor模型):

  1. 監聽埠,建立Socket連線
  2. 建立執行緒,處理內容
    1. 讀取Socket內容,並對協議進行解析
    2. 進行邏輯處理
    3. 回寫響應內容
    4. 如果是多次互動的應用(SMTP、FTP),則需要保持連線多進行幾次互動
  3. 關閉連線

建立執行緒是一個比較耗時的操作,同時維護執行緒本身也有一些開銷,所以我們會需要多執行緒機制,幸好JDK已經有很方便的多執行緒框架了,這裡我們不需要花很多心思。

此外,因為TCP連線的特性,我們還要使用連線池來進行管理:

  1. 建立TCP連線是比較耗時的操作,對於頻繁的通訊,保持連線效果更好
  2. 對於併發請求,可能需要建立多個連線
  3. 維護多個連線後,每次通訊,需要選擇某一可用連線
  4. 連線超時和關閉機制

想想就覺得很複雜了!實際上,基於NIO直接實現這部分東西,即使是老手也容易出現錯誤,而使用Netty之後,你只需要關注邏輯處理部分就可以了。

承:體驗Netty

這裡我們引用Netty的example包裡的一個例子,一個簡單的EchoServer,它接受客戶端輸入,並將輸入原樣返回。其主要程式碼如下:

<!-- lang: java --> public void run() { // Configure the server. ServerBootstrap bootstrap = new ServerBootstrap( new NioServerSocketChannelFactory(
                    Executors.newCachedThreadPool(),
                    Executors.newCachedThreadPool())); // Set up the pipeline factory. bootstrap.setPipelineFactory(new ChannelPipelineFactory() { public ChannelPipeline getPipeline() throws Exception { return Channels.pipeline(new EchoServerHandler());
        }
    }); // Bind and start to accept incoming connections. bootstrap.bind(new InetSocketAddress(port));
} 

這裡EchoServerHandler是其業務邏輯的實現者,大致程式碼如下:

<!-- lang: java -->
public class EchoServerHandler extends SimpleChannelUpstreamHandler { @Override public void messageReceived( ChannelHandlerContext ctx, MessageEvent e) { // Send back the received message to the remote peer. e.getChannel().write(e.getMessage());
    }
} 

還是挺簡單的,不是嗎?

轉:Netty背後的事件驅動機制

完成了以上一段程式碼,我們算是與Netty進行了第一次親密接觸。如果想深入學習呢?

首先推薦Netty的官方User Guide:http://netty.io/3.7/guide/。其次,閱讀原始碼是瞭解一個開源工具非常好的手段,但是Java世界的框架大多追求大而全,功能完備,如果逐個閱讀,難免迷失方向,Netty也並不例外。相反,抓住幾個重點物件,理解其領域概念及設計思想,從而理清其脈絡,相當於打通了任督二脈,以後的閱讀就不再困難了。

理解Netty的關鍵點在哪呢?我覺得,除了NIO的相關知識,另一個就是事件驅動的設計思想。什麼叫事件驅動?我們回頭看看EchoServerHandler的程式碼,其中的引數:public void messageReceived(ChannelHandlerContext ctx, MessageEvent e),MessageEvent就是一個事件。這個事件攜帶了一些資訊,例如這裡e.getMessage()就是訊息的內容,而EchoServerHandler則描述了處理這種事件的方式。一旦某個事件觸發,相應的Handler則會被呼叫,並進行處理。這種事件機制在UI程式設計裡廣泛應用,而Netty則將其應用到了網路程式設計領域。

在Netty裡,所有事件都來自ChannelEvent介面,這些事件涵蓋監聽埠、建立連線、讀寫資料等網路通訊的各個階段。而事件的處理者就是ChannelHandler,這樣,不但是業務邏輯,連網路通訊流程中底層的處理,都可以通過實現ChannelHandler來完成了。事實上,Netty內部的連線處理、協議編解碼、超時等機制,都是通過handler完成的。當博主弄明白其中的奧妙時,不得不佩服這種設計!

下圖描述了Netty進行事件處理的流程。Channel是連線的通道,是ChannelEvent的產生者,而ChannelPipeline可以理解為ChannelHandler的集合。

event driven in Netty

合:開啟Netty原始碼之門

理解了Netty的事件驅動機制,我們現在可以來研究Netty的各個模組了。Netty的包結構如下:

<!-- lang: ruby --> org
└── jboss
    └── netty
        ├── bootstrap 配置並啟動服務的類
        ├── buffer 緩衝相關類,對NIO Buffer做了一些封裝
        ├── channel 核心部分,處理連線
        ├── container 連線其他容器的程式碼
        ├── example 使用示例
        ├── handler 基於handler的擴充套件部分,實現協議編解碼等附加功能
        ├── logging 日誌
        └── util 工具類 

在這裡面,channel和handler兩部分比較複雜。我們不妨與Netty官方的結構圖對照一下,來了解其功能。

components in Netty

具體的解釋可以看這裡:http://netty.io/3.7/guide/#architecture。圖中可以看到,除了之前說到的事件驅動機制之外,Netty的核心功能還包括兩部分:

  • Zero-Copy-Capable Rich Byte Buffer

    零拷貝的Buffer。為什麼叫零拷貝?因為在資料傳輸時,最終處理的資料會需要對單個傳輸層的報文,進行組合或者拆分。NIO原生的ByteBuffer要做到這件事,需要對ByteBuffer內容進行拷貝,產生新的ByteBuffer,而Netty通過提供Composite(組合)和Slice(切分)兩種Buffer來實現零拷貝。這部分程式碼在org.jboss.netty.buffer包中。

  • Universal Communication API

    統一的通訊API。因為Java的Old I/O和New I/O,使用了互不相容的API,而Netty則提供了統一的API(org.jboss.netty.channel.Channel)來封裝這兩種I/O模型。這部分程式碼在org.jboss.netty.channel包中。

此外,Protocol Support功能通過handler機制實現。

接下來的文章,我們會根據模組,詳細的對Netty原始碼進行分析。

最後附上Netty那點事系列文章/程式碼的Github地址:https://github.com/code4craft/netty-learning

參考資料:

Netty那點事系列文章索引

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9399028/viewspace-2106178/,如需轉載,請註明出處,否則將追究法律責任。

相關文章