[置頂] Netty學習總結（1）——Netty入門介紹

1．Netty是什麼？

Netty是一個基於JAVA NIO類庫的異步通訊框架，它的架構特色是：異步非阻塞、基於事件驅動、高性能、高可靠性和高可定製性。

2．使用Netty可以作什麼？

• 開發異步、非阻塞的TCP網絡應用程序；

• 開發異步、非阻塞的UDP網絡應用程序；

• 開發異步文件傳輸應用程序；

• 開發異步HTTP服務端和客戶端應用程序；

• 提供對多種編解碼框架的集成，包括谷歌的Protobuf、Jboss marshalling、Java序列化、壓縮編解碼、XML解碼、字符串編解碼等，這些編解碼框架能夠被用戶直接使用；

• 提供形式多樣的編解碼基礎類庫，能夠很是方便的實現私有協議棧編解碼框架的二次定製和開發；

• 基於職責鏈模式的Pipeline-Handler機制，用戶能夠很是方便的對網絡事件進行攔截和定製；

• 全部的IO操做都是異步的，用戶能夠經過Future-Listener機制主動Get結果或者由IO線程操做完成以後主動Notify結果，用戶的業務線程不須要同步等待；

• IP黑白名單控制；

• 打印消息碼流；

• 流量控制和整形；

• 性能統計；

• 基於鏈路空閒事件檢測的心跳檢測

3．Netty在哪些行業獲得了應用？

• 互聯網行業：隨着網站規模的不斷擴大，系統併發訪問量也愈來愈高，傳統基於Tomcat等Web容器的垂直架構已經沒法知足需求，須要拆分應用進行服務化，以提升開發和維護效率。從組網狀況看，垂直的架構拆分以後，系統採用分佈式部署，各個節點之間須要遠程服務調用，高性能的RPC框架必不可少，Netty做爲異步高性能的通訊框架，每每做爲基礎通訊組件被這些RPC框架使用。

典型的應用有：阿里分佈式服務框架Dubbo的RPC框架使用Dubbo協議進行節點間通訊，Dubbo協議默認使用Netty做爲基礎通訊組件，用於實現各進程節點之間的內部通訊。它的架構圖以下：

其中，服務提供者和服務消費者之間，服務提供者、服務消費者和性能統計節點之間使用Netty進行異步/同步通訊。除了Dubbo以外，淘寶的消息中間件RocketMQ的消息生產者和消息消費者之間，也採用Netty進行高性能、異步通訊。

除了阿里系和淘寶系以外，不少其它的大型互聯網公司或者電商內部也已經大量使用Netty構建高性能、分佈式的網絡服務器。

• 遊戲行業：不管是手遊服務端、仍是大型的網絡遊戲，Java語言獲得了愈來愈普遍的應用。Netty做爲高性能的基礎通訊組件，它自己提供了TCP/UDP和HTTP協議棧，很是方便定製和開發私有協議棧。帳號登錄服務器、地圖服務器之間能夠方便的經過Netty進行高性能的通訊，架構示意圖以下：

• 大數據領域：經典的Hadoop的高性能通訊和序列化組件Avro的RPC框架，默認採用Netty進行跨節點通訊，它的Netty Service基於Netty框架二次封裝實現。

大數據計算每每採用多個計算節點和一個/N個彙總節點進行分佈式部署，各節點之間存在海量的數據交換。因爲Netty的綜合性能是目前各個成熟NIO框架中最高的，所以，每每會被選中用做大數據各節點間的通訊。

• 企業軟件：企業和IT集成須要ESB，Netty對多協議支持、私有協議定製的簡潔性和高性能是ESB RPC框架的首選通訊組件。事實上，不少企業總線廠商會選擇Netty做爲基礎通訊組件，用於企業的IT集成。

• 通訊行業：Netty的異步高性能、高可靠性和高成熟度的優勢，使它在通訊行業獲得了大量的應用。

4．使用傳統的Socket開發挺簡單的，我爲何要切換到NIO進行編程呢？

首先咱們看下傳統基於同步阻塞IO（BIO）的線程模型圖：

由上圖咱們能夠看出，傳統的同步阻塞IO通訊存在以下幾個問題：l線程模型存在致命缺陷：一鏈接一線程的模型致使服務端沒法承受大量客戶端的併發鏈接；

• 性能差：頻繁的線程上下文切換致使CPU利用效率不高；

• 可靠性差：因爲全部的IO操做都是同步的，因此業務線程只要進行IO操做，也會存在被同步阻塞的風險，這會致使系統的可靠性差，依賴外部組件的處理能力和網絡的狀況。

採用非阻塞IO（NIO）以後，同步阻塞IO的三個缺陷都將迎刃而解：

• Nio採用Reactor模式，一個Reactor線程聚合一個多路複用器Selector，它能夠同時註冊、監聽和輪詢成百上千個Channel，一個IO線程能夠同時併發處理N個客戶端鏈接，線程模型優化爲1：N（N < 進程可用的最大句柄數）或者 M : N (M一般爲CPU核數+ 1，N < 進程可用的最大句柄數)；

• 因爲IO線程總數有限，不會存在頻繁的IO線程之間上下文切換和競爭，CPU利用率高；

