- 什麼是 RPC？
RPC 就是 Remote Procedure Call 三個單詞首字母的縮寫，其字面意思爲：遠程過程
調用。而遠程過程調用直觀說法就是：進程 A 遠程調用進程 B 的過程方法。既然是遠程調
用則需要涉及網絡傳輸，由此可見 RPC 主要應用於不同主機間的過程調用，也可用於本機
中不同進程之前的過程調用。
簡單的說，RPC 就是從一臺主機上的進程 A 通過參數傳遞的方式調用另一臺主機上的
進程 B 中的一個函數，並得到返回的結果。因此 RPC 具有以下特點：
a. RPC 會隱藏底層的通訊細節，不需要直接處理如何通信及收發數據。
b. RPC 是一個請求響應模型。客戶端發起調用請求，服務端返回請求響應，這類似於
HTTP 的工作方式。
c. RPC 在使用形式上像調用本地函數一樣去調用遠程的函數。
- 爲什麼要用 RPC？
在以前的單機時代，一臺主機上可以運行多個進程，假如進程 A 和 B 都要控制打印機
進行打印，而打印機同時只能被一個進程控制操作，這要怎麼辦纔好呢？爲了解決這一問題
系統提供了打印服務 C 進程，C 進程有打印任務隊列，A 和 B 進程把需要打印生成一個打
印任務，然後向 C 進程提交請求即可。A 和 B 進程與 C 進程之間通信就是 IPC，IPC 就
是 Inter-Process Communication 縮寫，其主要功能就是單機中進程之間的相互通信。
到了網絡時代，不可能每臺主機都配置一臺打印機，不同主機需要訪問帶打印機的主機
時 IPC 已無能爲力。這時就需要把IPC 擴展到網絡上，而網絡通信有很多通訊協議，如：
TCP、UDP等等。不同通訊協議的控制方式不同，這給開發人員帶來困難，只要不同主機之間
涉及網絡通信，其需要考慮的因素就非常多了，如：網速、斷線、延時、私有性、安全性等
等。於是 RPC 就是爲簡化遠程調用應運而生了，開發人員使用 RPC 時無須考慮如何握手連
接、如何收發數據等等問題。
什麼時候要用到 RPC 呢？就是無法在單個進程內，甚至單個主機內通過本地調用的方
式完成的需求，比如不同的系統之間的通訊，甚至不同的組織間的通訊。例如計算能力需要
橫向擴展，需要在多臺主機組成的集羣上部署應用，同時要簡化通訊細節，這時 RPC 框架
就發揮作用了。集羣部署的本質就是分佈式服務，由此可見 RPC 框架是分佈式服務的基石，
實現 RPC 框架需要考慮方方面面。其對業務隱藏了底層通信過程: TCP/UDP通訊協議、函數
參數打包/解包、參數數據序列化/反序列化，使開發人員專注於功能實現。
3.RPC，即 Remote Procedure Call（遠程過程調用），說得通俗一點就是：調用遠程計算機上的服務，就像調用本地服務一樣。兩方面會直接影響 RPC 的性能，一是傳輸方式，二是序列化。
衆所周知，TCP 是傳輸層協議，HTTP 是應用層協議，而傳輸層較應用層更加底層，在數據傳輸方面，越底層越快，因此，在一般情況下，TCP 一定比 HTTP 快。就序列化而言，Java 提供了默認的序列化方式，但在高併發的情況下，這種方式將會帶來一些性能上的瓶頸，於是市面上出現了一系列優秀的序列化框架，比如：Protobuf、Kryo、Hessian、Jackson 等，它們可以取代 Java 默認的序列化，從而提供更高效的性能。
Spring：它是最強大的依賴注入框架，也是業界的權威標準。
Netty：它使 NIO 編程更加容易，屏蔽了 Java 底層的 NIO 細節。
Protostuff：它基於 Protobuf 序列化框架，面向 POJO，無需編寫 .proto 文件。
ZooKeeper：提供服務註冊與發現功能，開發分佈式系統的必備選擇，同時它也具備天生的集羣能力。