Netty高性能架構的理解之道

Netty的簡單介紹

Netty 是一個 NIO client-server(客戶端服務器)框架，使用 Netty 能夠快速開發網絡應用，例如服務器和客戶 端協議。 Netty 提供了一種新的方式來使開發網絡應用程序，這種新的方式使得它很容易使用和有很強的擴展性。 Netty 的內部實現時很複雜的，可是 Netty 提供了簡單易用的 api 從網絡處理代碼中解耦業務邏輯。 Netty 是徹底基 於 NIO 實現的，因此整個 Netty 都是異步的。
簡單點說就是Netty提供了一個簡單，間接的方法來操做網絡之間的通信。

使用 Netty 可以作什麼？

• 開發異步、非阻塞的 TCP 網絡應用程序；
• 開發異步、非阻塞的 UDP 網絡應用程序；
• 開發異步文件傳輸應用程序；
• 開發異步 HTTP 服務端和客戶端應用程序；
• 提供對多種編解碼框架的集成，包括谷歌的 Protobuf、Jbossmarshalling、Java 序列化、壓縮編解碼、XML 解碼、字符串編解碼等，這些編解碼框架能夠被用戶直接使用；
• 提供形式多樣的編解碼基礎類庫，能夠很是方便的實現私有協議棧編解碼框架的二次定製和開發；
• 基於職責鏈模式的 Pipeline-Handler 機制，用戶能夠很是方便的對網絡事件進行攔截和定製；
• 全部的 IO 操做都是異步的，用戶能夠經過 Future-Listener 機制主動 Get 結果或者由 IO 線程操做完成以後主動 Notify 結果，用戶的業務線程不須要同步等待；
• IP 黑白名單控制；
• 打印消息碼流；
• 流量控制和整形；
• 性能統計；
• 基於鏈路空閒事件檢測的心跳檢測
• ……

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

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

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

圖、Dubbo 節點間調用關係圖

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

除了阿里系和淘寶系以外，不少其它的大型互聯網公司或者電商內部也已經大量使用 Netty 構建高性能、分佈式的網絡服務器。
遊戲行業：不管是手遊服務端、仍是大型的網絡遊戲，Java 語言獲得了愈來愈普遍的應用。Netty 做爲高性能的基礎通訊組件，它自己提供了 TCP/UDP 和 HTTP 協議棧，很是方便定製和開發私有協議棧。帳號登錄服務器、地圖服務器之間能夠方便的經過 Netty 進行高性能的通訊，架構示意圖以下：

圖、Netty 在遊戲服務器架構中的應用

大數據領域：經典的 Hadoop 的高性能通訊和序列化組件 Avro 的 RPC 框架，默認採用 Netty 進行跨節點通訊，它的 Netty Service 基於 Netty 框架二次封裝實現。
大數據計算每每採用多個計算節點和一個/N個彙總節點進行分佈式部署，各節點之間存在海量的數據交換。因爲 Netty 的綜合性能是目前各個成熟 NIO 框架中最高的，所以，每每會被選中用做大數據各節點間的通訊。
企業軟件：企業和 IT 集成須要 ESB，Netty 對多協議支持、私有協議定製的簡潔性和高性能是 ESB RPC 框架的首選通訊組件。事實上，不少企業總線廠商會選擇 Netty 做爲基礎通訊組件，用於企業的 IT 集成。
通訊行業：Netty 的異步高性能、高可靠性和高成熟度的優勢，使它在通訊行業獲得了大量的應用。

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

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

圖、 同步阻塞 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 進行通訊已經逐漸成爲主流。

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

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

圖、JDK NIO 服務端建立和通訊序列圖

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

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

圖、JDK NIO 客戶端建立和通訊序列圖

不選擇JAVA原生NIO和IO的緣由

基於IO的經典同步堵塞模型：

經典的IO模型也就是傳統的服務器端同步阻塞I/O處理（也就是BIO，Blocking I/O）的經典編程模型，當咱們每獲得一個新的鏈接時，就會開啓一個線程來處理這個鏈接的任務。之因此使用多線程，主要緣由在於socket.accept()、socket.read()、socket.write()三個主要函數都是同步阻塞的，當一個鏈接在處理I/O的時候，系統是阻塞的，若是是單線程的話必然就掛死在那裏；但CPU是被釋放出來的，開啓多線程，就可讓CPU去處理更多的事情。

所以這個模型最本質的問題在於，嚴重依賴於線程。但線程是很」貴」的資源，主要表如今：

1. 線程的建立和銷燬成本很高，在Linux這樣的操做系統中，線程本質上就是一個進程。建立和銷燬都是重量級的系統函數。
   線程自己佔用較大內存，像Java的線程棧，通常至少分配512K～1M的空間，若是系統中的線程數過千，恐怕整個JVM的內存都會被吃掉一半。

