資訊專欄INFORMATION COLUMN
摘要：豐富的緩存數據結構使用它自己的緩存來表示字節序列而不是的。針對有一個定義良好的事件模型。有一些協議是多層的建立在其他低級協議基礎上。此外，甚至不是完全線程安全的。協議由標準化為。協議緩存整合是一個高效二進制協議的快速實現。
Chapter 2、結構概覽
這一節我們將確認Netty提供的核心功能是什么，以及它們怎么構成一個完整的網絡應用開發堆棧。
1、豐富的緩存數據結構Netty使用它自己的緩存API來表示字節序列而不是NIO的ByteBuffer。Netty的新緩存類——ChannelBuffer，徹底解決了ByteBuffer的問題，滿足了網絡應用開發者的日常需求。這里列舉幾個很酷的特點：
需要的話你可以自定義緩存類
通過一個內置的組合緩存類實現零拷貝組合
提供開箱即用的動態緩存，自動擴容，就像StringBuffer一樣
不再需要調用flip方法
通常比ByteBuffer要快
組合和切分ChannelBuffer當在通信層傳輸數據時，數據經常需要被組合或者切分。比如一次裝載被分成多個包，但是經常需要組合起來解碼。
傳統方式來說，多個包的數據通過復制到一個新的字節緩存而組合起來。
Netty支持零復制實現，通過讓一個新的ChannelBuffer“指向”所有要求組合的緩存，從而避免了復制操作。
傳統Java的I/O API對不同的傳輸類型提供不同的類和方法。舉個例子，java.net.Socket和java.net.DatagramSocket沒有公共父類因此它們在執行socket I/O的方式完全不一樣。
這種不匹配的結果就是使得應用程序從一種傳輸方式移植成另一種變得十分困難。也就是說你需要支持額外的傳輸方式因為應用程序的網絡層經常涉及到重寫。邏輯上，許多協議可以在不只一種傳輸方式，比如TCP/IP、UDO/IP、SCTP和串行通信上運行。
更糟的是，Java的新I/O（NIO）API繼承了老阻塞I/O（OIO）API的不兼容性，并且在下一個版本NIO.2（AIO）繼續這樣做。因為這些API在設計和表現特點上完全不同，你經常被迫在應用程序開始實現之前就需要確定好依賴那種API。
舉個例子，你可能想用OIO方式開始因為你服務的客戶數量很小且用OIO寫一個socket服務比用NIO要簡單得多。但是，當你的業務呈指數級上升然后你需要同時服務成千上萬的客戶時，麻煩就大了。你也可以用NIO方式開始，但是這可能會阻礙開發速度，畢竟NIO的選擇器API很復雜。
Netty擁有統一的異步I/O接口——Channel，它抽象了點對點通信要求的所有操作。只要你用一種Netty傳輸寫的應用程序，可以在其他Netty傳輸上運行。Nett通過統一的API提供了必要的傳輸方式：
基于NIO的TCP/IP傳輸（見org.jboss.netty.channel.socket.nio）
基于OIO的TCP/IP傳輸（見org.jboss.netty.channel.socket.oio）
基于OIO的UDP/IP傳輸
本地傳輸（見org.jboss.netty.channel.local）
要從一種傳輸方式切換到另一種，只需要改動幾行代碼，比如選擇另一個ChannelFactory實現。
你甚至可以使用還沒發布的新傳輸方式，比如串行通信傳輸，同樣替換幾行構造器調用的代碼。再者，你也可以通過繼承核心API實現自己的傳輸方式。
3、基于過濾鏈模式的事件模型一個定義良好的并可擴展性高的事件模型是一個事件驅動應用程序的前提。Netty針對I/O有一個定義良好的事件模型。你可以在不破壞已有代碼的情況下實現你自己的事件類，因為每一個事件類都根據一個嚴格的類層次體系區別于其他事件類。這是另一個和其他框架的不同點。很多NIO框架都沒有或者很有限的事件模型概念。如果它們提供了擴展，就會經常在嘗試增加自定義事件類時破壞已有代碼。
一個ChannelEvent由一個ChannelPipeline里的一列ChannelHandler來處理。這個管道實現了一個過濾鏈模式的高級形式，讓使用者完全控制一個事件如何被處理以及管道內的handler如何相互聯系。舉個例子，你可以規定數據從socket讀取時做點什么：
public class MyReadHandler implements SimpleChannelHandler {
public void messageReceived(ChannelHandlerContext ctx, MessageEvent evt) {
Object message = evt.getMessage();
// Do something with the received message.
...
// And forward the event to the next handler.
ctx.sendUpstream(evt);
}
}
你也可以規定一個handler在接收一個寫請求時做點什么：
public class MyWriteHandler implements SimpleChannelHandler {
public void writeRequested(ChannelHandlerContext ctx, MessageEvent evt) {
Object message = evt.getMessage();
// Do something with the message to be written.
...
// And forward the event to the next handler.
ctx.sendDownstream(evt);
}
}
4、支持更快速開發的高級組件
4.1、編解碼框架
之前“用POJO替代ChannelBuffer”那一節證實了，把協議編解碼從業務邏輯中分離出來通常是一個好主意。但是從零開始實現有一些困難。你需要處理信息分片。有一些協議是多層的（建立在其他低級協議基礎上）。還有一些協議在單機系統上實現特別困難。
因此，一個好的網絡應用框架需要提供一個可擴展的、可重用的、可單元測試的和多層級的編解碼器框架，產生可維護的用戶編解碼器。
Netty提供了一系列基礎和高級的編解碼器，可以解決你在寫一個協議編解碼器是遭遇的大多數問題，無論編解碼器是否簡單，是二進制的還是文本的。
4.2、SSL/TLS支持不像阻塞I/O，在NIO支持SSL是個值得正視對任務。你不能簡單得包裝一個流對數據進行加密解密，你必須要用到javax.net.ssl.SSLEngine。SSLEngine是一個跟SSL本身一樣復雜的狀態機。你需要處理所有可能的狀態，如密碼套件、加密密鑰協商、證書交換以及驗證。此外，SSL甚至不是完全線程安全的。
在Netty，SslHandler負責對外屏蔽SSLEngine所有細枝末節，你只需要配置SslHandler然后添加到你的ChannelPipeline中。SslHandler同時讓你可以很容易實現類似StartTLS的高級特性。
4.3、HTTP實現HTTP絕對是互聯網最流行的協議。現在已經有一系列HTTP實現，比如Servlet容器。那么為什么Netty還要自己實現HTTP呢？
Netty的HTTP支持和現有的HTTP庫很不一樣。它讓你可以完全控制HTTP在底層的消息交換。因為從根本上來說，它就是一個HTTP編解碼器和HTTP消息類的結合，沒有類似強制線程模型這樣的限制。也就是說，你可以按照你希望的工作方式來實現HTTP客戶端和服務端。你擁有所有HTTP規范內的控制權，包括線程模型、連接生命周期和分塊編碼。
基于它的高可定制性，你可以寫一個高效的HTTP服務：
要求持續連接和服務推送技術的聊天服務（如Comet）；
需要保持連接直到整個媒體文件流傳輸完畢的媒體流服務（如兩小時的電影）；
無內存壓力上傳大文件的文件服務（如上傳1G文件）；
可以異步連接成千上萬的第三方web服務的可伸縮的混合客戶端
4.4、WebSocket實現WebSocket在單TCP socket上實現一個雙向全雙工通信通道，用于web瀏覽器和web服務端端數據交互。
WebSocket協議由IETF標準化為RFC 6455。
Netty實現了RFC 6455和一系列舊版本規范。
Google Protocal Buffers是一個高效二進制協議的快速實現。憑借ProtobufEncoder和ProtobufDecoder，你可以將Goodgle Protocal Buffers編譯程序生成的信息類轉化為Netty編解碼器。
5、總結這一節，我們從特點出發回顧了Netty的總體架構。Netty擁有一個簡單且至今仍強大的架構。它由三個組件組成——buffer，channel和事件模型，所有高級特性都是在這三個組件的基礎上建立的。只要你理解了這三個組件是如何一起工作的，你就不難理解這節簡要提及的那些高級特性。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/74242.html
摘要：但是它不是自己創建線程，而是從調用構造方法時指定的線程池中獲取線程。這就意味著，即使發送兩個獨立的消息，操作系統會把他們視為一個字節串。釋放過程很簡單，調用它的方法，所有相關的和線程池將會自動關閉。 簡單找了下發現網上沒有關于Netty3比較完整的源碼解析的文章，于是我就去讀官方文檔，為了加強記憶，翻譯成了中文，有適當的簡化。 原文檔地址：Netty3文檔 Chapter 1 開始 1...
摘要：的選擇器允許單個線程監視多個輸入通道。一旦執行的線程已經超過讀取代碼中的某個數據片段，該線程就不會在數據中向后移動通常不會。 1、引言 很多初涉網絡編程的程序員，在研究Java NIO（即異步IO）和經典IO（也就是常說的阻塞式IO）的API時，很快就會發現一個問題：我什么時候應該使用經典IO，什么時候應該使用NIO？ 在本文中，將嘗試用簡明扼要的文字，闡明Java NIO和經典IO之...
摘要：英文全名為，也叫遠程過程調用，其實就是一個計算機通信協議，它是一種通過網絡從遠程計算機程序上請求服務而不需要了解底層網絡技術的協議。 Hello,Dubbo 你好，dubbo，初次見面，我想和你交個朋友。 Dubbo你到底是什么？ 先給出一套官方的說法：Apache Dubbo是一款高性能、輕量級基于Java的RPC開源框架。 那么什么是RPC？ 文檔地址：http://dubbo.a...
摘要：文檔翻譯系列二開始最簡單的方式就是在上使用示例。最小的例子如下它會在頁面上渲染一個標題。接下來的幾部分會逐步的介紹如何使用。我們會查驗應用的構建塊元素和組件。在例子中也使用了一些的語法。可以使用在線轉換器查看的代碼編譯。 React文檔翻譯系列（二）Hello World Hello World 開始React最簡單的方式就是在CodePen上使用Hello World示例。無需安裝任...
摘要：開始翻譯函數式編程專有名詞庫在翻譯的過程中，難免會遇到很多描述不太清楚的專有名詞，一個辦法是小組內進行討論，最后商量出來結果，小組內統一翻譯。因為本書的主題是函數式編程，所以這個名詞庫里大部分都是函數式編程相關的專有名詞。 在平時的工作中，我們都會經常查閱一些英文文檔來解決平時遇到的問題和拓寬視野。看到好的文章或者書籍有沒有想要和小伙伴分享的沖動，那么我們一起來翻譯吧～ 翻譯主張 信 ...
閱讀 2986·2021-11-16 11:45
閱讀 5162·2021-09-22 10:57
閱讀 1770·2021-09-08 09:36
閱讀 1591·2021-09-02 15:40
閱讀 2512·2021-07-26 23:38
閱讀 1194·2019-08-30 15:55
閱讀 929·2019-08-30 15:54
閱讀 1216·2019-08-29 14:06
