對於Netty的十一個疑問

【說明】本文原載於碼農 IO（manong.io）官方微信 developerWorks，轉載、引用請註明出處及作者。

  1．Netty 是什麼？

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

  2．使用 Netty 能夠做什麼？

    開發非同步、非阻塞的 TCP 網路應用程式；


    開發非同步、非阻塞的 UDP 網路應用程式；


    開發非同步檔案傳輸應用程式；


    開發非同步 HTTP 服務端和客戶端應用程式；


    提供對多種編解碼框架的整合，包括谷歌的 Protobuf、Jbossmarshalling、Java 序列化、壓縮編解碼、XML 解碼、字串編解碼等，這些編解碼框架可以被使用者直接使用；


    提供形式多樣的編解碼基礎類庫，可以非常方便的實現私有協議棧編解碼框架的二次定製和開發；


    基於職責鏈模式的 Pipeline-Handler 機制，使用者可以非常方便的對網路事件進行攔截和定製；


    所有的 IO 操作都是非同步的，使用者可以通過 Future-Listener 機制主動 Get 結果或者由 IO 執行緒操作完成之後主動 Notify 結果，使用者的業務執行緒不需要同步等待；


    IP 黑白名單控制；


    列印訊息碼流；


    流量控制和整形；


    效能統計；


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


    ……

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

       網際網路行業：隨著網站規模的不斷擴大，系統併發訪問量也越來越高，傳統基於 Tomcat 等 Web 容器的垂直架構已經無法滿足需求，需要拆分應用進行服務化，以提高開發和維護效率。從組網情況看，垂直的架構拆分之後，系統採用分散式部署，各個節點之間 需要遠端服務呼叫，高效能的 RPC 框架必不可少，Netty 作為非同步高效能的通訊框架，往往作為基礎通訊元件被這些 RPC 框架使用。

        典型的應用有：阿里分散式服務框架 Dubbo 的 RPC 框架使用 Dubbo 協議進行節點間通訊，Dubbo 協議預設使用 Netty 作為基礎通訊元件，用於實現各程序節點之間的內部通訊。它的架構圖如下：

 圖1-1 Dubbo 節點間呼叫關係圖

        其中，服務提供者和服務消費者之間，服務提供者、服務消費者和效能統計節點之間使用 Netty 進行非同步/同步通訊。


        除了 Dubbo 之外，淘寶的訊息中介軟體 RocketMQ 的訊息生產者和訊息消費者之間，也採用 Netty 進行高效能、非同步通訊。


        除了阿里系和淘寶系之外，很多其它的大型網際網路公司或者電商內部也已經大量使用 Netty 構建高效能、分散式的網路伺服器。


       遊戲行業：無論是手遊服務端、還是大型的網路遊戲，Java 語言得到了越來越廣泛的應用。Netty 作為高效能的基礎通訊元件，它本身提供了 TCP/UDP 和 HTTP 協議棧，非常方便定製和開發私有協議棧。賬號登陸伺服器、地圖伺服器之間可以方便的通過 Netty 進行高效能的通訊，架構示意圖如下：


        圖1-2 Netty 在遊戲伺服器架構中的應用

    大資料領域：經典的 Hadoop 的高效能通訊和序列化元件 Avro 的 RPC 框架，預設採用 Netty 進行跨節點通訊，它的 Netty Service 基於 Netty 框架二次封裝實現。


        大資料計算往往採用多個計算節點和一個/N個彙總節點進行分散式部署，各節點之間存在海量的資料交換。由於 Netty 的綜合性能是目前各個成熟 NIO 框架中最高的，因此，往往會被選中用作大資料各節點間的通訊。


        企業軟體：企業和 IT 整合需要 ESB，Netty 對多協議支援、私有協議定製的簡潔性和高效能是 ESB RPC 框架的首選通訊元件。事實上，很多企業匯流排廠商會選擇 Netty 作為基礎通訊元件，用於企業的 IT 整合。


    通訊行業：Netty 的非同步高效能、高可靠性和高成熟度的優點，使它在通訊行業得到了大量的應用。

        4．使用傳統的 Socket 開發挺簡單的，我為什麼要切換到 NIO 進行程式設計呢？

   首先我們看下傳統基於同步阻塞 IO（BIO）的執行緒模型圖：




