前言
本篇為《Netty剖析》系列最后一篇，主要對Netty做簡單的總結(jié)，如果對Netty的細節(jié)感興趣，可以閱讀本系列的另外兩篇：
Netty適用場景
Netty只是一套網(wǎng)絡框架，它不可能適用于所有場景，所以選用Netty前最好能想清楚它是否能很好的應對自己的需求。想要知道Netty的適用場景最好的方式就是從Netty本身的特性出發(fā)進行思考，具體可參考本系列第一篇Netty剖析 - 1. 基礎中"Netty的特色"章節(jié)，基于此，如果你的需求屬于下列場景，則Netty會比較適合你，包括：
- 高并發(fā)，實時處理，如：游戲服務器，聊天服務器，SOA調(diào)用框架，RPC框架等
- 對網(wǎng)絡協(xié)議（傳輸層與應用層）有一定的定制需求
- 一套代碼可能需要同時支持BIO和NIO
而其他情況，Netty并一不定適合，如：
- 需求較簡單的網(wǎng)絡應用，則不必使用Netty，畢竟在能滿足需求的基礎上，越簡單越好
- 單次請求處理耗時較長的應用，這種情況下NIO沒有優(yōu)勢，此時使用BIO的方式可能效果會更好
Netty支持的協(xié)議
Netty框架本身已經(jīng)對常用的協(xié)議進行了實現(xiàn)，包括：
- 應用層：HTTP，WebSocket，HTTP2，Redis，SMTP，DNS，MQTT，SSL，STARTTLS ，RTSP
- 傳輸層：TCP，UDP，SCTP，UDT等
- 其他：Protobuf，gzip
可以說，一般的應用使用Netty本身的支持就能滿足大部分需求，剩下的關注自己的業(yè)務即可
Netty & MINA & Jetty
Netty和MINA經(jīng)常會放在一起比較，主要是因為兩個框架有很多相似的地方，或者說它們本身就是一對兄弟 -- 都是基于Java NIO封裝的一個網(wǎng)絡框架。其實更深入的了解會發(fā)現(xiàn)，Netty的作者Trustin Lee也是MINA的作者（當然已經(jīng)不繼續(xù)參與了），據(jù)說他是對MINA的代碼不滿意，才重新寫了Netty，所以看Netty的代碼經(jīng)常能看到MINA的影子，但就現(xiàn)在來說Netty的社區(qū)遠比MINA要活躍，迭代頻率也更高，大部分的特性也優(yōu)于MINA
至于Jetty之所以會拿來比較，主要是因為和Netty名字類似，但其實這兩者并沒有很大的可比性，因為Jetty是一個輕量級的servlet容器，而Netty是一個基于NIO的異步網(wǎng)絡編程框架，基于Netty可以實現(xiàn)自己的servlet容器或者其它網(wǎng)絡應用
相關項目
很多項目內(nèi)部都使用Netty作為其網(wǎng)絡處理模塊，包括：
總結(jié)
本系列主要針對Netty的基礎概念，框架結(jié)構(gòu)及特色機制做了淺顯的分析，由于本人水平有限，難免有錯誤和不合適的地方，望大家不吝指出。Netty本身是一個優(yōu)秀的框架，其源碼的層次和結(jié)構(gòu)也很清晰，值得一讀；平常很多人說熟悉網(wǎng)絡，但是大部分人也僅僅只是知道一些皮毛（也包括我自己），其實，想要寫一個健壯易用的網(wǎng)絡框架并不容易，如果需要同時支持高并發(fā)，那更是難上加難，而Netty在這一點就做得很出色，不僅體現(xiàn)在其本身優(yōu)秀的代碼組織，更多的還是把一些已有的功能和思想進行合適的組裝和適當?shù)膬?yōu)化。另外，結(jié)合當今另一個炙手可熱的高性能服務器Nginx會發(fā)現(xiàn)，這兩者的思想有很多相通之處，如都是基于事件機制，都分為主工作組與子工作組，都是在PipeLine上設置一系列的Handler進行數(shù)據(jù)處理，都有通過邏輯映射增強內(nèi)存效率的設計等等，很有意思，感興趣的小伙伴可以找尋相關資料進行深入研究
