【Netty】最透徹的Netty原理架構解析

這多是目前最透徹的Netty原理架構解析 

本文基於 Netty 4.1 展開介紹相關理論模型，使用場景，基本組件、總體架構，知其然且知其因此然，但願給你們在實際開發實踐、學習開源項目方面提供參考。

Netty 是一個異步事件驅動的網絡應用程序框架，用於快速開發可維護的高性能協議服務器和客戶端。

JDK 原生 NIO 程序的問題

JDK 原生也有一套網絡應用程序 API，可是存在一系列問題，主要以下：

• NIO 的類庫和 API 繁雜，使用麻煩。你須要熟練掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。
• 須要具有其餘的額外技能作鋪墊。例如熟悉 Java 多線程編程，由於 NIO 編程涉及到 Reactor 模式，你必須對多線程和網路編程很是熟悉，才能編寫出高質量的 NIO 程序。
• 可靠性能力補齊，開發工做量和難度都很是大。例如客戶端面臨斷連重連、網絡閃斷、半包讀寫、失敗緩存、網絡擁塞和異常碼流的處理等等。 NIO 編程的特色是功能開發相對容易，可是可靠性能力補齊工做量和難度都很是大。
• JDK NIO 的 Bug。例如臭名昭著的 Epoll Bug，它會致使 Selector 空輪詢，最終致使 CPU 100%。 官方聲稱在 JDK 1.6 版本的 update 18 修復了該問題，可是直到 JDK 1.7 版本該問題仍舊存在，只不過該 Bug 發生機率下降了一些而已，它並無被根本解決。

Netty 的特色

Netty 對 JDK 自帶的 NIO 的 API 進行封裝，解決上述問題，主要特色有：

• 設計優雅，適用於各類傳輸類型的統一 API 阻塞和非阻塞 Socket；基於靈活且可擴展的事件模型，能夠清晰地分離關注點；高度可定製的線程模型 - 單線程，一個或多個線程池；真正的無鏈接數據報套接字支持（自 3.1 起）。
• 使用方便，詳細記錄的 Javadoc，用戶指南和示例；沒有其餘依賴項，JDK 5（Netty 3.x）或 6（Netty 4.x）就足夠了。
• 高性能，吞吐量更高，延遲更低；減小資源消耗；最小化沒必要要的內存複製。
• 安全，完整的 SSL/TLS 和 StartTLS 支持。
• 社區活躍，不斷更新，社區活躍，版本迭代週期短，發現的 Bug 能夠被及時修復，同時，更多的新功能會被加入。

Netty 常見使用場景

Netty 常見的使用場景以下：

• 互聯網行業。在分佈式系統中，各個節點之間須要遠程服務調用，高性能的 RPC 框架必不可少，Netty 做爲異步高性能的通訊框架，每每做爲基礎通訊組件被這些 RPC 框架使用。 典型的應用有：阿里分佈式服務框架 Dubbo 的 RPC 框架使用 Dubbo 協議進行節點間通訊，Dubbo 協議默認使用 Netty 做爲基礎通訊組件，用於實現各進程節點之間的內部通訊。
• 遊戲行業。不管是手遊服務端仍是大型的網絡遊戲，Java 語言獲得了愈來愈普遍的應用。Netty 做爲高性能的基礎通訊組件，它自己提供了 TCP/UDP 和 HTTP 協議棧。 很是方便定製和開發私有協議棧，帳號登陸服務器，地圖服務器之間能夠方便的經過 Netty 進行高性能的通訊。
• 大數據領域。經典的 Hadoop 的高性能通訊和序列化組件 Avro 的 RPC 框架，默認採用 Netty 進行跨界點通訊，它的 Netty Service 基於 Netty 框架二次封裝實現。

有興趣的讀者能夠了解一下目前有哪些開源項目使用了 Netty：Related Projects。

Netty 高性能設計

Netty 做爲異步事件驅動的網絡，高性能之處主要來自於其 I/O 模型和線程處理模型，前者決定如何收發數據，後者決定如何處理數據。

I/O 模型

用什麼樣的通道將數據發送給對方，BIO、NIO 或者 AIO，I/O 模型在很大程度上決定了框架的性能。

阻塞 I/O

