## 流量暴漲 隨著流量上漲，現有的系統無法滿足海量并發請求，架構師把系統拆分成多個服務，根據需要在多個機器上，這些服務非常靈活，可以隨訪問量彈性擴展  但是拆分成微服務之后增加了彈性，但也帶來了巨大的挑戰：服務之間互相調用的開銷增加了。 比如說：原來用戶下一個訂單需要登錄，瀏覽產品詳情，加入購物車，支付，扣庫存等一系列操作，在單體應用的時候它們都在一臺機器的同一個進程中，說白了就是模塊之間的函數調用，效率超級高。 現在因為都被安置在不同的服務器上，一個訂單流程，幾乎所有的操作都要跨越網絡，都是**遠程過程調用（RPC）**，執行時間和執行效率都不比以前了。 ## RPC 遠程過程調用的第一版實現使用了HTTP協議，雖然簡單明了，但是廢話太多。比如說簡單發一個消息就會附帶一堆無用的信息 ~~~ 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，尤其是服務器端，得能處理高并發訪問請求才行。 最早的Java IO是所謂的阻塞IO，想處理多個socket的話，需要創建多個線程。  這種方式如果有多個線程同時處理多個socket，即占空間，線程之間的切換開銷也巨大 更重要的是，雖然socket很多，但是真正需要處理的（可以讀寫數據的socket)卻不多，大量線程處于等待狀態（這也是為什么是阻塞IO的原因） 后來Java又搞了個NIO，通過多路復用的方式讓一個線程處理多個Socket  線程只需要通過Selector去查一下所管理的socket集合，哪個socket準備好了，就去處理哪個socket 人們先定義了一套精簡的RPC協議，里面規定了如何調用一個服務，方法名和參數如何傳遞，返回值用啥格式。然后想用Java NIO來實現。 但是Java NIO看上去很簡單，但API還是太低級了 不過有個叫Netty的開源框架，可以快速得開發高性能面向協議的服務器和客戶端。 想使用 Java NIO 來實現一個高性能的 RPC 框架，調用協議，數據的格式和次序都是自己定義的，現有的 HTTP 根本玩不轉，那使用 Netty 就是絕佳的選擇。 其實游戲領域是個更好的例子，長連接，自定義協議，高并發，Netty 就是絕配。 因為 Netty 本身就是一個基于 NIO 的網絡框架， 封裝了 Java NIO 那些復雜的底層細節，給你提供簡單好用的抽象概念來編程。 注意幾個關鍵詞，首先它是個**框架**，是個 “半成品”，不能開箱即用，你必須得拿過來做點定制，利用它開發出自己的應用程序，然后才能運行（就像使用 Spring 那樣）。 一個更加知名的例子就是阿里巴巴的 Dubbo 了，這個 RPC 框架的底層用的就是 Netty。 另外一個關鍵詞是高性能，如果你的應用根本沒有高并發的壓力，那就不一定要用 Netty 了。