物聯網編程之通信框架-Netty(一)

1、引言

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

2、相關資料

Netty源碼在線閱讀：

• Netty-4.1.x地址是：http://docs.52im.net/extend/docs/src/netty4_1/
• Netty-4.0.x地址是：http://docs.52im.net/extend/docs/src/netty4/
• Netty-3.x地址是：http://docs.52im.net/extend/docs/src/netty3/
  

Netty在線API文檔：

• Netty-4.1.x API文檔(在線版)：http://docs.52im.net/extend/docs/api/netty4_1/
• Netty-4.0.x API文檔(在線版)：http://docs.52im.net/extend/docs/api/netty4/
• Netty-3.x API文檔(在線版)：http://docs.52im.net/extend/docs/api/netty3/
  

3、JDK 原生 NIO 程序的問題

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

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

4、Netty 的特點

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

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

5、Netty 常見使用場景

Netty 常見的使用場景如下：

• 1）互聯網行業：在分佈式系統中，各個節點之間需要遠程服務調用，高性能的 RPC 框架必不可少，Netty 作為異步高性能的通信框架，往往作為基礎通信組件被這些 RPC 框架使用。典型的應用有：阿里分佈式服務框架 Dubbo 的 RPC 框架使用 Dubbo 協議進行節點間通信，Dubbo 協議默認使用 Netty 作為基礎通信組件，用於實現各進程節點之間的內部通信。
• 2）遊戲行業：無論是手遊服務端還是大型的網絡遊戲，Java 語言得到了越來越廣泛的應用。Netty 作為高性能的基礎通信組件，它本身提供了 TCP/UDP 和 HTTP 協議棧。

非常方便定製和開發私有協議棧，賬號登錄服務器，地圖服務器之間可以方便的通過 Netty 進行高性能的通信。

• 3）大數據領域：經典的 Hadoop 的高性能通信和序列化組件 Avro 的 RPC 框架，默認採用 Netty 進行跨界點通信，它的 Netty Service 基於 Netty 框架二次封裝實現。
• 4）物聯網行業：基於Netty異步高性能事件驅動機制，開發與終端通信的Java後臺服務程序已經不再是難事，已經有很多物聯網企業選擇Netty。

有興趣的讀者可以瞭解一下目前有哪些開源項目使用了 Netty的Related Projects:https://netty.io/wiki/related-projects.html

6、Netty 高性能設計

Netty 作為異步事件驅動的網絡，高性能之處主要來自於其 I/O 模型和線程處理模型，前者決定如何收發數據，後者決定如何處理數據（重點理解這點）。
6.1I/O 模型

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

特點如下：

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

【I/O 複用模型】：

在 I/O 複用模型中，會用到 Select，這個函數也會使進程阻塞，但是和阻塞 I/O 所不同的是這兩個函數可以同時阻塞多個 I/O 操作。
而且可以同時對多個讀操作，多個寫操作的 I/O 函數進行檢測，直到有數據可讀或可寫時，才真正調用 I/O 操作函數。
Netty 的非阻塞 I/O 的實現關鍵是基於 I/O 複用模型，這裡用 Selector 對象表示：

Netty 的 IO 線程 NioEventLoop 由於聚合了多路複用器 Selector，可以同時併發處理成百上千個客戶端連接。

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

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

以 GUI 的邏輯處理為例，說明兩種邏輯的不同：

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

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

主要包括 4 個基本組件：

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

可以看出，相對傳統輪詢模式，事件驅動有如下優點：

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

【Reactor 線程模型】：
Reactor 是反應堆的意思，Reactor 模型是指通過一個或多個輸入同時傳遞給服務處理器的服務請求的事件驅動處理模式。
服務端程序處理傳入多路請求，並將它們同步分派給請求對應的處理線程，Reactor 模式也叫 Dispatcher 模式，即 I/O 多了複用統一監聽事件，收到事件後分發(Dispatch 給某進程)，是編寫高性能網絡服務器的必備技術之一。
Reactor 模型中有 2 個關鍵組成：

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

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

• 1）單 Reactor 單線程；
• 2）單 Reactor 多線程；
• 3）主從 Reactor 多線程。

可以這樣理解，Reactor 就是一個執行 while (true) { selector.select(); …} 循環的線程，會源源不斷的產生新的事件，稱作反應堆很貼切。
篇幅關係，這裡不再具體展開 Reactor 特性、優缺點比較，有興趣的讀者可以參考我之前另外一篇文章：《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》、《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》。
【Netty 線程模型】：
Netty 主要基於主從 Reactors 多線程模型（如下圖）做了一定的修改，其中主從 Reactor 多線程模型有多個 Reactor：

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

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

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

EventLoopGroup bossGroup = new NioEventLoopGroup();

EventLoopGroup workerGroup = new NioEventLoopGroup();

ServerBootstrap server = new ServerBootstrap();

server.group(bossGroup, workerGroup)

.channel(NioServerSocketChannel.class)

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

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

【異步處理】：
異步的概念和同步相對。當一個異步過程調用發出後，調用者不能立刻得到結果。實際處理這個調用的部件在完成後，通過狀態、通知和回調來通知調用者。
Netty 中的 I/O 操作是異步的，包括 Bind、Write、Connect 等操作會簡單的返回一個 ChannelFuture。
調用者並不能立刻獲得結果，而是通過 Future-Listener 機制，用戶可以方便的主動獲取或者通過通知機制獲得 IO 操作結果。
當 Future 對象剛剛創建時，處於非完成狀態，調用者可以通過返回的 ChannelFuture 來獲取操作執行的狀態，註冊監聽函數來執行完成後的操作。
常見有如下操作：

• 1）通過 isDone 方法來判斷當前操作是否完成；
• 2）通過 isSuccess 方法來判斷已完成的當前操作是否成功；
• 3）通過 getCause 方法來獲取已完成的當前操作失敗的原因；
• 4）通過 isCancelled 方法來判斷已完成的當前操作是否被取消；
• 5）通過 addListener 方法來註冊監聽器，當操作已完成(isDone 方法返回完成)，將會通知指定的監聽器；如果 Future 對象已完成，則理解通知指定的監聽器。

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

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

if (future.isSuccess()) {

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

} else {

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

}

});

摘自：http://www.52im.net/thread-2043-1-1.html

閱讀更多 物聯網開發者之家 的文章

關鍵字: 美好，一直在身邊 聯網 設計