專注於Java領域優質技術，歡迎關注
關於RPC
首先了解什麼叫RPC，為什麼要RPC，RPC是指遠程過程調用，也就是說兩臺服務器A，B，一個應用部署在A服務器上，想要調用B服務器上應用提供的函數/方法，由於不在一個內存空間，不能直接調用，需要通過網絡來表達調用的語義和傳達調用的數據。
比如說，一個方法可能是這樣定義的：
Employee getEmployeeByName(String fullName)
那麼：
- 首先，要解決通訊的問題，主要是通過在客戶端和服務器之間建立TCP連接，遠程過程調用的所有交換的數據都在這個連接裡傳輸。連接可以是按需連接，調用結束後就斷掉，也可以是長連接，多個遠程過程調用共享同一個連接。
- 第二，要解決尋址的問題，也就是說，A服務器上的應用怎麼告訴底層的RPC框架，如何連接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱名稱是什麼，這樣才能完成調用。比如基於Web服務協議棧的RPC，就要提供一個endpoint URI，或者是從UDDI服務上查找。如果是RMI調用的話，還需要一個RMI Registry來註冊服務的地址。
- 第三，當A服務器上的應用發起遠程過程調用時，方法的參數需要通過底層的網絡協議如TCP傳遞到B服務器，由於網絡協議是基於二進制的，內存中的參數的值要序列化成二進制的形式，也就是序列化（Serialize）或編組（marshal），通過尋址和傳輸將序列化的二進制發送給B服務器。
- 第四，B服務器收到請求後，需要對參數進行反序列化（序列化的逆操作），恢復為內存中的表達方式，然後找到對應的方法（尋址的一部分）進行本地調用，然後得到返回值。
- 第五，返回值還要發送回服務器A上的應用，也要經過序列化的方式發送，服務器A接到後，再反序列化，恢復為內存中的表達方式，交給A服務器上的應用
（圖片來源：https://www.cs.rutgers.edu/~pxk/417/notes/03-rpc.html）
為什麼RPC呢？就是無法在一個進程內，甚至一個計算機內通過本地調用的方式完成的需求，比如比如不同的系統間的通訊，甚至不同的組織間的通訊。由於計算能力需要橫向擴展，需要在多臺機器組成的集群上部署應用，
RPC的協議有很多，比如最早的CORBA，Java RMI，Web Service的RPC風格，Hessian，Thrift，甚至Rest API。
關於Netty
而Netty框架不侷限於RPC，更多的是作為一種網絡協議的實現框架，比如HTTP，由於RPC需要高效的網絡通信，就可能選擇以Netty作為基礎。除了網絡通信，RPC還需要有比較高效的序列化框架，以及一種尋址方式。如果是帶會話（狀態）的RPC調用，還需要有會話和狀態保持的功能。
大體上來說，Netty就是提供一種事件驅動的，責任鏈式（也可以說是流水線）的網絡協議實現方式。網絡協議包含很多層次，很多部分組成，如傳輸層協議，編碼解碼，壓縮解壓，身份認證，加密解密，請求的處理邏輯，怎麼能夠更好的複用，擴展，業界通用的方法就是責任鏈，
一個請求應答網絡交互通常包含兩條鏈，一條鏈（Upstream）是從傳輸層，經過一系列步驟，如身份認證，解密，日誌，流控，最後到達業務層，一條鏈（DownStream）是業務層返回後，又經過一系列步驟，如加密等，又回到傳輸層。
（圖片來源：ChannelPipeline (The Netty Project API Reference (3.2.6.Final))）
這樣每一層都有一個處理接口，都可以進行不同的操作，比如身份認證，加解密，日誌，流控，將不同的處理實現像拼積木那樣插接起來就可以實現一個網絡協議了（快速開發）。每一層都有自己的實現，上層不需要關注面向網絡的操作（可維護）。Netty已經提供了很多實現。
（圖片來源：http://docs.jboss.org/netty/3.1/guide/html/architecture.html）
當然Netty還有許多好處，比如對非阻塞IO（NIO）的支持，比如在鏈上傳遞時最大程度的減少buffer的copy（高性能）。
閱讀更多 Java技術架構 的文章
