為什么要用Netty開發(fā)

為什么要用Netty開發(fā)

Netty是由JBOSS提供的基于Java NIO的開源框架，Netty提供異步非阻塞、事件驅(qū)動、高性能、高可靠、高可定制性的**應用程序和工具，可用于開發(fā)服務端和客戶端。
JAVA原先是采用的是傳統(tǒng)的BIO，為什么后來又研發(fā)出了NIO呢？
首先看看傳統(tǒng)的基于同步阻塞IO（BIO）的線程模型圖

BIO主要存在以下缺點：
1.從線程模型圖中可以看到，一連接一線程，由于線程數(shù)是有限的，所以這樣的模型是非常消耗資源的，
最終也導致它不能承受高并發(fā)連接的需求
2.性能低，因為頻繁的進行上下文切換，導致CUP利用率低
3.可靠性差，由于所有的IO操作都是同步的，即使是業(yè)務線程也如此，所以業(yè)務線程的IO操作也有可能被阻塞，
這將導致系統(tǒng)過分依賴**的實時情況和外部組件的處理能力，可靠性大大降低
上面的原因就是導致早期的高性能服務器為什么不選用JAVA開發(fā)，而是選用C/C++的重要原因。

為了解決上面的問題，NIO橫空出世，下面是NIO的線程模型圖

1.NIO采用了Reactor線程模型，一個Reactor聚合了一個多路復用器Selector，它可以同時注冊、監(jiān)聽和輪詢
成百上千個Channel，這樣一個IO線程可以同時處理很多個客戶端連接，線程模型優(yōu)化為1：N(N<**句柄、數(shù))，
或M:N(M通常為CUP核數(shù)+1)
2.避免了IO線程頻繁的上下文切換，提升了CUP的效率
3.所有的IO操作都是異步的，所以業(yè)務線程的IO操作就不用擔心阻塞，系統(tǒng)降低了對**的實時情況和外部組件
的處理能力的依賴
為什么不直接用JDK原生的NIO而選用Netty框架？
先看看JDK的NIO中服務端和客戶端的時序圖
服務端：

客戶端：

從圖中我們可以看到，使用JDK原生NIO的不足之處
1.NIO的類庫和API相當復雜，使用它來開發(fā)，需要非常熟練地掌握Selector、ByteBuffer、ServerSocketChannel、SocketChannel等
2.需要很多額外的編程技能來輔助使用NIO,例如，因為NIO涉及了Reactor線程模型，所以必須必須對多線程和**編程非常熟悉才能寫出高質(zhì)量的NIO程序
3.想要有高可靠性，工作量和難度都非常的大，因為服務端需要面臨客戶端頻繁的接入和斷開、**閃斷、半包讀寫、失敗緩存、**阻塞的問題，這些將嚴重影響我們的可靠性，而使用原生NIO解決它們的難度相當大。

4.JDK NIO中**的BUG–epoll空輪詢，當select返回0時，會導致Selector空輪詢而導致CUP****，百科**表示JDK1.6之后修復了這個問題，其實只是發(fā)生的概率降低了，沒有根本上解決。
那么為什么要用Netty呢？
1.API使用簡單，更容易上手，開發(fā)門檻低
2.功能強大，預置了多種編解碼功能，支持多種主流協(xié)議
3.定制能力高，可以通過ChannelHandler對通信框架進行靈活地拓展
4.高性能，與目前多種NIO主流框架相比，Netty綜合性能**
5.高穩(wěn)定性，解決了JDK NIO的BUG
6.經(jīng)歷了大規(guī)模的商業(yè)應用考驗，質(zhì)量和可靠性都有很好的驗證。

netty超時原因

1、檢查**的網(wǎng)速是否正常，局域網(wǎng)里是否有人看電影或者下載軟件等拖慢了網(wǎng)速。2、連接蘋果跟iTunes時，檢查iT的設置情況，打開iTunes — 編輯 — 偏好設置 — 家長控制 — iTunes Store這一項勾選（把 允許訪問iTunes U 這一項也勾選）– 確定。

再重啟，重開iTunes，回到剛才那個步驟，把剛剛勾選的兩項取消，回iTunes Store登陸。

