一篇文章，讀懂 Netty 的高性能架構之道

時間 2019-11-11

原文原文鏈接

Netty是一個高性能、異步事件驅動的NIO框架，它提供了對TCP、UDP和文件傳輸的支持，做爲一個異步NIO框架，Netty的全部IO操做都是異步非阻塞的，經過Future-Listener機制，用戶能夠方便的主動獲取或者經過通知機制得到IO操做結果。算法

做爲當前最流行的NIO框架，Netty在互聯網領域、大數據分佈式計算領域、遊戲行業、通訊行業等得到了普遍的應用，一些業界著名的開源組件也基於Netty的NIO框架構建。編程

爲何選擇Netty後端

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

經過對Netty的分析，咱們將它的優勢總結以下:瀏覽器

API使用簡單，開發門檻低；緩存
功能強大，預置了多種編解碼功能，支持多種主流協議；安全
定製能力強，能夠經過ChannelHandler對通訊框架進行靈活地擴展；服務器
性能高，經過與其餘業界主流的NIO框架對比，Netty的綜合性能最優；網絡
成熟、穩定，Netty修復了已經發現的全部JDK NIO BUG，業務開發人員不須要再爲NIO的BUG而煩惱；
社區活躍，版本迭代週期短，發現的BUG能夠被及時修復，同時，更多的新功能會加入；
經歷了大規模的商業應用考驗，質量獲得驗證。在互聯網、大數據、網絡遊戲、企業應用、電信軟件等衆多行業獲得成功商用，證實了它已經徹底可以知足不一樣行業的商業應用了。

Netty架構分析

Netty 採用了比較典型的三層網絡架構進行設計，邏輯架構圖以下所示：

第一層：Reactor 通訊調度層，它由一系列輔助類完成，包括 Reactor 線程 NioEventLoop 以及其父類、NioSocketChannel/NioServerSocketChannel 以及其父類、ByteBuffer 以及由其衍生出來的各類 Buffer、Unsafe 以及其衍生出的各類內部類等。該層的主要職責就是監聽網絡的讀寫和鏈接操做，負責將網絡層的數據讀取到內存緩衝區中，而後觸發各類網絡事件，例如鏈接建立、鏈接激活、讀事件、寫事件等等，將這些事件觸發到 PipeLine 中，由 PipeLine 充當的職責鏈來進行後續的處理。

第二層：職責鏈 PipeLine，它負責事件在職責鏈中的有序傳播，同時負責動態的編排職責鏈，職責鏈能夠選擇監聽和處理本身關心的事件，它能夠攔截處理和向後/向前傳播事件，不一樣的應用的 Handler 節點的功能也不一樣，一般狀況下，每每會開發編解碼 Hanlder 用於消息的編解碼，它能夠將外部的協議消息轉換成內部的 POJO 對象，這樣上層業務側只須要關心處理業務邏輯便可，不須要感知底層的協議差別和線程模型差別，實現了架構層面的分層隔離。

第三層：業務邏輯處理層，能夠分爲兩類：

純粹的業務邏輯處理，例如訂單處理。
應用層協議管理，例如HTTP協議、FTP協議等。

接下來，我從影響通訊性能的三個方面（I/O模型、線程調度模型、序列化方式）來談談Netty的架構。

I/O模型

傳統同步阻塞I/O模式以下圖所示：

它的弊端有不少：

性能問題：一鏈接一線程模型致使服務端的併發接入數和系統吞吐量受到極大限制；
可靠性問題：因爲I/O操做採用同步阻塞模式，當網絡擁塞或者通訊對端處理緩慢會致使I/O線程被掛住，阻塞時間沒法預測；
可維護性問題：I/O線程數沒法有效控制、資源沒法有效共享（多線程併發問題），系統可維護性差；

幾種I/O模型的功能和特性對比：

Netty的I/O模型基於非阻塞I/O實現，底層依賴的是JDK NIO框架的Selector。

Selector提供選擇已經就緒的任務的能力。簡單來說，Selector會不斷地輪詢註冊在其上的Channel，若是某個Channel上面有新的TCP鏈接接入、讀和寫事件，這個Channel就處於就緒狀態，會被Selector輪詢出來，而後經過SelectionKey能夠獲取就緒Channel的集合，進行後續的I/O操做。

一個多路複用器Selector能夠同時輪詢多個Channel，因爲JDK1.5_update10版本（+）使用了epoll()代替傳統的select實現，因此它並無最大鏈接句柄1024/2048的限制。這也就意味着只須要一個線程負責Selector的輪詢，就能夠接入成千上萬的客戶端，這確實是個很是巨大的技術進步。