傳統阻塞型 I/O(BIO)能夠用下圖表示：

Blocking I/O

特色以下：

• 每一個請求都須要獨立的線程完成數據 Read，業務處理，數據 Write 的完整操做問題。
• 當併發數較大時，須要建立大量線程來處理鏈接，系統資源佔用較大。
• 鏈接創建後，若是當前線程暫時沒有數據可讀，則線程就阻塞在 Read 操做上，形成線程資源浪費。

I/O 複用模型

在 I/O 複用模型中，會用到 Select，這個函數也會使進程阻塞，可是和阻塞 I/O 所不一樣的是這兩個函數能夠同時阻塞多個 I/O 操做。

並且能夠同時對多個讀操做，多個寫操做的 I/O 函數進行檢測，直到有數據可讀或可寫時，才真正調用 I/O 操做函數。

Netty 的非阻塞 I/O 的實現關鍵是基於 I/O 複用模型，這裏用 Selector 對象表示：

Nonblocking I/O

Netty 的 IO 線程 NioEventLoop 因爲聚合了多路複用器 Selector，能夠同時併發處理成百上千個客戶端鏈接。

當線程從某客戶端 Socket 通道進行讀寫數據時，若沒有數據可用時，該線程能夠進行其餘任務。

線程一般將非阻塞 IO 的空閒時間用於在其餘通道上執行 IO 操做，因此單獨的線程能夠管理多個輸入和輸出通道。

因爲讀寫操做都是非阻塞的，這就能夠充分提高 IO 線程的運行效率，避免因爲頻繁 I/O 阻塞致使的線程掛起。

一個 I/O 線程能夠併發處理 N 個客戶端鏈接和讀寫操做，這從根本上解決了傳統同步阻塞 I/O 一鏈接一線程模型，架構的性能、彈性伸縮能力和可靠性都獲得了極大的提高。

基於 Buffer

傳統的 I/O 是面向字節流或字符流的，以流式的方式順序地從一個 Stream 中讀取一個或多個字節, 所以也就不能隨意改變讀取指針的位置。

在 NIO 中，拋棄了傳統的 I/O 流，而是引入了 Channel 和 Buffer 的概念。在 NIO 中，只能從 Channel 中讀取數據到 Buffer 中或將數據從 Buffer 中寫入到 Channel。

基於 Buffer 操做不像傳統 IO 的順序操做，NIO 中能夠隨意地讀取任意位置的數據。

線程模型

數據報如何讀取？讀取以後的編解碼在哪一個線程進行，編解碼後的消息如何派發，線程模型的不一樣，對性能的影響也很是大。

事件驅動模型

一般，咱們設計一個事件處理模型的程序有兩種思路：

• 輪詢方式，線程不斷輪詢訪問相關事件發生源有沒有發生事件，有發生事件就調用事件處理邏輯。
• 事件驅動方式，發生事件，主線程把事件放入事件隊列，在另外線程不斷循環消費事件列表中的事件，調用事件對應的處理邏輯處理事件。事件驅動方式也被稱爲消息通知方式，實際上是設計模式中觀察者模式的思路。

以 GUI 的邏輯處理爲例，說明兩種邏輯的不一樣：

• 輪詢方式，線程不斷輪詢是否發生按鈕點擊事件，若是發生，調用處理邏輯。
• 事件驅動方式，發生點擊事件把事件放入事件隊列，在另外線程消費的事件列表中的事件，根據事件類型調用相關事件處理邏輯。

這裏借用 O'Reilly 大神關於事件驅動模型解釋圖：

事件驅動模型

主要包括 4 個基本組件：

• 事件隊列（event queue）：接收事件的入口，存儲待處理事件。
• 分發器（event mediator）：將不一樣的事件分發到不一樣的業務邏輯單元。
• 事件通道（event channel）：分發器與處理器之間的聯繫渠道。
• 事件處理器（event processor）：實現業務邏輯，處理完成後會發出事件，觸發下一步操做。

能夠看出，相對傳統輪詢模式，事件驅動有以下優勢：

• 可擴展性好，分佈式的異步架構，事件處理器之間高度解耦，能夠方便擴展事件處理邏輯。
• 高性能，基於隊列暫存事件，能方便並行異步處理事件。

