華納雲：小白科普Netty有什麼用？ 隨着移動互聯網的爆發性增加，小明公司的電子商務系統訪問量越來

小白科普：Netty有什麼用？
隨着移動互聯網的爆發性增加，小明公司的電子商務系統訪問量愈來愈大，因爲現有系統是個單體的巨型應用，已經沒法知足海量的併發請求，拆分勢在必行。
在微服務的大潮之中， 架構師小明把系統拆分紅了多個服務，根據須要部署在多個機器上，這些服務很是靈活，能夠隨着訪問量彈性擴展。
世界上沒有免費的午飯， 拆分紅多個「微服務」之後雖然增長了彈性，但也帶來了一個巨大的挑戰：服務之間互相調用的開銷。
好比說：原來用戶下一個訂單須要登陸，瀏覽產品詳情，加入購物車，支付，扣庫存等一系列操做，在單體應用的時候它們都在一臺機器的同一個進程中，說白了就是模塊之間的函數調用，效率超級高。
如今好了，服務被安置到了不一樣的服務器上，一個訂單流程，幾乎每一個操做都要越網絡，都是遠程過程調用(RPC)， 那執行時間、執行效率可遠遠比不上之前了。
遠程過程調用的初版實現使用了HTTP協議，也就是說各個服務對外提供HTTP接口。 小明發現，HTTP協議雖然簡單明瞭，可是廢話太多，僅僅是給服務器發個簡單的消息都會附帶一大堆無用信息：
GET /orders/1 HTTP/1.1
Host: order.myshop.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; )
Accept: text/html;
Accept-Language: en-US,en;
Accept-Encoding: gzip
Connection: keep-alive
......
看看那User-Agent，Accept-Language ，這個協議明顯是爲瀏覽器而生的！可是我這裏是程序之間的調用，用這個HTTP有點虧。
能不能自定義一個精簡的協議？ 在這個協議中我只須要把要調用方法名和參數發給服務器便可，根本不用這麼多亂七八糟的額外信息。
可是自定義協議客戶端和服務器端就得直接使用「低級」的Socket了，尤爲是服務器端，得可以處理高併發的訪問請求才行。
小明覆習了一下服務器端的socket編程，最先的Java是所謂的阻塞IO(Blocking IO)， 想處理多個socket的鏈接的話須要建立多個線程， 一個線程對應一個。
這種方式寫起來卻是挺簡單的，可是鏈接（socket）多了就受不了了，若是真的有成千上萬個線程同時處理成千上萬個socket，佔用大量的空間不說，光是線程之間的切換就是一個巨大的開銷。
更重要的是，雖然有大量的socket，可是真正須要處理的（能夠讀寫數據的socket）卻很少，大量的線程處於等待數據狀態（這也是爲何叫作阻塞的緣由），資源浪費得讓人心疼。
後來Java爲了解決這個問題，又搞了一個非阻塞IO(NIO：Non-Blocking IO，有人也叫作New IO)， 改變了一下思路：經過多路複用的方式讓一個線程去處理多個Socket。
這樣一來，只須要使用少許的線程就能夠搞定多個socket了，線程只須要經過Selector去查一下它所管理的socket集合，哪一個Socket的數據準備好了，就去處理哪一個Socket，一點兒都不浪費。
好了，就是Java NIO了！
小明先定義了一套精簡的RPC的協議，裏邊規定了如何去調用一個服務，方法名和參數該如何傳遞，返回值用什麼格式......等等。而後雄心勃勃地要把這個協議用Java NIO給實現了。
但是美好的理想很快被無情的現實給擊碎， 小明努力了一週就意識到本身陷入了一個大坑之中，Java NIO雖然看起來簡單，可是API仍是太「低級」了，有太多的複雜性，沒有強悍的、一流的編程能力根本沒法駕馭，根本作不到高併發狀況下的可靠和高效。
小明不死心，繼續向領導要人要資源，必定要把這個坑給填上，掙扎了6個月之後，終於實現了一個本身的NIO框架，能夠執行高併發的RPC調用了。
而後又是長達6個月的修修補補，小明常常半夜被叫醒：生產環境的RPC調用沒法返回了！ 這樣的Bug不知道改了多少個。
在那些不眠之夜中，小明常常仰天長嘆：我用NIO作個高併發的RPC框架怎麼這麼難吶！
一年以後，自研的框架終於穩定，但是小明也從張大胖那裏聽到了一個讓他崩潰的消息： 小明你知道嗎?有個叫Netty的開源框架，能夠快速地開發高性能的面向協議的服務器和客戶端。 易用、健壯、安全、高效，你能夠在Netty上輕鬆實現各類自定義的協議！我們也試試？
小明趕忙研究，看完後不禁得「淚流滿面」：這東西怎麼不早點出來啊！
好了，這個故事我快編不下去了，要爛尾了。
說說Netty究竟是何方神聖， 要解決什麼問題吧。
像上面小明的例子，想使用Java NIO來實現一個高性能的RPC框架，調用協議，數據的格式和次序都是本身定義的，現有的HTTP根本玩不轉，那使用Netty就是絕佳的選擇。
其實遊戲領域是個更好的例子，長鏈接，自定義協議，高併發，Netty就是絕配。
由於Netty自己就是一個基於NIO的網絡框架， 封裝了Java NIO那些複雜的底層細節，給你提供簡單好用的抽象概念來編程。
注意幾個關鍵詞，首先它是個框架，是個「半成品」，不能開箱即用，你必須得拿過來作點定製，利用它開發出本身的應用程序，而後才能運行（就像使用Spring那樣）。
一個更加知名的例子就是阿里巴巴的Dubbo了，這個RPC框架的底層用的就是Netty。
另一個關鍵詞是高性能，若是你的應用根本沒有高併發的壓力，那就不必定要用Netty了