3、關掉防火墻，在windows 安全中心。1.tomcat比較適合j2ee開發(fā)，因為其完整的實現(xiàn)了Servlet和JSP規(guī)范2.tomcat處理高并發(fā)請求性能不夠好，比如需要使用NIO時必須要安裝APR插件，確實比較麻煩。3.netty是一個性能非常好的java NIO**框架，我們已經(jīng)在諸多大項目中使用并驗證。所以：如果性能要求不高，則選用tomcat 開發(fā)上更易用如果對性能有要求，選用netty，當然其在使用上要更麻煩，最直接的啟停監(jiān)控腳本得自己來弄。

Netty 能做什么?

Netty能處理大容量數(shù)據(jù)流。
Netty是由JBOSS提供的一個java開源框架，現(xiàn)為?Github上的獨立項目。

Netty提供異步的、事件驅(qū)動的**應用程序框架和工具，用以快速開發(fā)高性能、高可靠性的**服務器和客戶端程序。

也就是說，Netty 是一個基于NIO的客戶、服務器端的編程框架，使用Netty 可以確保你快速和簡單的開發(fā)出一個**應用，例如實現(xiàn)了某種協(xié)議的客戶、服務端應用。Netty相當于簡化和流線化了**應用的編程開發(fā)過程，例如：基于TCP和UDP的socket服務開發(fā)。

特點
1、易用性
大量的 Javadoc 和 代碼實例，除了在 JDK 1.6 + 額外的限制。

2、性能
比核心 Java API 更好的吞吐量，較低的延時，資源消耗更少，這個得益于共享池和重用，減少內(nèi)存拷貝。

Netty WebSocket 拆包淺析

最近項目中運用 WebSocket 的場景越來越多，自然而然。踩到的坑也就越來越多，例如最經(jīng)常遇到的拆包，粘包問題。

而當發(fā)現(xiàn)這個問題的時候，起初我認為與我之前通過 mina 實現(xiàn)自定義協(xié)議頭，解決 socket 進行數(shù)據(jù)傳輸時遇到拆包問題的場景是一樣的。

而當我慢慢深入了解 WebSocket的時候才發(fā)現(xiàn)，實際上，WebSocket 的出現(xiàn)，就是為了解決拆包，粘包的問題的。因為這些事情，本身就是應該由運用層去解決，而不是在TCP/IP層解決。 通過**搜索，我們可以知道 WebSocket 協(xié)議是根據(jù) RFC6455 規(guī)范實現(xiàn)的，而**版本是13（距離現(xiàn)今也接近10年了）。 以下是 WebScoket 定義的協(xié)議幀片段。

通過以上的幀定義片段。我也就明白了，為什么說 WebSocket 是為了解決拆包，粘包問題等一系列應用層問題而誕生的。從 RCF6455 規(guī)范定義第 5.3 章節(jié)中可以發(fā)現(xiàn)，每次發(fā)送或者接收的幀報文中，都會有定義協(xié)議的一些信息，例如頭部大小，數(shù)據(jù)大小，以及幀類型，標識位等信息。

看完協(xié)議定義，那么開始查看?Netty?源碼。 以下是?Netty?定義的相關幀類型以供開發(fā)者使用。當服務端接收到協(xié)議由 HTTP 握手升級協(xié)議 WebSocket 時，我們需要通過?WebSocketServerHandshakerFactory 類新建 WebSocketHandshaker ，此時會判斷 WebSocket 協(xié)議版本以及相關信息進行校驗。

而?WebSocketServerHandshaker 中，分別定義了?WebSocketFrameDecoder ， WebSocketFrameEncoder 進行解碼，編碼調(diào)用。那么從現(xiàn)實開始，大概也就清楚了， Netty?中?WebSocket?和?Socket?實現(xiàn)，實際上都是一樣的，都是一個解碼器（負責接收數(shù)據(jù)，處理成需要的類型，例如文本，二進制），一個編碼器（負責根據(jù)協(xié)議版本，進行幀封裝）的結(jié)構。 從?WebSocket13FrameDecoder 我們可以得知，實際上?WebSocket13FrameDecoder 是繼承自 WebSocket08FrameDecoder （由于實現(xiàn)細節(jié)一致），而?WebSocket08FrameDecoder 是繼承自?ByteToMessageDecoder ，實際上都是通過二進制數(shù)據(jù)進行解碼處理的。

