sunyoson
在程序開發中，我們經常會調用第三方API，而這類API一般提供多種方式供我們調用，比如：基於HTTP協議的、還有RPC方式調用的，以致於很多人會有這種質疑：既然有了HTTP這種請求方式，為什麼還有RPC的存在？
HTTP和RPC是完全不同的概念
在這裡我們需要搞清楚一點的是，HTTP和RPC在概念上就是不同的，兩種是不能相提並論的。
HTTP是超文本傳輸協議；
RPC是指遠程過程調用，它是對不同系統間相互調用方式的一種描述，RPC不是協議也不是一種新技術，嚴格意義上應該稱它是一種解決方案（概念）或技術實現的框架。RPC框架底層一般支持多種協議，比如：HTTP、TCP、自定協議等。
所以說RPC也是可以通過HTTP來實現的！
RPC與HTTP調用的應用場景
RPC框架提供的是面向服務的封裝，它針對服務的性能效率、可用性等都做了優化（比如提供了：註冊中心、服務治理、負載均衡、二進制傳輸、熔斷、服務降級等功能），是一套完整的解決方案；而HTTP調用缺少這些高級特性，它只是簡單的數據通信，另外HTTP API受限於HTTP協議（要帶HTTP請求頭），傳輸效率及安全性不如RPC。
為什麼使用RPC而不是簡單的HTTP API？
HTTP API一般在接口數量不多的情況下采用的，因為它使用起來簡單快捷，直接利用現成的HTTP協議就可以進行數據傳輸。
但對於一個大型項目，內部模塊子系統眾多，接口也變得很多了，在這種情況下如果再使用一個個零散的HTTP API，維護成本極高。所以RPC框架優點就顯示出來了，比如說：
支持長鏈接，減少了網絡開銷；
擁有註冊中心，服務治理起來更方便；
有監控功能，易於定位問題；
對調用方來說是無感知、統一化的。
以上就是我的觀點，對於這個問題大家是怎麼看待的呢？歡迎在下方評論區交流 ~ 我是科技領域創作者，十年互聯網從業經驗，歡迎關注我瞭解更多科技知識！
網絡圈
首先：
http 和 rpc 並不是一個並行概念。
http是超文本傳輸協議，應用層網絡協議。
rpc不是協議，是指remote procedure call 遠程過程調用，對不同應用間相互調用的一種描述。其調用協議通常包含傳輸協議和編碼協議；支持http和tcp；
其次：
rpc調用是面向服務的封裝，針對服務的可用性和效率等都做了優化。單純使用http調用則缺少了這些特性。
例如rpc框架提供的負載均衡，服務治理，自動熔斷/降級，實現二進制傳輸等；
如果把一個http server容器上封裝一層服務發現和函數代理調用，那它就已經可以做一個rpc框架了。
總結：
RPC是一種編程模式，把對服務器的調用抽象為過程調用，通常伴隨著框架代碼自動生成等功能。使用RPC做網絡服務開發時，通常只需要實現服務器端的一個處理函數，其餘的客戶端調用，序列化反序列化，方法派發等都由框架或者生成的代碼來完成，較大地減輕了網絡服務開發和調用的複雜性。RPC框架更多的在內網中應用間調用使用，http 除了內網傳輸，更習慣用在跨網間，跨語言間調用。