Reactor 線程模型

Reactor 是反應堆的意思，Reactor 模型是指經過一個或多個輸入同時傳遞給服務處理器的服務請求的事件驅動處理模式。

服務端程序處理傳入多路請求，並將它們同步分派給請求對應的處理線程，Reactor 模式也叫 Dispatcher 模式，即 I/O 多了複用統一監聽事件，收到事件後分發(Dispatch 給某進程)，是編寫高性能網絡服務器的必備技術之一。

Reactor 模型中有 2 個關鍵組成：

• Reactor，Reactor 在一個單獨的線程中運行，負責監聽和分發事件，分發給適當的處理程序來對 IO 事件作出反應。它就像公司的電話接線員，它接聽來自客戶的電話並將線路轉移到適當的聯繫人。
• Handlers，處理程序執行 I/O 事件要完成的實際事件，相似於客戶想要與之交談的公司中的實際官員。Reactor 經過調度適當的處理程序來響應 I/O 事件，處理程序執行非阻塞操做。

Reactor 模型

取決於 Reactor 的數量和 Hanndler 線程數量的不一樣，Reactor 模型有 3 個變種：

• 單 Reactor 單線程。
• 單 Reactor 多線程。
• 主從 Reactor 多線程。

能夠這樣理解，Reactor 就是一個執行 while (true) { selector.select(); …} 循環的線程，會源源不斷的產生新的事件，稱做反應堆很貼切。

篇幅關係，這裏再也不具體展開 Reactor 特性、優缺點比較，有興趣的讀者能夠參考我以前另一篇文章：《理解高性能網絡模型》。

Netty 線程模型

Netty 主要基於主從 Reactors 多線程模型（以下圖）作了必定的修改，其中主從 Reactor 多線程模型有多個 Reactor：

• MainReactor 負責客戶端的鏈接請求，並將請求轉交給 SubReactor。
• SubReactor 負責相應通道的 IO 讀寫請求。
• 非 IO 請求（具體邏輯處理）的任務則會直接寫入隊列，等待 worker threads 進行處理。

這裏引用 Doug Lee 大神的 Reactor 介紹：Scalable IO in Java 裏面關於主從 Reactor 多線程模型的圖：

主從 Rreactor 多線程模型

特別說明的是：雖然 Netty 的線程模型基於主從 Reactor 多線程，借用了 MainReactor 和 SubReactor 的結構。可是實際實現上 SubReactor 和 Worker 線程在同一個線程池中：

EventLoopGroup bossGroup = newNioEventLoopGroup();

EventLoopGroup workerGroup = newNioEventLoopGroup();

ServerBootstrap server= newServerBootstrap();

server.group(bossGroup, workerGroup)

.channel(NioServerSocketChannel. class)

上面代碼中的 bossGroup 和 workerGroup 是 Bootstrap 構造方法中傳入的兩個對象，這兩個 group 均是線程池：

• bossGroup 線程池則只是在 Bind 某個端口後，得到其中一個線程做爲 MainReactor，專門處理端口的 Accept 事件，每一個端口對應一個 Boss 線程。
• workerGroup 線程池會被各個 SubReactor 和 Worker 線程充分利用。

異步處理

異步的概念和同步相對。當一個異步過程調用發出後，調用者不能馬上獲得結果。實際處理這個調用的部件在完成後，經過狀態、通知和回調來通知調用者。

Netty 中的 I/O 操做是異步的，包括 Bind、Write、Connect 等操做會簡單的返回一個 ChannelFuture。

調用者並不能馬上得到結果，而是經過 Future-Listener 機制，用戶能夠方便的主動獲取或者經過通知機制得到 IO 操做結果。

當 Future 對象剛剛建立時，處於非完成狀態，調用者能夠經過返回的 ChannelFuture 來獲取操做執行的狀態，註冊監聽函數來執行完成後的操做。

常見有以下操做：

• 經過 isDone 方法來判斷當前操做是否完成。
• 經過 isSuccess 方法來判斷已完成的當前操做是否成功。
• 經過 getCause 方法來獲取已完成的當前操做失敗的緣由。
• 經過 isCancelled 方法來判斷已完成的當前操做是否被取消。
• 經過 addListener 方法來註冊監聽器，當操做已完成(isDone 方法返回完成)，將會通知指定的監聽器；若是 Future 對象已完成，則理解通知指定的監聽器。