查看?WebSocket08FrameDecoder 我們可以了解到具體的實現(xiàn)細節(jié)，就是每次解碼的時候，都會讀取首部信息，然后依次對數(shù)據(jù)進行處理。而拆包等操作，都是已經(jīng)進行的相應處理和封裝。 看完 Netty 的源碼實現(xiàn)，那么就可以進行實際的編碼解決問題了。 當服務端/客戶端發(fā)現(xiàn)包文過大時，會進行拆包。

而為每個包定義一系列的定義。 例如：當接收一個 Text 消息時， Netty 首先會實例化一個 TextWebSocketFrame 對象并傳遞給調(diào)用方，而通過?isFinalFragment 我們可以判斷出，這個幀對象是否已經(jīng)傳輸完畢，如果傳輸完畢，那么進行業(yè)務處理。如果沒有傳輸完畢，那么繼續(xù)等待余下信息，進行拼接處理。以上為服務端接收拆包信息的處理方式，反之亦然，客戶端接收消息也可以進行相應操作。

而根據(jù) WebSocket 1.3 版本實現(xiàn)的組件，也都根據(jù) RFC6455 規(guī)范進行相應實現(xiàn)，可以實現(xiàn)無縫對接。

如何實現(xiàn)Netty框架中服務器端的消息推送？

netty框架是用在服務器端，客戶端是嵌入式編程，通過自定義的tcp通信協(xié)議進行連接的，現(xiàn)在需求是這樣的，服務器端只是用來和客戶端進行通信，現(xiàn)在有第三方如微信端進行支付成功后在數(shù)據(jù)庫里生成了一條數(shù)據(jù)，表示要往某個客戶端發(fā)送指令，以下兩種方式可供參考：1、微信端生成通訊指令后調(diào)用TCP端的接口（負責通訊程序和數(shù)據(jù)庫交互的），在接口程序中通過定義Socket連到通訊程序服務器端，根據(jù)通道編號去發(fā)送，但是這種會導致服務器端的tcp客戶端連接變得更多。2、直接在netty框架中定義了scheduleAtF。

當然也可借助第三方工具來完成推送。

例如極光推送，極光推送具有以下功能：1、多種消息類型開發(fā)者可以輕松地通過極光發(fā)送各個移動平臺的系統(tǒng)通知，還可以在控制臺編輯多種富文本展示模板; 極光還提供自定義消息的透傳，客戶端接到消息內(nèi)容后根據(jù)自己的邏輯自由處理。2、用戶和推送統(tǒng)計完整的消息生命周期查詢，并且可以形成“推送報表”與“用戶統(tǒng)計報表”呈現(xiàn)給開發(fā)者，用來觀察推送的效果和應用發(fā)展趨勢。3、短信補充通過極光后臺推送APP通知消息，對于一些重要又不能遺漏的信息可以調(diào)用極光短信的后臺對未收到的客戶端發(fā)送短信通知，保證消息的可靠性。4、A/B 測試合理的推送能夠激活用戶，提高用戶粘性，使用A/B分組測試的科學方法，根據(jù)測試反饋的結(jié)果，幫助開發(fā)者選擇**化的推送方案。

5、極光推送安全包為金融、**、政務及其他對推送安全要求極高的客戶提供安全嚴謹、穩(wěn)定可靠的信息推送解決方案6、可定制的私有云對于安全性要求更高，希望推送數(shù)據(jù)和系統(tǒng)存儲在自己服務器的客戶，及個性化需求需要定制開發(fā)的，性能更高要求的，或者想擁有自己推送平臺的甚至要求源碼授權二次開發(fā)的開發(fā)者，極光提供全功能的私有云解決方案。深圳市和訊華谷信息技術有限公司（極光 Aurora Mobile，納斯達克股票代碼：JG）成立于2011年，是**領先的開發(fā)者服務提供商，專注于為開發(fā)者提供穩(wěn)定高效的消息推送、一鍵認證以及流量變現(xiàn)等服務，助力開發(fā)者的運營、增長與變現(xiàn)。同時，極光的行業(yè)應用已經(jīng)拓展至市場洞察、金融風控與商業(yè)地理服務，助力各行各業(yè)優(yōu)化決策、提升效率。