在工作中偶然看到公司舊架構在loaclserver中使用的是thrift，遂記錄一下
thrif作為一種rpc框架 接口描述語言和二進制通信協議，至於為何使用thrift 其問題本質是為何在已有http的情況下使用rpc
HTTP協議，以其中的Restful規范為代表，其優勢很大。它可讀性好，且可以得到防火牆的支持、跨語言的支持。而且，在去年的報告中，Restful大有超過RPC的趨勢。
但是HTTP也有其缺點，這是與其優點相對應的。首先是有用信息占比少，畢竟HTTP工作在第七層，包含了大量的HTTP頭等信息。其次是效率低，還是因為第七層的緣故。還有，其可讀性似乎沒有必要，因為我們可以引入網關增加可讀性。此外，使用HTTP協議調用遠程方法比較復雜，要封裝各種參數名和參數值。
1、HTTP和RPC同一級別，還是被RPC包含？
2、Restful也屬於RPC么？
對於以上兩點，我畫圖來一一說明。
上圖是一個比較完整的關系圖，這時我們發現HTTP（圖中藍色框）出現了兩次。其中一個是和RPC並列的，都是跨應用調用方法的解決方案；另一個則是被RPC包含的，是RPC通信過程的可選協議之一。
因此，第一個問題的答案是都對。看指的是哪一個藍色框。從題主的提問看，既然題主在糾結這兩者，應該是指與RPC並列的藍色框。
第二個問題是在問遠程過程調用（紅色框）是不是包含了Restful（黃色框），這種理解的關鍵在於對RPC的理解。
RPC字面理解是遠程過程調用，即在一個應用中調用另一個應用的方法。那Restful是滿足的，通過它可以實現在一個應用中調用另一個應用的方法。
但是，上述理解使得RPC的定義過於寬泛。RPC通常特指在一個應用中調用另一個應用的接口而實現的遠程調用，即紅色框所指的范圍。這樣，RPC是不包含Restful的。
因此，第二個問題的答案是Restful不屬於RPC，除非對RPC有着非常規的寬泛理解。
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框架能讀懂即可，因此效率可以更高。通常使用UDP或者TCP作為通訊協議，當然也可以使用HTTP。
內網HTTP調用 通常會經過一個proxy（eg：nginx）再到達backend（實現下游路由配置、負載均衡、服務降級 熔斷），rpc框架自帶這些