例以下面的代碼中綁定端口是異步操做，當綁定操做處理完，將會調用相應的監聽器處理邏輯。

serverBootstrap.bind(port).addListener(future -> {

if(future.isSuccess()) {

System.out. println( newDate() + ": 端口["+ port + "]綁定成功!");

} else{

System.err. println( "端口["+ port + "]綁定失敗!");

}

});

相比傳統阻塞 I/O，執行 I/O 操做後線程會被阻塞住, 直到操做完成；異步處理的好處是不會形成線程阻塞，線程在 I/O 操做期間能夠執行別的程序，在高併發情形下會更穩定和更高的吞吐量。

Netty 架構設計

前面介紹完 Netty 相關一些理論，下面從功能特性、模塊組件、運做過程來介紹 Netty 的架構設計。

功能特性

Netty 功能特性以下：

• 傳輸服務，支持 BIO 和 NIO。
• 容器集成，支持 OSGI、JBossMC、Spring、Guice 容器。
• 協議支持，HTTP、Protobuf、二進制、文本、WebSocket 等一系列常見協議都支持。還支持經過實行編碼解碼邏輯來實現自定義協議。
• Core 核心，可擴展事件模型、通用通訊 API、支持零拷貝的 ByteBuf 緩衝對象。

模塊組件

Bootstrap、ServerBootstrap

Bootstrap 意思是引導，一個 Netty 應用一般由一個 Bootstrap 開始，主要做用是配置整個 Netty 程序，串聯各個組件，Netty 中 Bootstrap 類是客戶端程序的啓動引導類，ServerBootstrap 是服務端啓動引導類。

Future、ChannelFuture

正如前面介紹，在 Netty 中全部的 IO 操做都是異步的，不能馬上得知消息是否被正確處理。

可是能夠過一會等它執行完成或者直接註冊一個監聽，具體的實現就是經過 Future 和 ChannelFutures，他們能夠註冊一個監聽，當操做執行成功或失敗時監聽會自動觸發註冊的監聽事件。

Channel

Netty 網絡通訊的組件，可以用於執行網絡 I/O 操做。Channel 爲用戶提供：

• 當前網絡鏈接的通道的狀態（例如是否打開？是否已鏈接？）
• 網絡鏈接的配置參數 （例如接收緩衝區大小）
• 提供異步的網絡 I/O 操做(如創建鏈接，讀寫，綁定端口)，異步調用意味着任何 I/O 調用都將當即返回，而且不保證在調用結束時所請求的 I/O 操做已完成。 調用當即返回一個 ChannelFuture 實例，經過註冊監聽器到 ChannelFuture 上，能夠 I/O 操做成功、失敗或取消時回調通知調用方。
• 支持關聯 I/O 操做與對應的處理程序。

不一樣協議、不一樣的阻塞類型的鏈接都有不一樣的 Channel 類型與之對應。下面是一些經常使用的 Channel 類型：

• NioSocketChannel，異步的客戶端 TCP Socket 鏈接。
• NioServerSocketChannel，異步的服務器端 TCP Socket 鏈接。
• NioDatagramChannel，異步的 UDP 鏈接。
• NioSctpChannel，異步的客戶端 Sctp 鏈接。
• NioSctpServerChannel，異步的 Sctp 服務器端鏈接，這些通道涵蓋了 UDP 和 TCP 網絡 IO 以及文件 IO。

Selector

Netty 基於 Selector 對象實現 I/O 多路複用，經過 Selector 一個線程能夠監聽多個鏈接的 Channel 事件。

當向一個 Selector 中註冊 Channel 後，Selector 內部的機制就能夠自動不斷地查詢(Select) 這些註冊的 Channel 是否有已就緒的 I/O 事件（例如可讀，可寫，網絡鏈接完成等），這樣程序就能夠很簡單地使用一個線程高效地管理多個 Channel 。

NioEventLoop

NioEventLoop 中維護了一個線程和任務隊列，支持異步提交執行任務，線程啓動時會調用 NioEventLoop 的 run 方法，執行 I/O 任務和非 I/O 任務：

