首先，實名讚揚題主的問題。這個問題非常好。
其次，實名反對各個上來就講RPC好而HTTP不好的答案。因為，題主的觀點非常對。
HTTP協議，以其中的Restful規範為代表，其優勢很大。它可讀性好，且可以得到防火牆的支持、跨語言的支持。而且，在去年的報告中，Restful大有超過RPC的趨勢。
本想引用下報告內容，無奈最近由於某些原因，KeXueShangWang被Qiang了。等我日後出牆時，再做補充。
但是HTTP也有其缺點，這是與其優點相對應的。首先是有用信息佔比少，畢竟HTTP工作在第七層，包含了大量的HTTP頭等信息。其次是效率低，還是因為第七層的緣故。還有，其可讀性似乎沒有必要，因為我們可以引入網關增加可讀性。此外，使用HTTP協議調用遠程方法比較複雜，要封裝各種參數名和參數值。
而RPC則與HTTP互補，我們詳細介紹下。看完這篇回答，能讓你對RPC的產生、原理、實現代碼都有著清晰的瞭解。這樣，也能在業務系統中，在RPC和HTTP之間做好抉擇。
但需要再說一句，不是說RPC好，也不是說HTTP好，兩者各有千秋，還在比拼中。
要問我站誰？我根據業務場景，靈活站位……
RPC的英文全稱是Remote Procedure Call，翻譯為中文叫“遠程過程調用”。其中稍顯晦澀的其實就是“過程”，過程其實就是方法。所以，可以把RPC理解為“遠程方法調用”。
要了解遠程過程調用，那先理解過程調用。非常簡單，如下圖，就是調用一個方法。這太常見了，不多解釋。
而在分佈式系統中，因為每個服務的邊界都很小，很有可能調用別的服務提供的方法。這就出現了服務A調用服務B中方法的需求，即遠程過程調用。
要想讓服務A調用服務B中的方法，最先想到的就是通過HTTP請求實現。是的，這是很常見的，例如服務B暴露Restful接口，然後讓服務A調用它的接口。基於Restful的調用方式因為可讀性好（服務B暴露出的是Restful接口，可讀性當然好）而且HTTP請求可以通過各種防火牆，因此非常不錯。
然而，如前面所述，基於Restful的遠程過程調用有著明顯的缺點，主要是效率低、封裝調用複雜。當存在大量的服務間調用時，這些缺點變得更為突出。
服務A調用服務B的過程是應用間的內部過程，犧牲可讀性提升效率、易用性是可取的。基於這種思路，RPC產生了。
通常，RPC要求在調用方中放置被調用的方法的接口。調用方只要調用了這些接口，就相當於調用了被調用方的實際方法，十分易用。於是，調用方可以像調用內部接口一樣調用遠程的方法，而不用封裝參數名和參數值等操作。
那要想實現這個過程該怎麼辦呢？別急，咱們一步一步來。
首先，調用方調用的是接口，必須得為接口構造一個假的實現。顯然，要使用動態代理。這樣，調用方的調用就被動態代理接收到了。
第二，動態代理接收到調用後，應該想辦法調用遠程的實際實現。這包括下面幾步：
- 識別具體要調用的遠程方法的IP、端口
- 將調用方法的入參進行序列化
- 通過通信將請求發送到遠程的方法中
這樣，遠程的服務就接收到了調用方的請求。它應該：
- 反序列化各個調用參數
- 定位到實際要調用的方法，然後輸入參數，執行方法
- 按照調用的路徑返回調用的結果
整個過程如下所示。
這樣，RPC操作就完成了。
調用方調用內部的一個方法，但是被RPC框架偷樑換柱為遠程的一個方法。之間的通信數據可讀性不需要好，只需要RPC框架能讀懂即可，因此效率可以更高。通常使用UDP或者TCP作為通訊協議，當然也可以使用HTTP。例如下面的示例中，為了保證實現最簡單，就用了HTTP進行通信。
講到這裡，RPC的產生原因、原理應該清楚了。為了讓大家真的明白，我寫了一個真的是最最簡單的RPC實現。把它放到了：
https://github.com/yeecode/EasyRPC
它包含一個客戶端，一個服務端。客戶端只要調用自身內部的接口，就通過這個小的RPC實現調用到了服務端的方法。
下面是客戶端的代碼，看著類有點多，其實代碼不長。其中的RPC代碼完成完成動態代理、遠程調用參數序列化、遠程調用發起、遠程調用結果反序列化的工作。
RPC客戶端
下面是服務端的代碼，代碼更少，完成遠程調用接收、調用參數反序列化、調用實際觸發、調用結果序列化的工作。
RPC服務端
這樣，一個RPC小框架就做完了，並不複雜。
所以，不要被RPC嚇到，它就是讓一個應用調用另一個應用中方法的一種實現方式。與調用遠程接口區別不大，條條大路通羅馬。
再說一次，不是說RPC好，也不是說HTTP好，兩者各有千秋。本質上，兩者是可讀性和效率之間的抉擇，通用性和易用性之間的抉擇。最終誰能發展更好，很難說。
要問我站誰？我根據業務場景，靈活站位……
閱讀更多 Java技術架構 的文章
