姓名：?？??學(xué)號(hào)：17101223416
轉(zhuǎn)載自：https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665514049&idx=1&sn=5c0b2c44e21ae15b62057f7a9531be19&chksm=80d67c02b7a1f514a66b5351357aa3a1bfe67c763d337bd897980503b783724ce566af94a5a4&scene=38#wechat_redirect
【嵌牛導(dǎo)讀】：隨著移動(dòng)互聯(lián)網(wǎng)的爆發(fā)性增長(zhǎng)，系統(tǒng)訪(fǎng)問(wèn)量越來(lái)越大，由于現(xiàn)有系統(tǒng)是個(gè)單體的巨型應(yīng)用，已經(jīng)無(wú)法滿(mǎn)足海量的并發(fā)請(qǐng)求，拆分勢(shì)在必行。
【嵌牛鼻子】：?jiǎn)误w應(yīng)用、Netty
【嵌牛提問(wèn)】：Netty到底是何方神圣呢？
【嵌牛正文】：
在微服務(wù)的大潮之中， 架構(gòu)師小明把系統(tǒng)拆分成了多個(gè)服務(wù)，根據(jù)需要部署在多個(gè)機(jī)器上，這些服務(wù)非常靈活，可以隨著訪(fǎng)問(wèn)量彈性擴(kuò)展。
世界上沒(méi)有免費(fèi)的午餐， 拆分成多個(gè)“微服務(wù)”以后雖然增加了彈性，但也帶來(lái)了一個(gè)巨大的挑戰(zhàn)：服務(wù)之間互相調(diào)用的開(kāi)銷(xiāo)。
比如說(shuō)：原來(lái)用戶(hù)下一個(gè)訂單需要登錄，瀏覽產(chǎn)品詳情，加入購(gòu)物車(chē)，支付，扣庫(kù)存等一系列操作，在單體應(yīng)用的時(shí)候它們都在一臺(tái)機(jī)器的同一個(gè)進(jìn)程中，說(shuō)白了就是模塊之間的函數(shù)調(diào)用，效率超級(jí)高。
現(xiàn)在好了，服務(wù)被安置到了不同的服務(wù)器上，一個(gè)訂單流程，幾乎每個(gè)操作都要越網(wǎng)絡(luò)，都是遠(yuǎn)程過(guò)程調(diào)用(RPC)， 那執(zhí)行時(shí)間、執(zhí)行效率可遠(yuǎn)遠(yuǎn)比不上以前了。
遠(yuǎn)程過(guò)程調(diào)用的第一版實(shí)現(xiàn)使用了HTTP協(xié)議，也就是說(shuō)各個(gè)服務(wù)對(duì)外提供HTTP接口。 小明發(fā)現(xiàn)，HTTP協(xié)議雖然簡(jiǎn)單明了，但是廢話(huà)太多，僅僅是給服務(wù)器發(fā)個(gè)簡(jiǎn)單的消息都會(huì)附帶一大堆無(wú)用信息：
GET/orders/1HTTP/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 ，這個(gè)協(xié)議明顯是為瀏覽器而生的！但是我這里是程序之間的調(diào)用，用這個(gè)HTTP有點(diǎn)虧。
能不能自定義一個(gè)精簡(jiǎn)的協(xié)議？ 在這個(gè)協(xié)議中我只需要把要調(diào)用方法名和參數(shù)發(fā)給服務(wù)器即可，根本不用這么多亂七八糟的額外信息。
但是自定義協(xié)議客戶(hù)端和服務(wù)器端就得直接使用“低級(jí)”的Socket了，尤其是服務(wù)器端，得能夠處理高并發(fā)的訪(fǎng)問(wèn)請(qǐng)求才行。
小明復(fù)習(xí)了一下服務(wù)器端的socket編程，最早的Java是所謂的阻塞IO(Blocking IO)， 想處理多個(gè)socket的連接的話(huà)需要?jiǎng)?chuàng)建多個(gè)線(xiàn)程， 一個(gè)線(xiàn)程對(duì)應(yīng)一個(gè)。
這種方式寫(xiě)起來(lái)倒是挺簡(jiǎn)單的，但是連接（socket）多了就受不了了，如果真的有成千上萬(wàn)個(gè)線(xiàn)程同時(shí)處理成千上萬(wàn)個(gè)socket，占用大量的空間不說(shuō)，光是線(xiàn)程之間的切換就是一個(gè)巨大的開(kāi)銷(xiāo)。
更重要的是，雖然有大量的socket，但是真正需要處理的（可以讀寫(xiě)數(shù)據(jù)的socket）卻不多，大量的線(xiàn)程處于等待數(shù)據(jù)狀態(tài)（這也是為什么叫做阻塞的原因），資源浪費(fèi)得讓人心疼。
后來(lái)Java為了解決這個(gè)問(wèn)題，又搞了一個(gè)非阻塞IO(NIO：Non-Blocking IO，有人也叫做New IO)， 改變了一下思路：通過(guò)多路復(fù)用的方式讓一個(gè)線(xiàn)程去處理多個(gè)Socket。
這樣一來(lái)，只需要使用少量的線(xiàn)程就可以搞定多個(gè)socket了，線(xiàn)程只需要通過(guò)Selector去查一下它所管理的socket集合，哪個(gè)Socket的數(shù)據(jù)準(zhǔn)備好了，就去處理哪個(gè)Socket，一點(diǎn)兒都不浪費(fèi)。
好了，就是Java NIO了！
小明先定義了一套精簡(jiǎn)的RPC的協(xié)議，里邊規(guī)定了如何去調(diào)用一個(gè)服務(wù)，方法名和參數(shù)該如何傳遞，返回值用什么格式......等等。然后雄心勃勃地要把這個(gè)協(xié)議用Java NIO給實(shí)現(xiàn)了。
可是美好的理想很快被無(wú)情的現(xiàn)實(shí)給擊碎， 小明努力了一周就意識(shí)到自己陷入了一個(gè)大坑之中，Java NIO雖然看起來(lái)簡(jiǎn)單，但是API還是太“低級(jí)”了，有太多的復(fù)雜性，沒(méi)有強(qiáng)悍的、一流的編程能力根本無(wú)法駕馭，根本做不到高并發(fā)情況下的可靠和高效。
小明不死心，繼續(xù)向領(lǐng)導(dǎo)要人要資源，一定要把這個(gè)坑給填上，掙扎了6個(gè)月以后，終于實(shí)現(xiàn)了一個(gè)自己的NIO框架，可以執(zhí)行高并發(fā)的RPC調(diào)用了。
然后又是長(zhǎng)達(dá)6個(gè)月的修修補(bǔ)補(bǔ)，小明經(jīng)常半夜被叫醒：生產(chǎn)環(huán)境的RPC調(diào)用無(wú)法返回了！ 這樣的Bug不知道改了多少個(gè)。
在那些不眠之夜中，小明經(jīng)常仰天長(zhǎng)嘆：我用NIO做個(gè)高并發(fā)的RPC框架怎么這么難吶！
一年之后，自研的框架終于穩(wěn)定，可是小明也從張大胖那里聽(tīng)到了一個(gè)讓他崩潰的消息： 小明你知道嗎?有個(gè)叫Netty的開(kāi)源框架，可以快速地開(kāi)發(fā)高性能的面向協(xié)議的服務(wù)器和客戶(hù)端。 易用、健壯、安全、高效，你可以在Netty上輕松實(shí)現(xiàn)各種自定義的協(xié)議！咱們也試試？
小明趕緊研究，看完后不由得“淚流滿(mǎn)面”：這東西怎么不早點(diǎn)出來(lái)啊！
好了，這個(gè)故事我快編不下去了，要爛尾了。
說(shuō)說(shuō)Netty到底是何方神圣， 要解決什么問(wèn)題吧。
像上面小明的例子，想使用Java NIO來(lái)實(shí)現(xiàn)一個(gè)高性能的RPC框架，調(diào)用協(xié)議，數(shù)據(jù)的格式和次序都是自己定義的，現(xiàn)有的HTTP根本玩不轉(zhuǎn)，那使用Netty就是絕佳的選擇。
其實(shí)游戲領(lǐng)域是個(gè)更好的例子，長(zhǎng)連接，自定義協(xié)議，高并發(fā)，Netty就是絕配。
因?yàn)镹etty本身就是一個(gè)基于NIO的網(wǎng)絡(luò)框架， 封裝了Java NIO那些復(fù)雜的底層細(xì)節(jié)，給你提供簡(jiǎn)單好用的抽象概念來(lái)編程。
注意幾個(gè)關(guān)鍵詞，首先它是個(gè)框架，是個(gè)“半成品”，不能開(kāi)箱即用，你必須得拿過(guò)來(lái)做點(diǎn)定制，利用它開(kāi)發(fā)出自己的應(yīng)用程序，然后才能運(yùn)行（就像使用Spring那樣）。
一個(gè)更加知名的例子就是阿里巴巴的Dubbo了，這個(gè)RPC框架的底層用的就是Netty。
另外一個(gè)關(guān)鍵詞是高性能，如果你的應(yīng)用根本沒(méi)有高并發(fā)的壓力，那就不一定要用Netty了。
