Netty：一個非阻塞的用戶端/伺服器架構，netty架構

Netty：一個非阻塞的用戶端/伺服器架構，netty架構

Netty：一個非阻塞的用戶端/伺服器架構

作者：chszs，轉載需註明。部落客頁：http://blog.csdn.net/chszs

Netty是一個非同步事件驅動的網路應用程式框架，為Java網路應用的開發帶來了一些新活力。Netty由協議伺服器和用戶端所組成，可用於快速開發可維護的高效能軟體。Netty應用程式框架及其工具簡化了網路編程，而且由Netty社區進行維護。

Netty還被歸類為NIO用戶端/伺服器架構，用它能夠快速、簡易地開發網路應用，使得TCP和UDP通訊端伺服器的網路編程得以簡化和更加合理。

內建的HTTP協議支援WebSocket，允許架構運行在Servlet容器內。新版的Netty同時支援非阻塞I/O和阻塞I/O通訊。

Netty的特性：

1、傳輸服務包括：通訊端和資料報、HTTP通道、虛擬機器內部管道

2、協議支援以下擴充：HTTP、Web Socket、Google Protocol Buffer、SSL-StartTLS、大檔案傳輸、RTSP、Zlib或gzip壓縮、二進位協議、其它遺留的文字格式設定

3、核心：可擴充的事件模型、整合通訊API、零拷貝能力的富位元組緩衝

Netty設計：

Netty在設計上針對多種傳輸類型，整合了一套統一的API、阻塞和非阻塞的通訊端。Netty的事件模型是可擴充的，可以把關注點進行明確隔離。Netty的執行緒模式提供了在單線程或類SEDA這樣的線程池之間選擇的靈活性，而且線程是高可自訂的，對資料報的支援實現了真正的無串連通訊，Netty的管道抽象與安全線程、動態可變性相結合，使得架構得到有力支撐。

註：SEDA，即Staged Event Driven Architecture，階段化的事件驅動架構。SEDA的思路是將原先由一個線程完成的任務，分割為相對獨立的多個階段。每個階段由專用的一組線程負責執行，階段之間用過隊列互動。採用SEDA方式，只有在並發量提高到一定程度，並發成為系統瓶頸時才能體現價值。就單個操作而言，由於隊列的傳遞，其延遲一定是有所上升的。

可以參考這篇論文《SEDA: an Architecture for Well-Conditioned, Scalable Internet Services》

SEDA是加州大學伯克利分校研究的一套優秀的高效能互連網伺服器架構模型，其設計目標是：支援大規模並發處理、簡化系統開發、支援處理監測、支援系統資源管理。

兩種目前廣泛使用的網路伺服器架構模型：

1）多線程伺服器（Threaded Server)

工作原理：對於每一個request，dispatcher都會為其建立並分配一個線程，該線程負責這個請求的處理。此方式又名為（Thread-per-request）。

優點：執行粒度是整個完整的處理流程，處理邏輯清晰，易於開發。
缺點：當隨著處理請求的不斷增加，會導致並發執行的線程數量太多。過多的線程數量會導致系統線上程調度和資源爭用上的開銷過大，從而引起系統效能急劇下降，導致系統處理能力下降。
改進措施：引入線程池（Bounded Thread Pools）
系統最多隻能建立一定數量的線程。當所有線程都飽和運行時，新到達的處理請求只能等待，或者被拋棄。
缺點：執行粒度仍然是完整的處理流程，難以檢測系統效能瓶頸的根源以及進行相應調整。

2）事件驅動並發處理（Event-Driven Concurrency）

將處理流程分割成多個步驟，每一個步驟都實現為一個有限狀態機器（FSM）。
工作原理：所有的處理請求會作為Event進入系統，由Scheduler負責傳遞給相應FSM。FSM的處理結果也以Event形式輸出給Scheduler。新的Event會再次被Scheduler進行轉寄給下一個FSM，直至處理完成。

優點：
1、隨著處理量的增加，系統負荷是以線形增長。當達到系統飽和處理能力後，系統的處理能力不會下降。
2、由於將各處理步驟獨立實現，易於進行系統監測和調整。
缺點：
Scheduler的設計和實現過於複雜，針對於不同的應用和系統的邏輯變更需要不同的實現。

SEDA架構

 (近似於Event-Driven Concurrency，但是沒有其中的Scheduler)將每一個處理步驟獨立為一個Stage。

Stage結構：
1）一個接受輸入的Event Queue；
2）一個應用開發人員編寫的Event Handler；
3）一個Controller用於對執行過程進行控制。包括並發線程數量、批處理數量等等；
4）一個Thread Pool用於並發處理；
Stage的輸入通過Event Queue獲得。Stage的輸出會以Event形式推送到其他Stage的Event Queue中。Stage之間的這種串連關係由應用開發人員指定。
帶來的問題：Event Queue儘管減少了模組間的耦合性，但是會降低響應速度。

效能及有效性：

Netty不僅提供了良好的穩定性，還提供了更好的輸送量和更低的延遲效能，把記憶體複製限制到最低需求上，零拷貝能力富位元組緩衝特性使核心能夠管理DMA複製。這減少了CPU和系統匯流排的負擔，提升了架構的有效性。

可擴充性與整合：

Netty有可擴充能力，支援擴充到上千種連線類型，而且在維持有效性的同時沒有效能瓶頸。這些串連的可靠性都非常高，而且不會失效。Netty易於擴充和構建。Netty還提供了靈活的整合效能，可以與很多環境比如Linux、Java、C#、C++、Python等環境整合。

安全：Netty提供了完整的SSL/TLS和StartTLS支援。

Netty官方提供了很多指南、文檔以及JavaDoc和例子供開發人員參考。

Netty目前的最新穩定版是4.0.23版。

： http://dl.bintray.com/netty/downloads/netty-4.0.23.Final.tar.bz2

android用戶端+服務端，技術選擇的思路

Netty是由JBOSS提供的一個java開源架構。Netty提供非同步、事件驅動的網路應用程式架構和工具，用以快速開發高效能、高可靠性的網路伺服器和用戶端程式。也就是說，Netty 是一個基於NIO的客戶，伺服器端編程架構，它在socket的基礎上根據各種常用的應用協議又進一步封裝，提供更便利的介面。如果需要快速搭建一個C/S服務架構，那Netty過來用是沒錯。

反過來你的情況是需要學習這個課程，你應該掌握基本的socket編程及其通訊原理，所以學習時直接用socket編程比較好。也許哪一天，你靈感來了，編出一個比Netty更好的架構，一個更牛的軟體。
 
怎使用netty寫一個http長串連伺服器

我又看了下play的原始碼，play自訂handler裡的messageRecived:
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e)
throws Exception{
Invoker.invoke(new NettyInvokation(request, response, ctx, nettyRequest, e));}messageReceived結束後，worker線程就即將（還要去做一些系統預定的收尾工作）脫離這個request，也就是說，這個request不再會佔用worker了。但是
Invoker.invoke這個方法會在play架構內部的線程池裡提交一個任務來繼續處理request，完成真正的商務邏輯。
上面是play的做法，簡單總結一下就是可以通過在messageReceived中啟動一個新的線程或者向線程池提交任務的方式來完成request的商務邏輯處理部分，這樣不但可以保持長串連不關閉，而且不會佔用netty的worker進程。當處理商務邏輯完成後，再通過回呼函數，把結果用netty提供的HttpResponse返回到用戶端
請求-netty master-netty worker-（這時worker已經可以去處理其他的請求了）自己啟動一個新的線程-netty response
我沒測試，等有時間再看看吧