• I/O 任務，即 selectionKey 中 ready 的事件，如 accept、connect、read、write 等，由 processSelectedKeys 方法觸發。
• 非 IO 任務，添加到 taskQueue 中的任務，如 register0、bind0 等任務，由 runAllTasks 方法觸發。

兩種任務的執行時間比由變量 ioRatio 控制，默認爲 50，則表示容許非 IO 任務執行的時間與 IO 任務的執行時間相等。

NioEventLoopGroup

NioEventLoopGroup，主要管理 eventLoop 的生命週期，能夠理解爲一個線程池，內部維護了一組線程，每一個線程(NioEventLoop)負責處理多個 Channel 上的事件，而一個 Channel 只對應於一個線程。

ChannelHandler

ChannelHandler 是一個接口，處理 I/O 事件或攔截 I/O 操做，並將其轉發到其 ChannelPipeline(業務處理鏈)中的下一個處理程序。

ChannelHandler 自己並無提供不少方法，由於這個接口有許多的方法須要實現，方便使用期間，能夠繼承它的子類：

• ChannelInboundHandler 用於處理入站 I/O 事件。
• ChannelOutboundHandler 用於處理出站 I/O 操做。

或者使用如下適配器類：

• ChannelInboundHandlerAdapter 用於處理入站 I/O 事件。
• ChannelOutboundHandlerAdapter 用於處理出站 I/O 操做。
• ChannelDuplexHandler 用於處理入站和出站事件。

ChannelHandlerContext

保存 Channel 相關的全部上下文信息，同時關聯一個 ChannelHandler 對象。

ChannelPipline

保存 ChannelHandler 的 List，用於處理或攔截 Channel 的入站事件和出站操做。

ChannelPipeline 實現了一種高級形式的攔截過濾器模式，使用戶能夠徹底控制事件的處理方式，以及 Channel 中各個的 ChannelHandler 如何相互交互。

下圖引用 Netty 的 Javadoc 4.1 中 ChannelPipeline 的說明，描述了 ChannelPipeline 中 ChannelHandler 一般如何處理 I/O 事件。

I/O 事件由 ChannelInboundHandler 或 ChannelOutboundHandler 處理，並經過調用 ChannelHandlerContext 中定義的事件傳播方法。

例如 ChannelHandlerContext.fireChannelRead（Object）和 ChannelOutboundInvoker.write（Object）轉發到其最近的處理程序。

入站事件由自下而上方向的入站處理程序處理，如圖左側所示。入站 Handler 處理程序一般處理由圖底部的 I/O 線程生成的入站數據。

一般經過實際輸入操做（例如 SocketChannel.read（ByteBuffer））從遠程讀取入站數據。

出站事件由上下方向處理，如圖右側所示。出站 Handler 處理程序一般會生成或轉換出站傳輸，例如 write 請求。

I/O 線程一般執行實際的輸出操做，例如 SocketChannel.write（ByteBuffer）。

在 Netty 中每一個 Channel 都有且僅有一個 ChannelPipeline 與之對應，它們的組成關係以下：

一個 Channel 包含了一個 ChannelPipeline，而 ChannelPipeline 中又維護了一個由 ChannelHandlerContext 組成的雙向鏈表，而且每一個 ChannelHandlerContext 中又關聯着一個 ChannelHandler。

入站事件和出站事件在一個雙向鏈表中，入站事件會從鏈表 head 日後傳遞到最後一個入站的 handler，出站事件會從鏈表 tail 往前傳遞到最前一個出站的 handler，兩種類型的 handler 互不干擾。

Netty 工做原理架構

初始化並啓動 Netty 服務端過程以下：

