[Netty 1] 初識Netty

1. 簡介

最先接觸netty是在閱讀Zookeeper源碼的時候，後來看到Storm的消息傳輸層也由ZMQ轉爲Netty，因此決心好好來研究和學習一下netty這個框架。

Netty項目地址：http://netty.io/index.html 

Github項目： https://github.com/netty/netty

Netty是一個異步的、事件驅動的網絡應用框架，基於它可以快速開發高性能協議的服務器和客戶端。Netty是基於NIO的，它大大簡化了網絡編程，Netty強調「quick and easy「，但並不只限於」quick and easy「，它的實現是創建在吸收了許多協議（FTP、SMTP、HTTP等）的實現經驗的基礎之上的，通過做者精心的設計探索，成功的找到了一種方式，在保證易於開發的同時還保證了其應用的性能，穩定性和伸縮性。

2. 架構介紹

netty的架構圖：

 

 咱們能夠看到主要有三大部分組成：Core、Transport Services和Protocol Support。

2.1 Core

Core封裝了底層通訊接口並提供了一個抽象的可擴展的事件模型。

2.1.1 Zero-Copy-Capable Rich Byte Buffer

netty基於NIO，可是它並無使用NIO的ByteBuffer，而是使用了本身定義的Buffer： ChannelBuffer。這是Netty用來表示二進制或文本消息的最基本的數據結構。 ChannelBuffer類型的設計從底層解決了ByteBuffer的問題，並可以知足平常網絡應用開發。它相比ByteBuffer有着明顯的優點，主要體如今：

• 容許自定義緩衝類型
• 基於內置複合緩衝類型實現透明的零拷貝
• 提供開箱的動態緩衝類型，容量能夠根據須要擴充，這點跟StringBuffer很相似
• 再也不須要調用flip（）方法
• 一般會比ByteBuffer更快

 至於每一點的詳細介紹，請參考官方文檔： http://docs.jboss.org/netty/3.2/api/org/jboss/netty/buffer/package-summary.html#package_description

2.1.2 Universal Communication API

傳統的Java I/O API在應對不一樣的傳輸協議時須要使用不一樣的類型和方法。例如，java.net.Socket 和 java.net.DatagramSocket它們並不具備相同的超類型，所以，這就須要使用不一樣的調用方式執行socket操做。

這種模式上的不匹配使得在更換一個網絡應用的傳輸協議時變得繁雜和困難。因爲（Java I/O API）缺少協議間的移植性，當你試圖在不修改網絡傳輸層的前提下增長多種協議的支持，這時便會產生問題。而且理論上講，多種應用層協議可運行在多種傳輸 層協議之上例如TCP/IP,UDP/IP,SCTP和串口通訊。
讓這種狀況變得更糟的是，Java新的I/O（NIO）API與原有的阻塞式的I/O（OIO）API並不兼容，NIO.2(AIO)也是如此。因爲全部的API不管是在其設計上仍是性能上的特性都與彼此不一樣，在進入開發階段，你經常會被迫的選擇一種你須要的API。
例如，在用戶數較小的時候你可能會選擇使用傳統的OIO(Old I/O) API，畢竟與NIO相比使用OIO將更加容易一些。然而，當你的業務呈指數增加而且服務器須要同時處理成千上萬的客戶鏈接時你便會遇到問題。這種狀況下 你可能會嘗試使用NIO，可是複雜的NIO Selector編程接口又會耗費你大量時間並最終會阻礙你的快速開發。
Netty有一個叫作Channel的統一的異步I/O編程接口，這個編程接口抽象了全部點對點的通訊操做。也就是說，若是你的應用是基於Netty的某一種傳輸實現，那麼一樣的，你的應用也能夠運行在Netty的另外一種傳輸實現上。Netty提供了幾種擁有相同編程接口的基本傳輸實現：

• NIO-based TCP/IP transport (See org.jboss.netty.channel.socket.nio),
• OIO-based TCP/IP transport (See org.jboss.netty.channel.socket.oio),
• OIO-based UDP/IP transport, and
• Local transport (See org.jboss.netty.channel.local).

切換不一樣的傳輸實現一般只需對代碼進行幾行的修改調整，例如選擇一個不一樣的ChannelFactory實現。
此外，你甚至能夠利用那些尚未寫入的新的傳輸協議，只需替換一些構造器的調用方法便可，例如串口通訊。並且因爲核心API具備高度的可擴展性，你還能夠完成本身的傳輸實現。

2.1.3 Extensible Event Model

Netty框架是基於事件驅動的，因此設計一個良好的具備很好的可擴展性的事件模型是很是必要的。