• 全部的IO操做都是異步的，即便業務線程直接進行IO操做，也不會被同步阻塞，系統再也不依賴外部的網絡環境和外部應用程序的處理性能。

因爲切換到NIO編程以後能夠爲系統帶來巨大的可靠性、性能提高，因此，目前採用NIO進行通訊已經逐漸成爲主流。

5．爲何不直接基於JDK的NIO類庫編程呢？

咱們經過JDK NIO服務端和客戶端的工做時序圖來回答下這個問題:

即使拋開代碼和NIO類庫複雜性不談，一個高性能、高可靠性的NIO服務端開發和維護成本都是很是高的，開發者須要具備豐富的NIO編程經驗和網絡維護經驗，不少時候甚至須要經過抓包來定位問題。也許開發出一套NIO程序須要1個月，可是它的穩定極可能須要1年甚至更長的時間，這也就是爲何我不建議直接使用JDK NIO類庫進行通訊開發的一個重要緣由。

下面再一塊兒看下JDK NIO客戶端的通訊時序圖：它一樣很是複雜:

6．爲何要選擇Netty框架？

Netty是業界最流行的NIO框架之一，它的健壯性、功能、性能、可定製性和可擴展性在同類框架中都是數一數二的，它已經獲得成百上千的商用項目驗證，例如Hadoop的RPC框架Avro使用Netty做爲通訊框架。不少其它業界主流的RPC和分佈式服務框架，也使用Netty來構建高性能的異步通訊能力。

Netty的優勢總結以下：

• API使用簡單，開發門檻低；

• 功能強大，預置了多種編解碼功能，支持多種主流協議；

• 定製能力強，能夠經過ChannelHandler對通訊框架進行靈活的擴展；

• 性能高，經過與其它業界主流的NIO框架對比，Netty的綜合性能最優；

• 成熟、穩定，Netty修復了已經發現的全部JDK NIO BUG，業務開發人員不須要再爲NIO的BUG而煩惱；

• 社區活躍，版本迭代週期短，發現的BUG能夠被及時修復，同時，更多的新功能會被加入；

• 經歷了大規模的商業應用考驗，質量獲得驗證。在互聯網、大數據、網絡遊戲、企業應用、電信軟件等衆多行業獲得成功商用，證實了它徹底知足不一樣行業的商用標準。

正是由於這些優勢，Netty逐漸成爲Java NIO編程的首選框架。

7．據說Netty各版本的API變化比較頻繁，我該如何選擇版本？

事實上，Netty各版本之間的API變動並無一些人講的那麼可怕，最大的變動就是3.X系列到4.X/5.X的變動，Netty不只僅重構了包路徑，對於以前一直想改可是考慮到前向兼容性沒改的類庫進行了優化和修改。此次變動的主要緣由是Netty脫離了Jboss獨立發展，這對於Netty的長遠發展是件好事。

在我看來，Netty4.X系列版本的架構和API設計更加合理，同時，它提供了更多新的特性。所以，我我的建議用戶能夠選擇4.X系列版本，以避免將來升級遇到困難和問題。

對於已經使用3.X系列版本的用戶，若是現有功能已經知足需求，短時間內暫時不須要升級。若是須要使用更多新特性和功能，建議在充分評估以後進行升級，這可能須要一些工做量。

因爲Netty5最新版本仍處於測試階段，從學習和研究角度能夠試用一下，Netty5相比於Netty4是前向兼容的，所以，將來用戶升級到Netty5會更加容易。

8．Netty和Mina 我究竟該選擇哪一個？

根據個人經驗，不管選擇哪一個，都是個正確的選擇。二者各有千秋，Netty在內存管理方面更勝一籌，綜合性能也更優。可是，API變動的管理和兼容性作的不是太好。相比於Netty，Mina的前向兼容性、內聚的可維護性功能更多，例如JMX的集成、性能統計、狀態機等。

建議用戶能夠根據本身對二者的熟悉程度和實際項目需求，作出最佳選擇。若是你鎖定了二者，自己就意味着你作出了正確選擇，不須要再糾結於選擇哪一個而和領導、同事吵得面紅耳赤。

9．Netty使用簡單嗎？

Netty的基礎開發和應用很是簡單，開發一個Echo服務端只須要28行代碼，開發對應的Echo客戶端只須要26行代碼！

可是，若是你要利用它進行私有協議棧開發、HTTP服務端和客戶端開發等，仍然須要深刻的學習Netty的一些高級類庫和功能，瞭解Netty的設計原理。只有這樣，才能恰到好處的使用Netty，爲項目和公司帶來更大的價值。

10．有沒有Netty相關的書籍供學習和參考？

目前市面上有兩本Netty書籍，《Netty in Action》和 《Netty權威指南》。

11．我是大學畢業生，正在學習Java NIO，據說掌握Netty等NIO框架對將來找工做頗有幫助？

從個人經驗和目前Netty的行業應用狀況，確實如此。下面咱們簡單看下以Netty招聘爲關鍵字的搜索結果：

隨着移動互聯網和物聯網的發展，Netty在非傳統行業的應用也日益普遍，例如手機移動推送服務、智能傢俱、物聯網關等。