圖1-3 同步阻塞 IO（BIO）執行緒模型圖
 由上圖我們可以看出，傳統的同步阻塞 IO 通訊存在如下幾個問題：


    執行緒模型存在致命缺陷：一連線一執行緒的模型導致服務端無法承受大量客戶端的併發連線；


    效能差：頻繁的執行緒上下文切換導致 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 服務端和客戶端的工作時序圖來回答下這個問題：

        圖1-4 JDK NIO 服務端建立和通訊序列圖

        即便拋開程式碼和 NIO 類庫複雜性不談，一個高效能、高可靠性的 NIO 服務端開發和維護成本都是非常高的，開發者需要具有豐富的 NIO 程式設計經驗和網路維護經驗，很多時候甚至需要通過抓包來定位問題。也許開發出一套 NIO 程式需要 1 個月，但是它的穩定很可能需要 1 年甚至更長的時間，這也就是為什麼我不建議直接使用 JDK NIO 類庫進行通訊開發的一個重要原因。


        下面再一起看下 JDK NIO 客戶端的通訊時序圖：它同樣非常複雜。


        圖1-5 JDK NIO 客戶端建立和通訊序列圖

        6．為什麼要選擇 Netty 框架？

        Netty 是業界最流行的 NIO 框架之一，它的健壯性、功能、效能、可定製性和可擴充套件性在同類框架中都是首屈一指的，它已經得到成百上千的商用專案驗證，例如 Hadoop 的 RPC 框架 Avro 使用 Netty 作為通訊框架。很多其它業界主流的 RPC 和分散式服務框架，也使用 Netty 來構建高效能的非同步通訊能力。


        Netty 的優點總結如下：


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


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


    定製能力強，可以通過 ChannelHandler 對通訊框架進行靈活的擴充套件；


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


    社群活躍，版本迭代週期短，發現的 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 相關的書籍供學習和參考？

        2014 年5-6 月，中國第一本學習 Netty 的教材《Netty 權威指南》將由電子工業出版社博文視點出版。


        全書共 23 個章節，從 JAVA IO 的歷史演進講起，包括 NIO 基礎入門、Netty 基礎入門、Netty 編解碼框架的使用和開發、UDP 開發、非同步檔案傳輸、基於 Netty 的非同步 HTTP 協議棧開發和應用、半包解碼器的定製和使用、私有協議棧的設計和開發、行業應用、架構剖析、核心類庫的功能講解和原始碼分析等。


        無論你是初學者，還是 NIO 高手，都能從本書中汲取營養，為掌握乃至精通 Netty 提供快捷通道。

        11．我是大學畢業生，正在學習 Java，聽說掌握 Netty 等 NIO 框架找工作會相對容易一些，是真的嗎？

        從我的經驗和 Netty 行業應用來看，前景無限好！下面我們通過谷歌搜尋簡單看下現在市場對 Netty 和 Mina 的需求。

        就個人而言，我無意冒犯或者貶低其它技術，但是，相比於 WEB 前臺開發/精通 Spring 框架等，精通和熟悉 Netty 的人畢竟是非常少的。一個原因是非同步網路程式設計的複雜性，另一個原因是中國的 NIO 程式設計正處於方興未艾階段，市場需求在逐漸增大，開始出現井噴。但是精通 NIO 程式設計和具有相關經驗的人太少，導致供需不平衡，這也是最近 Netty 越來越火的一個重要原因，市場需求決定技術導向。

原文連結：http://www.open-open.com/news/view/1d31d83