Netty具備定義良好的I/O事件模型。因爲嚴格的層次結構區分了不一樣的事件類型，所以Netty容許你在不破壞現有代碼的狀況下實現本身的事件類 型，這是與其餘框架相比另外一個不一樣的地方。不少NIO框架沒有或者僅有有限的事件模型概念；在你試圖添加一個新的事件類型的時候經常須要修改已有的代碼， 或者根本就不容許你進行這種擴展。
在一個ChannelPipeline內部一個ChannelEvent被一組ChannelHandler處理。所以對於一個事件如何被處理以及管道內部處理器間的交互過程，你都將擁有絕對的控制力。

有關事件模型的更多信息，參考API文檔中的ChannelEvent 和ChannelPipeline部分。

2.2 Transport Services 和 Protocol Support

上述所說起的核心組件已經足夠實現各類類型的網絡應用，除此以外，Netty也提供了一系列的高級組件來加速你的開發過程。

2.2.1. Codec框架

從業務邏輯代碼中分離協議處理部分老是一個很不錯的想法。然而若是一切從零開始便會遭遇 到實現上的複雜性。你不得不處理分段的消息。一些協議是多層的（例如構建在其餘低層協議之上的協議）。一些協議過於複雜以至難以在一臺主機（single state machine）上實現。

所以，一個好的網絡應用框架應該提供一種可擴展，可重用，可單元測試而且是多層的codec框架，爲用戶提供易維護的codec代碼。
Netty提供了一組構建在其核心模塊之上的codec實現，這些簡單的或者高級的codec實現幫你解決了大部分在你進行協議處理開發過程會遇到的問題，不管這些協議是簡單的仍是複雜的，二進制的或是簡單文本的。

2.2.2. SSL / TLS 支持

不一樣於傳統阻塞式的I/O實現，在NIO模式下支持SSL功能是一個艱難的工做。你不能只是簡單的包裝一下流數據並進行加密或解密工做，你不得不借助於 javax.net.ssl.SSLEngine，SSLEngine是一個有狀態的實現，其複雜性不亞於SSL自身。你必須管理全部可能的狀態，例如密 碼套件，密鑰協商（或從新協商），證書交換以及認證等。此外，與一般指望狀況相反的是SSLEngine甚至不是一個絕對的線程安全實現。
在Netty內部，SslHandler 封裝了全部艱難的細節以及使用SSLEngine可能帶來的陷阱。你所作的僅是配置並將該SslHandler插入到你的ChannelPipeline中。一樣Netty也容許你實現像StartTlS 那樣所擁有的高級特性，這很容易。

2.2.3.  HTTP實現

HTTP無疑是互聯網上最受歡迎的協議，而且已經有了一些例如Servlet容器這樣的HTTP實現。所以，爲何Netty還要在其核心模塊之上構建一套HTTP實現？
與現有的HTTP實現相比Netty的HTTP實現是至關不同凡響的。在HTTP消息的低層交互過程當中你將擁有絕對的控制力。這是由於Netty的 HTTP實現只是一些HTTP codec和HTTP消息類的簡單組合，這裏不存在任何限制——例如那種被迫選擇的線程模型。你能夠爲所欲爲的編寫那種能夠徹底按照你指望的工做方式工做 的客戶端或服務器端代碼。這包括線程模型，鏈接生命期，快編碼，以及全部HTTP協議容許你作的，全部的一切，你都將擁有絕對的控制力。
因爲這種高度可定製化的特性，你能夠開發一個很是高效的HTTP服務器，例如：

•  要求持久化連接以及服務器端推送技術的聊天服務（e.g. Comet ）
•  須要保持連接直至整個文件下載完成的媒體流服務（e.g. 2小時長的電影）
•  須要上傳大文件而且沒有內存壓力的文件服務（e.g. 上傳1GB文件的請求）
•  支持大規模mash-up應用以及數以萬計鏈接的第三方web services異步處理平臺

2.2.4. Google Protocol Buffer 整合

Google Protocol Buffers 是快速實現一個高效的二進制協議的理想方案。經過使用 ProtobufEncoder 和ProtobufDecoder，你能夠把Google Protocol Buffers 編譯器（protoc）生成的消息類放入到Netty的codec實現中。請參考官方示例中的「LocalTime」示例，這個例子也同時顯示出開發一個由簡單協議定義的客戶及服務端是多麼的容易。

2.3. 總述

在這一章節，咱們從功能特性的角度回顧了Netty的總體架構。Netty有一個簡單卻不失強大的架構。這個架構由三部分組成——緩衝（buffer）， 通道（channel），事件模型（event model）——全部的高級特性都構建在這三個核心組件之上。一旦你理解了它們之間的工做原理，你便不難理解在本章簡要說起的更多高級特性。

 

參考： http://blog.sina.com.cn/s/blog_3fe961ae01011oob.html