rpc (遠程過程調用）
遠程過程調用。
RPC 的主要功能目標是讓構建分布式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性。
比如服務A想要調用服務B上的某個方法/函數，使用方可以忽略底層的傳輸層的細節，專注於方法的使用。就像調用一個本地函數，使用十分便捷，不需要關心接口的url，校驗規則，返回值解析等過程。
thrift:
一種接口描述語言和二進制通訊協議，它被用來定義和創建跨語言的服務。它被當作一個遠程過程調用（RPC）框架來使用，是由Facebook為“大規模跨語言服務開發”而開發的RPC框架，現已由Apache管理和開源。
rpc vs http
rpc優點：
- 支持多種編碼和傳輸協議，可以針對不同的場景選擇不同的設計方案，更加靈活可用。
- rpc的傳輸效率更加高效，比restful更加簡潔，節約帶寬。（比如thirft中的TCompactProtocol， 使用高效率的、密集的二進制編碼格式進行數據傳輸, 比json更加高效）
- 簡化了交互邏輯。原來跨系統調用的時候，一般使用 http 的方式進行交互。程序員之間要反復交流，針對接口反復確認。最后花了很多時間在這個上面。而且交互代碼會寫的比較麻煩：拼接 URL 參數、寫調用 http 代碼、解析調用結果，如果出錯還要寫重試代碼。使用 thrift 以后，整個這些操作都被封裝到框架底層：針對接口的討論，只要給出 idl ，剩余的事情都讓機器去確認。同時，整個開發邏輯也極大簡化，基本就幾行代碼。
- 接口更加明確，有 idl 這個天然的接口文檔，少一個參數都編譯不通過，大大減少了因為接口參數問題出現的 bug 。
- 可以建立長連接(比如建立長連接TCP通道)，不必每次通信都要像http一樣去3次握手什么的，減少了網絡開銷。
- rpc是建立在TCP協議的socket通信上的，而web api是建立在HTTP/HTTPS協議上的，rpc天然地性能會更高。
rpc不足:
- thrift的IDL是靜態化的，客戶端調用的時候，依賴於按照接IDL生成的客戶端接口代碼（SDK），一旦想要變更接口規則，那么對於客戶端而言，需要更新客戶端SDK，並重新編譯、生成可執行代碼。 但是基於restful的web服務是動態化的，對於接口的變更，客戶端的改動要容易得多。
- 維護成本高，尤其當客戶端使用多種不同語言時，每次接口的變動都需要更新一堆不同語言的SDK， 這是維護升級的噩夢。
http 優點:
- 輕量級，簡單易用。無需要額外的SDK，維護性和擴展性都比較好 。
- 可以基於https協議，安全性較高
http不足:
- 只支持http/https協議，使用時需要關注協議和網絡層的細節，而且http協議交互過程比較復雜(TCP三次握手，http協議報頭較為復雜)
http vs 高性能二進制協議
- http相對更規范，更標准，更通用，無論哪種語言都支持http協議。如果你是對外開放API，例如開放平台，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，相應的，如果采用http，無疑在你實現SDK之前，支持了所有語言，所以，現在開源中間件，基本最先支持的幾個協議都包含RESTful。
- RPC協議性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能達到http的二倍。響應時間也更為出色。
使用場景：
http: 對外提供的服務，更加規范、通用、易擴展、已維護，具有較高的安全性(https)。
rpc: 對內提供的服務，尤其適用於需要進行大量數據交互的服務(thrift提供高效的壓縮協議，交互更加簡潔，吞吐量更大)、 高頻率交互的服務(可以考慮建立TCP長連接，比如即將開工的大權限系統)
性能對比:
還可以參考這篇文章：
IDL
IDL是Interface description language的縮寫，指接口描述語言，是CORBA規范的一部分，是跨平台開發的基礎。
IDL是用來描述軟件組件接口的一種計算機語言。IDL通過一種中立的方式來描述接口，使得在不同平台上運行的對象和用不同語言編寫的程序可以相互通信交流；比如，一個組件用C++寫成，另一個組件用Java寫成。
IDL通常用於遠程調用軟件。 在這種情況下，一般是由遠程客戶終端調用不同操作系統上的對象組件，並且這些對象組件可能是由不同計算機語言編寫的。IDL建立起了兩個不同操作系統間通信的橋梁。