使用非阻塞I/O模型以後，Netty解決了傳統同步阻塞I/O帶來的性能、吞吐量和可靠性問題。

線程調度模型

經常使用的Reactor線程模型有三種，分別以下：

Reactor單線程模型：Reactor單線程模型，指的是全部的I/O操做都在同一個NIO線程上面完成。對於一些小容量應用場景，可使用單線程模型。
Reactor多線程模型：Rector多線程模型與單線程模型最大的區別就是有一組NIO線程處理I/O操做。主要用於高併發、大業務量場景。
主從Reactor多線程模型：主從Reactor線程模型的特色是服務端用於接收客戶端鏈接的再也不是個1個單獨的NIO線程，而是一個獨立的NIO線程池。利用主從NIO線程模型，能夠解決1個服務端監聽線程沒法有效處理全部客戶端鏈接的性能不足問題。

事實上，Netty的線程模型並不是固定不變，經過在啓動輔助類中建立不一樣的EventLoopGroup實例並經過適當的參數配置，就能夠支持上述三種Reactor線程模型。

在大多數場景下，並行多線程處理能夠提高系統的併發性能。可是，若是對於共享資源的併發訪問處理不當，會帶來嚴重的鎖競爭，這最終會致使性能的降低。爲了儘量的避免鎖競爭帶來的性能損耗，能夠經過串行化設計，即消息的處理儘量在同一個線程內完成，期間不進行線程切換，這樣就避免了多線程競爭和同步鎖。

爲了儘量提高性能，Netty採用了串行無鎖化設計，在I/O線程內部進行串行操做，避免多線程競爭致使的性能降低。表面上看，串行化設計彷佛CPU利用率不高，併發程度不夠。可是，經過調整NIO線程池的線程參數，能夠同時啓動多個串行化的線程並行運行，這種局部無鎖化的串行線程設計相比一個隊列-多個工做線程模型性能更優。

序列化方式

影響序列化性能的關鍵因素總結以下：

序列化後的碼流大小（網絡帶寬佔用）
序列化&反序列化的性能（CPU資源佔用）
併發調用的性能表現：穩定性、線性增加、偶現的時延毛刺等

對Java序列化和二進制編碼分別進行性能測試，編碼100萬次，測試結果代表：Java序列化的性能只有二進制編碼的6.17%左右。

Netty默認提供了對Google Protobuf的支持，經過擴展Netty的編解碼接口，用戶能夠實現其它的高性能序列化框架，例如Thrift的壓縮二進制編解碼框架。

不一樣的應用場景對序列化框架的需求也不一樣，對於高性能應用場景Netty默認提供了Google的Protobuf二進制序列化框架，若是用戶對其它二進制序列化框架有需求，也能夠基於Netty提供的編解碼框架擴展實現。

Netty架構剖析之可靠性

Netty面臨的可靠性挑戰：

做爲RPC框架的基礎網絡通訊框架，一旦故障將致使沒法進行遠程服務（接口）調用。
做爲應用層協議的基礎通訊框架，一旦故障將致使應用協議棧沒法正常工做。
網絡環境複雜（例如手遊或者推送服務的GSM/3G/WIFI網絡），故障不可避免，業務卻不能中斷。

從應用場景看，Netty是基礎的通訊框架，一旦出現Bug，輕則須要重啓應用，重則可能致使整個業務中斷。它的可靠性會影響整個業務集羣的數據通訊和交換，在當今以分佈式爲主的軟件架構體系中，通訊中斷就意味着整個業務中斷，分佈式架構下對通訊的可靠性要求很是高。

從運行環境看，Netty會面臨惡劣的網絡環境，這就要求它自身的可靠性要足夠好，平臺可以解決的可靠性問題須要由Netty自身來解決，不然會致使上層用戶關注過多的底層故障，這將下降Netty的易用性，同時增長用戶的開發和運維成本。

Netty的可靠性是如此重要，它的任何故障均可能會致使業務中斷，蒙受巨大的經濟損失。所以，Netty在版本的迭代中不斷加入新的可靠性特性來知足用戶日益增加的高可靠和健壯性需求。

鏈路有效性檢測

Netty提供的心跳檢測機制分爲三種：

讀空閒，鏈路持續時間t沒有讀取到任何消息；
寫空閒，鏈路持續時間t沒有發送任何消息；
讀寫空閒，鏈路持續時間t沒有接收或者發送任何消息。

當網絡發生單通、鏈接被防火牆Hang住、長時間GC或者通訊線程發生非預期異常時，會致使鏈路不可用且不易被及時發現。特別是異常發生在凌晨業務低谷期間，當早晨業務高峯期到來時，因爲鏈路不可用會致使瞬間的大批量業務失敗或者超時，這將對系統的可靠性產生重大的威脅。