2. 線程的切換成本是很高的。操做系統發生線程切換的時候，須要保留線程的上下文，而後執行系統調用。若是線程數太高，可能執行線程切換的時間甚至會大於線程執行的時間，這時候帶來的表現每每是系統load偏高、CPU sy使用率特別高（超過20%以上)，致使系統幾乎陷入不可用的狀態。

3. 容易形成鋸齒狀的系統負載。由於系統負載是用活動線程數或CPU核心數，一旦線程數量高但外部網絡環境不是很穩定，就很容易形成大量請求的結果同時返回，激活大量阻塞線程從而使系統負載壓力過大。

基於NIO的異步模型：

NIO是一種同步非阻塞的I/O模型，也是I/O多路複用的基礎，並且已經被愈來愈多地應用到大型應用服務器，成爲解決高併發與大量鏈接、I/O處理問題的有效方式。

不使用NIO的緣由：

1. NIO的類庫和API繁雜。須要不少額外的技能作鋪墊。例如須要很熟悉Java多線程編程、Selector線程模型。致使工做量和開發難度都很是大。
2. 擴展 ByteBuffer：NIO和Netty都有ByteBuffer來操做數據，可是NIO的ByteBuffer長度固定並且操做複雜，許多操做甚至都須要本身實現。並且它的構造函數是私有，不能擴展。Netty 提供了本身的
   ByteBuffer 實現， Netty 經過一些簡單的 APIs 對 ByteBuffer 進行構造、使用和操做，以此來解決 NIO 中的一些限制。
3. NIO 對緩衝區的聚合和分散操做可能會操做內存泄露，到jdk7才解決了內存泄露的問題
4. 存在臭名昭著的epoll bug，致使Selector空輪詢：這個bug會致使linux上致使cpu 100%

爲何選擇Netty

• API使用簡單，開發門檻低。
• 功能強大，預置了多種編解碼功能，支持多種協議開發。
• 定製能力強，能夠經過ChannelHadler進行擴展。
• 性能高，對比其它NIO框架，Netty綜合性能最優。
• 經歷了大規模的應用驗證。在互聯網、大數據、網絡遊戲、企業應用、電信軟件獲得成功，不少著名的框架通訊底層就用了Netty，好比Dubbo
• 穩定，修復了NIO出現的全部Bug。
• 切換IO和NIO，由於IO和NIO的API徹底不一樣，相互切換很是困難。

相似的框架對比：

與Mina相比有什麼優點？

一、都是Trustin Lee的做品，Netty更晚；

二、Mina將內核和一些特性的聯繫過於緊密，使得用戶在不須要這些特性的時候沒法脫離，相比下性能會有所降低，Netty解決了這個設計問題；

三、Netty的文檔更清晰，不少Mina的特性在Netty裏都有；

四、Netty更新週期更短，新版本的發佈比較快；

五、它們的架構差異不大，Mina靠apache生存，而Netty靠jboss，和jboss的結合度很是高，Netty有對google protocal buf的支持，有更完整的ioc容器支持(spring,guice,jbossmc和osgi)；

六、Netty比Mina使用起來更簡單，Netty裏你能夠自定義的處理upstream events 或/和 downstream events，可使用decoder和encoder來解碼和編碼發送內容；

七、Netty和Mina在處理UDP時有一些不一樣，Netty將UDP無鏈接的特性暴露出來；而Mina對UDP進行了高級層次的抽象，能夠把UDP當成」面向鏈接」的協議，而要Netty作到這一點比較困難。

在此我向你們推薦一個架構學習交流羣。交流學習羣號：575745314 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

Netty多種IO方式的比較：

一、BIO（同步阻塞IO）

使用ServerSocket綁定IP地址和監聽端口，客戶端發起鏈接，經過三次握手創建鏈接，用socket來進行通訊，經過輸入輸出流的方式來進行同步阻塞的通訊

每次客戶端發起鏈接請求，都會啓動一個線程

線程數量：客戶端併發訪問數爲1：1，因爲線程是JAVA虛擬機中很是寶貴的資源，一旦線程數急劇增長，系統性能會急劇降低，致使線程棧溢出，建立新的線程失敗，並最終致使宕機

因此在JDK1.4以前，人們想到了一種方法，即PIO方式

二、PIO（僞異步阻塞IO）

使用線程池來處理客戶端的請求

客戶端個數：線程池最大線程數=M：N，其中M遠大於N

在read和write的時候，仍是IO阻塞的，只是把每一個線程交由線程池來控制管理

三、NIO（異步阻塞IO）

用NIO方式處理IO

使用多路複用器Selector來輪詢每一個通道Channel，當通道中有事件時就通知處理，不會阻塞

使用至關複雜

四、AIO（真正的異步非阻塞IO）

NIO2.0引入了新的異步通道的概念，不須要使用多路複用器（Selector）對註冊通道進行輪詢便可實現異步讀寫，從而簡化了NIO編程模型

使用Netty框架進行編程步驟

一、構建事件處理池

二、使用引導程序關聯事件處理池、通道、事件處理器

