目錄
- 一、Channel、EventLoop 和 ChannelFuture
- 1.1 Channel 介面
- 1.2 EventLoop 介面
- 1.3 ChannelFuture 介面
- 二、ChannelHandler 和 ChannelPipeline
- 2.1 ChannelHandler 介面
- 2.2 ChannelPipeline 介面
- 2.3 編碼器和解碼器
- 2.4 抽象類 SimpleChannelInboundHandler
- 三、引導
一、Channel、EventLoop 和 ChannelFuture
上一篇博文我們在構建服務端和客戶端中出現了一些新的類，可能有些同學還有些不了解它們的具體功能，沒關系，接下來我們對于 Channel、EventLoop 和 ChannelFuture 類進行的討論增添更多的細節，這些類合在一起，可以被認為是 Netty 網路抽象的代表：
- Channel ： Socket；
- EventLoop ： 控制流、多執行緒處理、并發；
- ChannelFuture ： 異步通知，
1.1 Channel 介面
基本的 I/O 操作（bind()、connect()、read()和 write()）依賴于底層網路傳輸所提供的原語，在基于 Java 的網路編程中，其基本的構造是 class Socket，Netty 的 Channel 介面所提供的 API，大大地降低了直接使用 Socket 類的復雜性，此外，Channel 也是擁有許多預定義的、專門化實作的廣泛類層次結構的根，下面是一個簡短的部分清單：
- EmbeddedChannel；
- LocalServerChannel；
- NioDatagramChannel；
- NioSctpChannel；
- NioSocketChannel，
1.2 EventLoop 介面
EventLoop 定義了 Netty 的核心抽象，用于處理連接的生命周期中所發生的事件，如圖在高層次上說明了 Channel、EventLoop、Thread 以及 EventLoopGroup 之間的關系，
這些關系可以表述為：
- 一個 EventLoopGroup 包含一個或者多個 EventLoop；
- 一個 EventLoop 在它的生命周期內只和一個 Thread 系結；
- 所有由 EventLoop 處理的 I/O 事件都將在它專有的 Thread 上被處理；
- 一個 Channel 在它的生命周期內只注冊于一個 EventLoop；
- 一個 EventLoop 可能會被分配給一個或多個 Channel，
注意，在這種設計中，一個給定 Channel 的 I/O 操作都是由相同的 Thread 執行的，實際上消除了對于同步的需要，
1.3 ChannelFuture 介面
Netty 中所有的 I/O 操作都是異步的，因為一個操作可能不會立即回傳，所以我們需要一種用于在之后的某個時間點確定其結果的方法，為此，Netty 提供了ChannelFuture 介面，其 addListener()方法注冊了一個ChannelFutureListener，以便在某個操作完成時（無論是否成功）得到通知，
可以將 ChannelFuture 看作是將來要執行的操作的結果的占位符，它究竟什么時候被執行則可能取決于若干的因素，因此不可能準確地預測，但是可以肯定的是它將會被執行，此外，所有屬于同一個 Channel 的操作都被保證其將以它們被呼叫的順序被執行，
二、ChannelHandler 和 ChannelPipeline
2.1 ChannelHandler 介面
從應用程式開發人員的角度來看，Netty 的主要組件是 ChannelHandler，它充當了所有處理入站和出站資料的應用程式邏輯的容器，這是可行的，因為 ChannelHandler 的方法是由網路事件（其中術語“事件”的使用非常廣泛）觸發的，事實上，ChannelHandler 可專門用于幾乎任何型別的動作，例如將資料從一種格式轉換為另外一種格式，或者處理轉換程序中所拋出的例外，
舉例來說，ChannelInboundHandler 是一個我們會經常實作的子介面，這種型別的ChannelHandler 接收入站事件和資料，這些資料隨后將會被你的應用程式的業務邏輯所處理，當我們要給連接的客戶端發送回應時，也可以從 ChannelInboundHandler 沖刷資料，我們的應用程式的業務邏輯通常駐留在一個或者多個 ChannelInboundHandler 中，
Netty 以配接器類的形式提供了大量默認的 ChannelHandler 實作，其旨在簡化應用程式處理邏輯的開發程序，如ChannelPipeline中的每個ChannelHandler將負責把事件轉發到鏈中的下一個 ChannelHandler，這些配接器類（及它們的子類）將自動執行這個操作，所以我們只重寫那些你想要特殊處理的方法和事件，
那么為什么要用配接器的形式提供這些？
那是因為有一些配接器類可以將撰寫自定義的 ChannelHandler 所需要的努力降到最低限度，因為它們提供了定義在對應介面中的所有方法的默認實作，下面這些是撰寫自定義 ChannelHandler 時經常會用到的配接器類：
- ChannelHandlerAdapter
- ChannelInboundHandlerAdapter
- ChannelOutboundHandlerAdapter
- ChannelDuplexHandler
2.2 ChannelPipeline 介面
ChannelPipeline 提供了 ChannelHandler 鏈的容器，并定義了用于在該鏈上傳播入站和出站事件流的 API，當 Channel 被創建時，它會被自動地分配到它專屬的 ChannelPipeline，ChannelHandler 安裝到 ChannelPipeline 中的程序如下所示：
- 一個ChannelInitializer的實作被注冊到了ServerBootstrap中或用于客戶端的Bootstrap
- 當 ChannelInitializer.initChannel()方法被呼叫時，ChannelInitializer將在 ChannelPipeline 中安裝一組自定義的 ChannelHandler；
- ChannelInitializer 將它自己從 ChannelPipeline 中移除，
為了審查發送或者接收資料時將會發生什么，讓我們來更加深入地研究 ChannelPipeline和 ChannelHandler 之間的共生關系吧，
ChannelHandler 是專為支持廣泛的用途而設計的，可以將它看作是處理往來 ChannelPipeline 事件（包括資料）的任何代碼的通用容器，如圖，其展示了從 ChannelHandler 派生的 ChannelInboundHandler 和ChannelOutboundHandler 介面，
使得事件流經 ChannelPipeline 是 ChannelHandler 的作業，它們是在應用程式的初始化或者引導階段被安裝的，這些物件接收事件、執行它們所實作的處理邏輯，并將資料傳遞給鏈中的下一個 ChannelHandler（有點類似責任鏈模式），它們的執行順序是由它們被添加的順序所決定的，實際上，被我們稱為 ChannelPipeline 的是這些 ChannelHandler 的編排順序，
如圖，說明了一個 Netty 應用程式中入站和出站資料流之間的區別，從一個客戶端應用程式的角度來看，如果事件的運動方向是從客戶端到服務器端，那么我們稱這些事件為出站的，反之則稱為入站的，
從上圖看入站和出站 ChannelHandler 可以被安裝到同一個 ChannelPipeline中，如果一個訊息或者任何其他的入站事件被讀取，那么它會從 ChannelPipeline 的頭部開始流動，并被傳遞給第一個 ChannelInboundHandler，這個 ChannelHandler 不一定會實際地修改資料，具體取決于它的具體功能，在這之后，資料將會被傳遞給鏈中的下一個ChannelInboundHandler，最終，資料將會到達 ChannelPipeline 的尾端，屆時，所有處理就都結束了，
資料的出站運動（即正在被寫的資料）在概念上也是一樣的，在這種情況下，資料將從ChannelOutboundHandler 鏈的尾端開始流動，直到它到達鏈的頭部為止，在這之后，出站資料將會到達網路傳輸層，這里顯示為 Socket，通常情況下，這將觸發一個寫操作，
ps：通過使用作為引數傳遞到每個方法的 ChannelHandlerContext事件可以被傳遞給當前ChannelHandler 鏈中的下一個ChannelHandler，因為你有時會忽略那些不感興趣的事件，所以 Netty提供了抽象基類
ChannelInboundHandlerAdapter 和 ChannelOutboundHandlerAdapter， ChannelHandlerContext 上的對應方法，每個都提供了簡單地將事件傳遞給下一ChannelHandler的方法的實作，隨后，我們可以通過重寫你所感興趣的那些方法來擴展這些類，
上圖中出站和入站的ChannelHandler都在同一個ChannelPipeline中，那么ChannelPipeline是如何區分和處理這兩種不同的類別的呢？
雖然 ChannelInboundHandle 和ChannelOutboundHandle 都擴展自 ChannelHandler，但是 Netty 能區分 ChannelInboundHandler 實作和 ChannelOutboundHandler 實作，并確保資料只會在具有相同定向型別的兩個 ChannelHandler 之間傳遞，
當ChannelHandler 被添加到ChannelPipeline 時，它將會被分配一個ChannelHandlerContext，其代表了 ChannelHandler 和 ChannelPipeline 之間的系結，雖然這個物件可以被用于獲取底層的 Channel，但是它主要還是被用于寫出站資料，
在 Netty 中，有兩種發送訊息的方式，我們可以直接寫到 Channel 中，也可以 寫到和 ChannelHandler相關聯的ChannelHandlerContext物件中，前一種方式將會導致訊息從ChannelPipeline 的尾端開始流動，而后者將導致訊息從 ChannelPipeline 中的下一個 ChannelHandler 開始流動，
總結一下：
- 將訊息寫入Channel 它將從尾端開始流動，
- 將訊息寫入ChannelHandler中，它將會從下一個ChannelHandler開始流動，
2.3 編碼器和解碼器
當我們通過 Netty 發送或者接收一個訊息的時候，就將會發生一次資料轉換，入站訊息會被解碼；也就是說，從位元組轉換為另一種格式，通常是一個 Java 物件，如果是出站訊息，則會發生相反方向的轉換：它將從它的當前格式被編碼為位元組，這兩種方向的轉換的原因很簡單：網路資料總是一系列的位元組，（編解碼）
對應于特定的需要，Netty 為編碼器和解碼器提供了不同型別的抽象類，例如，我們的應用程式可能使用了一種中間格式，而不需要立即將訊息轉換成位元組，我們仍然需要一個編碼器，但是它將派生自一個不同的超類，為了確定合適的編碼器型別，我們可以應用一個簡單的命名約定，通常來說，這些基類的名稱將類似于 ByteToMessageDecoder 或 MessageToByteEncoder，對于特殊的型別，我們會發現類似于 ProtobufEncoder 和 ProtobufDecoder這樣的名稱——預置的用來支持 Google 的 Protocol Buffers，
嚴格地說，其他的處理器也可以完成編碼器和解碼器的功能，但是，正如有用來簡化ChannelHandler 的創建的配接器類一樣，所有由 Netty 提供的編碼器/解碼器配接器類都實作了 ChannelOutboundHandler 或者 ChannelInboundHandler 介面，
我們會發現對于入站資料來說，channelRead 方法/事件已經被重寫了，對于每個從入站Channel 讀取的訊息，這個方法都將會被呼叫，隨后，它將呼叫由預置解碼器所提供的 decode()方法，并將已解碼的位元組轉發給 ChannelPipeline 中的下一個 ChannelInboundHandler，
出站訊息的模式是相反方向的：編碼器將訊息轉換為位元組，并將它們轉發給下一個ChannelOutboundHandler，
2.4 抽象類 SimpleChannelInboundHandler
最常見的情況是，我們的應用程式會利用一個 ChannelHandler 來接收解碼訊息，并對該資料應用業務邏輯，要創建一個這樣的 ChannelHandler，我們只需要擴展基類 SimpleChannelInboundHandler
在這種型別的 ChannelHandler 中，最重要的方法是 channelRead0(ChannelHandlerContext,T)，除了要求不要阻塞當前的 I/O 執行緒之外，其具體實作完全取決于我們，
三、引導
Netty 的引導類為應用程式的網路層配置提供了容器，這涉及將一個行程系結到某個指定的埠（服務端），或者將一個行程連接到另一個運行在某個指定主機的指定埠上的行程（客戶端），
嚴格來說，“連接”這個術語僅適用于面向連接的協議，如 TCP，其保證了兩個連接端點之間訊息的有序傳遞，
因此，有兩種型別的引導：一種用于客戶端（簡單地稱為 Bootstrap），而另一種（ServerBootstrap）用于服務器，無論我們的應用程式使用哪種協議或者處理哪種型別的資料，唯一決定它使用哪種引導類的是它是作為一個客戶端還是作為一個服務器（后面我們單獨提出來說明引導），
| 類別 | Bootstrap | ServerBootstrap |
|---|---|---|
| 網路編程中的作用 | 連接到遠程主機和埠 | 系結到一個本地埠 |
| EventLoopGroup 的數目 | 1 | 2 |
ps：實際上，ServerBootstrap 類也可以只使用一個 EventLoopGroup，此時其將在兩個場景下共用同一個 EventLoopGroup，
細心的同學應該發現了，ServerBootstrap使用了2個EventLoopGroup，這是因為服務器需要兩組不同的 Channel，
- 第一組將只包含一個 ServerChannel，代表服務器自身的已系結到某個本地埠的正在監聽的套接字，（專門用來創建Channel ）
- 而第二組將包含所有已創建的用來處理傳入客戶端連接（對于每個服務器已經接受的連接都有一個）的 Channel，（專門為Channel分配EventLoop）
它們的關系如圖：
ServerChannel 相關聯的 EventLoopGroup 將分配一個負責為傳入連接請求創建Channel 的 EventLoop，一旦連接被接受，第二個 EventLoopGroup 就會給它的 Channel分配一個 EventLoop，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/553383.html
標籤：其他
上一篇：MyBatis體系筆記（未完結）
下一篇：返回列表