從技術層面看，要解決鏈路的可靠性問題，必須週期性的對鏈路進行有效性檢測。目前最流行和通用的作法就是心跳檢測。

心跳檢測機制分爲三個層面：

TCP層面的心跳檢測，即TCP的Keep-Alive機制，它的做用域是整個TCP協議棧；
協議層的心跳檢測，主要存在於長鏈接協議中。例如SMPP協議；
應用層的心跳檢測，它主要由各業務產品經過約定方式定時給對方發送心跳消息實現。

心跳檢測的目的就是確認當前鏈路可用，對方活着而且可以正常接收和發送消息。作爲高可靠的NIO框架，Netty也提供了基於鏈路空閒的心跳檢測機制：

讀空閒，鏈路持續時間t沒有讀取到任何消息；
寫空閒，鏈路持續時間t沒有發送任何消息；
讀寫空閒，鏈路持續時間t沒有接收或者發送任何消息。

流量整形

流量整形（Traffic Shaping）是一種主動調整流量輸出速率的措施。Netty的流量整形有兩個做用：

防止因爲上下游網元性能不均衡致使下游網元被壓垮，業務流程中斷；
防止因爲通訊模塊接收消息過快，後端業務線程處理不及時致使的「撐死」問題。

流量整形的原理示意圖以下：

流量整形（Traffic Shaping）是一種主動調整流量輸出速率的措施。一個典型應用是基於下游網絡結點的TP指標來控制本地流量的輸出。流量整形與流量監管的主要區別在於，流量整形對流量監管中須要丟棄的報文進行緩存——一般是將它們放入緩衝區或隊列內，也稱流量整形（Traffic Shaping，簡稱TS）。當令牌桶有足夠的令牌時，再均勻的向外發送這些被緩存的報文。流量整形與流量監管的另外一區別是，整形可能會增長延遲，而監管幾乎不引入額外的延遲。

Netty支持兩種流量整形模式：

全局流量整形：全局流量整形的做用範圍是進程級的，不管你建立了多少個Channel，它的做用域針對全部的Channel。用戶能夠經過參數設置：報文的接收速率、報文的發送速率、整形週期。
鏈路級流量整形：單鏈路流量整形與全局流量整形的最大區別就是它以單個鏈路爲做用域，能夠對不一樣的鏈路設置不一樣的整形策略。

優雅停機

Netty的優雅停機三部曲：

再也不接收新消息
退出前的預處理操做
資源的釋放操做

Java的優雅停機一般經過註冊JDK的ShutdownHook來實現，當系統接收到退出指令後，首先標記系統處於退出狀態，再也不接收新的消息，而後將積壓的消息處理完，最後調用資源回收接口將資源銷燬，最後各線程退出執行。

一般優雅退出須要有超時控制機制，例如30S，若是到達超時時間仍然沒有完成退出前的資源回收等操做，則由停機腳本直接調用kill -9 pid，強制退出。

在實際項目中，Netty做爲高性能的異步NIO通訊框架，每每用做基礎通訊框架負責各類協議的接入、解析和調度等，例如在RPC和分佈式服務框架中，每每會使用Netty做爲內部私有協議的基礎通訊框架。
當應用進程優雅退出時，做爲通訊框架的Netty也須要優雅退出，主要緣由以下：

儘快的釋放NIO線程、句柄等資源；
若是使用flush作批量消息發送，須要將積攢在發送隊列中的待發送消息發送完成；
正在write或者read的消息，須要繼續處理；
設置在NioEventLoop線程調度器中的定時任務，須要執行或者清理。

Netty架構剖析之安全性

Netty面臨的安全挑戰：

對第三方開放
做爲應用層協議的基礎通訊框架

安全威脅場景分析：

對第三方開放的通訊框架：若是使用Netty作RPC框架或者私有協議棧，RPC框架面向非授信的第三方開放，例如將內部的一些能力經過服務對外開放出去，此時就須要進行安全認證，若是開放的是公網IP，對於安全性要求很是高的一些服務，例如在線支付、訂購等，須要經過SSL/TLS進行通訊。
應用層協議的安全性。做爲高性能、異步事件驅動的NIO框架，Netty很是適合構建上層的應用層協議。因爲絕大多數應用層協議都是公有的，這意味着底層的Netty須要向上層提供通訊層的安全傳輸功能。

SSL/TLS

Netty安全傳輸特性：

支持SSL V2和V3
支持TLS
支持SSL單向認證、雙向認證和第三方CA認證。

SSL單向認證流程圖以下：

