什么是 RPC 框架
RPC 框架----- 遠程過程調用協議RPC（Remote Procedure Call Protocol)-----允許像調用本地服務一樣調用遠程服務。
RPC是指遠程過程調用，也就是說兩台服務器A，B，一個應用部署在A服務器上，想要調用B服務器上應用提供的函數/方法，由於不在一個內存空間，不能直接調用，需要通過網絡來表達調用的語義和傳達調用的數據。比如說，一個方法可能是這樣定義的：
Employee getEmployeeByName(String fullName)那么：
第一，首先，要解決通訊的問題，主要是通過在客戶端和服務器之間建立TCP連接（socket），遠程過程調用的所有交換的數據都在這個連接里傳輸。連接可以是按需連接，調用結束后就斷掉，也可以是長連接，多個遠程過程調用共享同一個連接。
第二，要解決尋址的問題，也就是說，A服務器上的應用怎么告訴底層的RPC框架，如何連接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱名稱是什么，這樣才能完成調用。比如基於Web服務協議棧的RPC，就要提供一個endpoint URI，或者是從UDDI服務上查找。如果是RMI調用的話，還需要一個RMI Registry來注冊服務的地址。
第三，當A服務器上的應用發起遠程過程調用時，方法的參數需要通過底層的網絡協議如TCP傳遞到B服務器，由於網絡協議是基於二進制的，內存中的參數的值要序列化成二進制的形式，也就是序列化（Serialize）或編組（marshal），通過尋址和傳輸將序列化的二進制發送給B服務器。
第四，B服務器收到請求后，需要對參數進行反序列化（序列化的逆操作），恢復為內存中的表達方式，然后找到對應的方法（尋址的一部分）進行本地調用，然后得到返回值。
第五，返回值還要發送回服務器A上的應用，也要經過序列化的方式發送，服務器A接到后，再反序列化，恢復為內存中的表達方式，交給A服務器上的應用
總的來說可以歸納為以下幾步：
1，遠程服務之間建立通訊協議
2，尋址：服務器（如主機或IP地址）以及特定的端口，方法的名稱名稱是什么
3，通過序列化和反序列化進行數據傳遞
4，將傳遞過來的數據通過java反射原理定位接口方法和參數
5，暴露服務：用map將尋址的信息暴露給遠方服務（提供一個endpoint URI或者一個前端展示頁面）
6，多線程並發請求業務
什么是RPC
提到RPC（Remote Procedure Call），就躲不開提到分布式，這個促使RPC誕生的領域。
假設你有一個Calculator，以及它的實現類CalculatorImpl，那么單體應用時，要調用Calculator的add方法來執行一個加運算，你可以方法中直接使用，因為在同一個地址空間，或者說在同一塊內存，這個稱為本地函數調用。
現在，將系統改造為分布式應用，接口調用和實現分別在兩個子系統內，
服務A里頭並沒有CalculatorImpl這個類，那它要怎樣調用服務B的CalculatorImpl的add方法呢？可以模仿B/S架構的調用方式，在B服務暴露一個Restful接口，然后A服務通過調用這個Restful接口來間接調用CalculatorImpl的add方法。
這樣，已經很接近RPC了，不過，像這種每次調用時，是不是都需要寫一串發起http請求的代碼呢？比如httpClient.sendRequest...之類的，能不能簡單一下，像本地方法調用一樣，去發起遠程調用，讓使用者感知不到遠程調用的過程。
屏蔽的工作，可以使用代理模式解決，生成一個代理對象，而這個代理對象的內部，就是通過httpClient來實現RPC遠程過程調用的。
這就是很多RPC框架要解決的問題和解決的思路，比如阿里的Dubbo。
總結一下，RPC要解決的兩個問題：
1. 解決分布式系統中，服務之間的調用問題。
2. 遠程調用時，要能夠像本地調用一樣方便，讓調用者感知不到遠程調用的邏輯。
RPC是一種技術的概念名詞
RPC=Remote Produce Call 是一種技術的概念名詞，HTTP是一種協議,RPC可以通過 HTTP 來實現,也可以通過Socket自己實現一套協議來實現.所以題目可以換一種理解,為何 RPC 還有除 HTTP 之外的實現法,有何必要，畢竟除了HTTP實現外,私有協議不具備通用性.
RPC框架好處
http接口是在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；
優點就是簡單、直接、開發方便。
如果是一個大型的網站，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了：
首先就是長鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網絡開銷；
其次就是RPC框架一般都有注冊中心，有豐富的監控管理；發布、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。
最后是安全性。
rpc是一種概念，http也是rpc實現的一種方式。
論復雜度，dubbo/hessian用起來是超級簡單的。
至於為什么用dubbo/hessian，有幾點：
一是調用簡單，真正提供了類似於調用本地方法一樣調用接口的功能 。
二是參數返回值簡單明了 參數和返回值都是直接定義在jar包里的，不需要二次解析。
三是 輕量，沒有多余的信息。
四是便於管理，基於dubbo的注冊中心。
RPC能解耦服務
RPC:遠程過程調用。RPC的核心並不在於使用什么協議。RPC的目的是讓你在本地調用遠程的方法，而對你來說這個調用是透明的，你並不知道這個調用的方法是部署哪里。
通過RPC能解耦服務，這才是使用RPC的真正目的。RPC的原理主要用到了動態代理模式，至於http協議，只是傳輸協議而已。簡單的實現可以參考spring remoting，復雜的實現可以參考dubbo。
rpc=socket + 動態代理
服務器通訊原理就是一台socket服務器A,另一台socket客戶端B,現在如果要通訊的話直接以流方式寫入或讀出。這樣能實現通訊，但有個問題。如何知道更多信息？
比如需要發送流大小，編碼，Ip等。這樣就有了協議，協議就是規范，就是發送的流中攜帶了很多的內容。那回到剛剛的問題。發送的內容就是文本類型，客戶端就得序列化，那么常用的就有json，xml之類，如果想把內容變得更小，那就有二進制了。把文本變成二進制傳遞。
說到 rpc 與http接口，不要太復雜了。rpc 協議更簡單內容更小，那么來說效率是要高一點
rpc 是什么？就是socket 加動態代理。
總結
學技術應該是知其然知其所以然，我們得明白什么場景，或者什么業務需要它，它能解決其他技術不能解決或者不方便解決的問題。
RPC是一個軟件結構概念，是構建分布式應用的理論基礎。就好比為啥你家可以用到發電廠發出來的電？是因為電是可以傳輸的。至於用銅線還是用鐵絲還是其他種類的導線，也就是用http還是用其他協議的問題了。這個要看什么場景，對性能要求怎么樣。
在java中的最基本的就是RMI技術，它是java原生的應用層分布式技術。我們可以肯定的是在傳輸性能方面，RMI的性能是優於HTTP的。
那為啥很少用到這個技術？那是因為用這個有很多局限性，首先它要保證傳輸的兩端都要要用java實現，且兩邊需要有相同的對象類型和代理接口，不需要容器，但是加大了編程的難度，在應用內部的各個子系統之間還是會看到他的身影，比如EJB就是基於rmi技術的。
這就與目前的bs架構的軟件大相徑庭。用http必須要服務端位於http容器里面，這樣減少了網絡傳輸方面的開發，只需要關注業務開發即可。所以在架構一個軟件的時候，不能一定根據需求選定技術。