三、綁定端口服務

四、等待操做完成

五、關閉事件處理池

幾種IO的功能和特性對比

按照書上的例子碼了一遍：

服務端：

服務端處理器：

客戶端：

客戶端處理器：

Netty的高性能架構之道

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

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

爲何選擇Netty

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

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

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

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

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

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

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

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

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

在此我向你們推薦一個架構學習交流羣。交流學習羣號：575745314 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

Netty架構分析

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

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

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

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

1.純粹的業務邏輯 處理，例如訂單處理。

2.應用層協議管理，例如HTTP協議、FTP協議等。

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

I/O模型

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

它的弊端有不少：

1.性能問題：一鏈接一線程模型致使服務端的併發接入數和系統吞吐量受到極大限制；

2.可靠性問題：因爲I/O操做採用同步阻塞模式，當網絡擁塞或者通訊對端處理緩慢會致使I/O線程被掛住，阻塞時間沒法預測；

3.可維護性問題：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線程模型有三種，分別以下：

1.Reactor單線程模型：Reactor單線程模型，指的是全部的I/O操做都在同一個NIO線程上面完成。對於一些小容量應用場景，可使用單線程模型。

2.Reactor多線程模型：Rector多線程模型與單線程模型最大的區別就是有一組NIO線程處理I/O操做。主要用於高併發、大業務量場景。

3.主從Reactor多線程模型：主從Reactor線程模型的特色是服務端用於接收客戶端鏈接的再也不是個1個單獨的NIO線程，而是一個獨立的NIO線程池。利用主從NIO線程模型，能夠解決1個服務端監聽線程沒法有效處理全部客戶端鏈接的性能不足問題。

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

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

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

序列化方式

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

1.序列化後的碼流大小（網絡帶寬佔用）

2.序列化&反序列化的性能（CPU資源佔用）

3.併發調用的性能表現：穩定性、線性增加、偶現的時延毛刺等

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

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

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

Netty架構剖析之可靠性

Netty面臨的可靠性挑戰：

1.做爲RPC框架的基礎網絡通訊框架，一旦故障將致使沒法進行遠程服務（接口）調用。

2.做爲應用層協議的基礎通訊框架，一旦故障將致使應用協議棧沒法正常工做。

3.網絡環境複雜（例如手遊或者推送服務的GSM/3G/WIFI網絡），故障不可避免，業務卻不能中斷。

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

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

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

鏈路有效性檢測

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

1.讀空閒，鏈路持續時間t沒有讀取到任何消息；

2.寫空閒，鏈路持續時間t沒有發送任何消息；

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

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

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

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

1.TCP層面的心跳檢測，即TCP的Keep-Alive機制，它的做用域是整個TCP協議棧；

2.協議層的心跳檢測，主要存在於長鏈接協議中。例如SMPP協議；

3.應用層的心跳檢測，它主要由各業務產品經過約定方式定時給對方發送心跳消息實現。

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

1.讀空閒，鏈路持續時間t沒有讀取到任何消息；

2.寫空閒，鏈路持續時間t沒有發送任何消息；

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

流量整形

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

1.防止因爲上下游網元性能不均衡致使下游網元被壓垮，業務流程中斷；

2.防止因爲通訊模塊接收消息過快，後端業務線程處理不及時致使的「撐死」問題。

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

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

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

1.全局流量整形：全局流量整形的做用範圍是進程級的，不管你建立了多少個Channel，它的做用域針對全部的Channel。用戶能夠經過參數設置：報文的接收速率、報文的發送速率、整形週期。

2.鏈路級流量整形：單鏈路流量整形與全局流量整形的最大區別就是它以單個鏈路爲做用域，能夠對不一樣的鏈路設置不一樣的整形策略。

在此我向你們推薦一個架構學習交流羣。交流學習羣號：575745314 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

優雅停機

Netty的優雅停機三部曲：

1.再也不接收新消息

2.退出前的預處理操做

3.資源的釋放操做

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安全傳輸特性：

1.支持SSL V2和V3

2.支持TLS

3.支持SSL單向認證、雙向認證和第三方CA認證。

SSL單向認證流程圖以下：

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

單向認證：單向認證，即客戶端只驗證服務端的合法性，服務端不驗證客戶端。

雙向認證：與單向認證不一樣的是服務端也須要對客戶端進行安全認證。這就意味着客戶端的自簽名證書也須要導入到服務端的數字證書倉庫中。

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

可擴展的安全特性

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

1.IP地址黑名單機制

2.接入認證

3.敏感信息加密或者過濾機制

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

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

Netty架構剖析之擴展性

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

1.線程模型可擴展

2.序列化方式可擴展

3.上層協議棧可擴展

4.提供大量的網絡事件切面，方便用戶功能擴展

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

5.判斷擴展點，事先預留相關擴展接口，給用戶二次定製和擴展使用；

6.主要功能點都基於接口編程，方便用戶定製和擴展。