Netty經過SslHandler提供了對SSL的支持，它支持的SSL協議類型包括：SSL V二、SSL V3和TLS。

單向認證：單向認證，即客戶端只驗證服務端的合法性，服務端不驗證客戶端。
雙向認證：與單向認證不一樣的是服務端也須要對客戶端進行安全認證。這就意味着客戶端的自簽名證書也須要導入到服務端的數字證書倉庫中。
CA認證：基於自簽名的SSL雙向認證，只要客戶端或者服務端修改了密鑰和證書，就須要從新進行簽名和證書交換，這種調試和維護工做量是很是大的。所以，在實際的商用系統中每每會使用第三方CA證書頒發機構進行簽名和驗證。咱們的瀏覽器就保存了幾個經常使用的CA_ROOT。每次鏈接到網站時只要這個網站的證書是通過這些CA_ROOT簽名過的。就能夠經過驗證了。

可擴展的安全特性

經過Netty的擴展特性，能夠自定義安全策略：

IP地址黑名單機制
接入認證
敏感信息加密或者過濾機制

IP地址黑名單是比較經常使用的弱安全保護策略，它的特色就是服務端在與客戶端通訊的過程當中，對客戶端的IP地址進行校驗，若是發現對方IP在黑名單列表中，則拒絕與其通訊，關閉鏈路。

接入認證策略很是多，一般是較強的安全認證策略，例如基於用戶名+密碼的認證，認證內容每每採用加密的方式，例如Base64+AES等。

Netty架構剖析之擴展性

經過Netty的擴展特性，能夠自定義安全策略：

線程模型可擴展
序列化方式可擴展
上層協議棧可擴展
提供大量的網絡事件切面，方便用戶功能擴展

Netty的架構可擴展性設計理念以下：

判斷擴展點，事先預留相關擴展接口，給用戶二次定製和擴展使用；
主要功能點都基於接口編程，方便用戶定製和擴展。

精彩問答

問：據我以前瞭解到，Java的NIO selector底層在Windows下的實現是起兩個隨機端口互聯來監測鏈接或讀寫事件，在Linux上是利用管道實現的；我有遇到過這樣的需求，須要佔用不少個固定端口作服務端，若是在Windows下，利用NIO框架（Mina或Netty）就有可能會形成端口衝突，這種狀況有什麼好的解決方案嗎？

你說的問題確實存在，Linux使用Pipe實現網絡監聽，Windows要啓動端口。目前沒有更好的辦法，建議的方式是做爲服務端的端口能夠規劃一個範圍，而後根據節點和進程信息動態生成，若是發現端口衝突，能夠在規劃範圍內基於算法從新生成一個新的端口。

問：請我，我如今將Spring與Netty作了整合，使用Spring的Service開啓 Netty主線程，可是中止整個運行容器的時候，Netty的TCP Server端口不能釋放？退出處理時，有什麼好的辦法釋放Netty Server端口麼？

實際上，由誰拉起Netty 主線程並不重要。咱們須要作的就是當應用容器退出的時候（Spring Context銷燬），在退出以前調用Netty 的優雅退出接口便可實現端口、NIO線程資源的釋放。請參考這篇文章：http://www.infoq.com/cn/articles/netty-elegant-exit-mechanism-and-principles

問：適合用Netty寫Web通訊麼?

Netty不是Web框架，沒法解析JSP、HTML、JS等，可是它能夠作Web 通訊，例如可使用Netty重寫Tomcat的HTTP/HTTPS 通訊協議棧。

問：能不能講解一下Netty的串行無鎖化設計，如何在串行和並行中達到最優？

爲了儘量提高性能，Netty採用了串行無鎖化設計，在IO線程內部進行串行操做，避免多線程競爭致使的性能降低。表面上看，串行化設計彷佛CPU利用率不高，併發程度不夠。可是，經過調整NIO線程池的線程參數，能夠同時啓動多個串行化的線程並行運行，這種局部無鎖化的串行線程設計相比一個隊列-多個工做線程模型性能更優。Netty的NioEventLoop讀取到消息以後，直接調用ChannelPipeline的fireChannelRead(Object msg)，只要用戶不主動切換線程，一直會由NioEventLoop調用到用戶的Handler，期間不進行線程切換，這種串行化處理方式避免了多線程操做致使的鎖的競爭，從性能角度看是最優的。

REFER:
Netty系列之Netty高性能之道
http://www.infoq.com/cn/articles/netty-high-performance/http://www.infoq.com/cn/articles/netty-high-performance/
談談如何使用Netty開發實現高性能的RPC服務器
http://www.cnblogs.com/jietang/p/5615681.html