publicstaticvoidmain(String[] args) {

// 建立mainReactor

NioEventLoopGroup boosGroup = newNioEventLoopGroup();

// 建立工做線程組

NioEventLoopGroup workerGroup = newNioEventLoopGroup();

final ServerBootstrap serverBootstrap = newServerBootstrap();

serverBootstrap

// 組裝NioEventLoopGroup

. group(boosGroup, workerGroup)

// 設置channel類型爲NIO類型

.channel(NioServerSocketChannel.class)

// 設置鏈接配置參數

.option(ChannelOption.SO_BACKLOG, 1024)

.childOption(ChannelOption.SO_KEEPALIVE, true)

.childOption(ChannelOption.TCP_NODELAY, true)

// 配置入站、出站事件handler

.childHandler( newChannelInitializer<NioSocketChannel>() {

@ Override

protectedvoidinitChannel(NioSocketChannel ch) {

// 配置入站、出站事件channel

ch.pipeline().addLast(...);

ch.pipeline().addLast(...);

}

});

// 綁定端口

intport = 8080;

serverBootstrap.bind(port).addListener(future -> {

if(future.isSuccess()) {

System. out.println( newDate() + ": 端口["+ port + "]綁定成功!");

} else{

System.err.println( "端口["+ port + "]綁定失敗!");

}

});

}

基本過程以下：

• 初始化建立 2 個 NioEventLoopGroup，其中 boosGroup 用於 Accetpt 鏈接創建事件並分發請求，workerGroup 用於處理 I/O 讀寫事件和業務邏輯。
• 基於 ServerBootstrap(服務端啓動引導類)，配置 EventLoopGroup、Channel 類型，鏈接參數、配置入站、出站事件 handler。
• 綁定端口，開始工做。

結合上面介紹的 Netty Reactor 模型，介紹服務端 Netty 的工做架構圖：

服務端 Netty Reactor 工做架構圖

Server 端包含 1 個 Boss NioEventLoopGroup 和 1 個 Worker NioEventLoopGroup。

NioEventLoopGroup 至關於 1 個事件循環組，這個組裏包含多個事件循環 NioEventLoop，每一個 NioEventLoop 包含 1 個 Selector 和 1 個事件循環線程。

每一個 Boss NioEventLoop 循環執行的任務包含 3 步：

• 輪詢 Accept 事件。
• 處理 Accept I/O 事件，與 Client 創建鏈接，生成 NioSocketChannel，並將 NioSocketChannel 註冊到某個 Worker NioEventLoop 的 Selector 上。
• 處理任務隊列中的任務，runAllTasks。任務隊列中的任務包括用戶調用 eventloop.execute 或 schedule 執行的任務，或者其餘線程提交到該 eventloop 的任務。

每一個 Worker NioEventLoop 循環執行的任務包含 3 步：

• 輪詢 Read、Write 事件。
• 處理 I/O 事件，即 Read、Write 事件，在 NioSocketChannel 可讀、可寫事件發生時進行處理。
• 處理任務隊列中的任務，runAllTasks。

其中任務隊列中的 Task 有 3 種典型使用場景。

①用戶程序自定義的普通任務

ctx.channel().eventLoop().execute( newRunnable() {

@Override

publicvoidrun(){

//...

}

});

②非當前 Reactor 線程調用 Channel 的各類方法

例如在推送系統的業務線程裏面，根據用戶的標識，找到對應的 Channel 引用，而後調用 Write 類方法向該用戶推送消息，就會進入到這種場景。最終的 Write 會提交到任務隊列中後被異步消費。

③用戶自定義定時任務

ctx.channel().eventLoop().schedule( newRunnable() {

@Override

publicvoidrun(){

}

}, 60, TimeUnit.SECONDS);

總結

如今穩定推薦使用的主流版本仍是 Netty4，Netty5 中使用了 ForkJoinPool，增長了代碼的複雜度，可是對性能的改善卻不明顯，因此這個版本不推薦使用，官網也沒有提供下載連接。

Netty 入門門檻相對較高，是由於這方面的資料較少，並非由於它有多難，你們其實均可以像搞透 Spring 同樣搞透 Netty。

在學習以前，建議先理解透整個框架原理結構，運行過程，能夠少走不少彎路。

參考資料：

• Netty入門與實戰：仿寫微信 IM 即時通信系統
• Netty官網
• Netty 4.x學習筆記 - 線程模型
• Netty入門與實戰
• 理解高性能網絡模型
• Netty基本原理介紹
• software-architecture-patterns.pdf
• Netty高性能之道 —— 李林鋒
• 《Netty In Action》
• 《Netty權威指南》

做者：陳彩華

編輯：陶家龍、孫淑娟

出處：轉載自Hollis（ID：hollischuang）微信公衆號