Java實戰技術2020-04-03 08:24:52首先 http 和 rpc 並不是一個並行概念。
rpc是遠端過程呼叫，其呼叫協議通常包含傳輸協議和序列化協議。
傳輸協議包含： 如著名的 ［gRPC］（grpc / grpc。io） 使用的 http2 協議，也有如dubbo一類的自定義報文的tcp協議。
序列化協議包含： 如基於文字編碼的 xml json，也有二進位制編碼的 protobuf hessian等。
因此我理解的你想問的問題應該是：為什麼要使用自定義 tcp 協議的 rpc 做後端程序通訊？
要解決這個問題就應該搞清楚 http 使用的 tcp 協議，和我們自定義的 tcp 協議在報文上的區別。
首先要否認一點 http 協議相較於自定義tcp報文協議，增加的開銷在於連線的建立與斷開。http協議是支援連線池複用的，也就是建立一定數量的連線不斷開，並不會頻繁的建立和銷燬連線。二一要說的是http也可以使用protobuf這種二進位制編碼協議對內容進行編碼，因此二者最大的區別還是在傳輸協議上。
HTTP有用資訊佔比少，畢竟HTTP工作在第七層，包含了大量的HTTP頭等資訊。其次是效率低，還是因為第七層的緣故。還有，其可讀性似乎沒有必要，因為我們可以引入閘道器增加可讀性。此外，使用HTTP協議呼叫遠端方法比較複雜，要封裝各種引數名和引數值。
通用定義的http1。1協議的tcp報文包含太多廢資訊，一個POST協議的格式大致如下：
HTTP/1。0 200 OK
Content-Type： text/plain
Content-Length： 137582
Expires： Thu， 05 Dec 1997 16：00：00 GMT
Last-Modified： Wed， 5 August 1996 15：55：28 GMT
Server： Apache 0。84
Hello World即使編碼協議也就是body是使用二進位制編碼協議，報文元資料也就是header頭的鍵值對卻用了文字編碼，非常佔位元組數。如上圖所使用的報文中有效位元組數僅僅佔約 30%，也就是70%的時間用於傳輸元資料廢編碼。當然實際情況下報文內容可能會比這個長，但是報頭所佔的比例也是非常可觀的。
那麼假如我們使用自定義tcp協議的報文如下：
報頭佔用的位元組數也就只有16個byte，極大地精簡了傳輸內容，採用自定義tcp協議的rpc來進行通訊減少了通訊內容，可以提高通訊效率。
所謂的效率優勢是針對http1。1協議來講的，http2。0協議已經最佳化編碼效率問題，像grpc這種rpc庫使用的就是http2。0協議。這麼來說吧http容器的效能測試單位通常是kqps，自定義tpc協議則通常是以10kqps到100kqps為基準
簡單來說成熟的rpc庫相對http容器，更多的是封裝了“服務發現”，“負載均衡”，“熔斷降級”一類面向服務的高階特性。可以這麼理解，rpc框架是面向服務的更高階的封裝。如果把一個http servlet容器上封裝一層服務發現和函式代理呼叫，那它就已經可以做一個rpc框架了。
所以為什麼要用rpc呼叫？因為良好的rpc呼叫是面向服務的封裝，針對服務的可用性和效率等都做了最佳化。單純使用http呼叫則缺少了這些特性。
網路圈2019-07-10 07:58:42在程式開發中，我們經常會呼叫第三方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框架優點就顯示出來了，比如說：
支援長連結，減少了網路開銷；
擁有註冊中心，服務治理起來更方便；
有監控功能，易於定位問題；
對呼叫方來說是無感知、統一化的。
以上就是我的觀點，對於這個問題大家是怎麼看待的呢？歡迎在下方評論區交流 ~ 我是科技領域創作者，十年網際網路從業經驗，歡迎關注我瞭解更多科技知識！
老白說IT2020-05-27 14:04:07樓主會有這樣的問題顯然是因為只看到了現狀而忽略了這兩種方式的歷史發展。
其實這個問題倒過來問可能會比較合適。
既然有了RPC請求為什麼還需要HTTP呢？
RPC早在上世紀80年代就被人用來做分散式系統的通訊，Java更是在早期的1。1版本就提供了Java版本的RPC框架（RMI）。
而HTTP協議則是1990年才開始作為主流協議出現，而且HTTP發明的場景是用於web架構。所以在很長一段時間內，HTTP只是用於瀏覽器程式和後端web系統通訊用的東西，而HTML幾乎是唯一的資料支援格式。如此笨重的HTML，沒有人會考慮使用HTTP作為分散式系統通訊的協議。在很長一段時間內，RPC才是正統。
然而隨著前端技術的發展，AJAX技術和JSON的大行其道，HTTP呼叫慢慢脫離了HTML，轉而使用JSON，這才為後面用於系統間呼叫定下基礎。
最後隨著RESTFUL思潮的興起，越來越多系統考慮用HTTP來提供服務，但這時候，RPC已經是各種大型分散式呼叫的標配了。
所以從歷史的程序來看，我們發現HTTP是後來者是追趕著，這個市場一直是被RPC霸佔著的。
那麼回到題主的問題，那既然現在有了HTTP這麼方便的技術，是不是我們就可以把RPC一腳踢開了？
不可否認，HTTP方式的溝通，給程式設計師們提供了大量便利。因為現在大部分的系統都是面向瀏覽器的（很多手機app也是使用HTML5來渲染的），因此使用HTTP協議，能夠保證系統間最大程度的技術棧一致，那無疑是維護成本最低的，而這時HTTP的技術生態也剛好滿足這個條件，所以燎原之勢一觸即發。
但是總是有部分系統，他們需要使用RPC，一可能是老架構，也不敢動這塊，二是效能要求可能只有RPC可以滿足。不過個人覺得現在的HTTP2的多路通訊已經對效能有了很大的提升，所以不是非常苛求效能的話，HTTP應該能夠滿足大部分需求。
J的程式碼2019-08-12 12:11:35首先：
http 和 rpc 並不是一個並行概念。
http是超文字傳輸協議，應用層網路協議。
rpc不是協議，是指remote procedure call 遠端過程呼叫，對不同應用間相互呼叫的一種描述。其呼叫協議通常包含傳輸協議和編碼協議；支援http和tcp；
其次：
rpc呼叫是面向服務的封裝，針對服務的可用性和效率等都做了最佳化。單純使用http呼叫則缺少了這些特性。
例如rpc框架提供的負載均衡，服務治理，自動熔斷/降級，實現二進位制傳輸等；
如果把一個http server容器上封裝一層服務發現和函式代理呼叫，那它就已經可以做一個rpc框架了。
總結：
RPC是一種程式設計模式，把對伺服器的呼叫抽象為過程呼叫，通常伴隨著框架程式碼自動生成等功能。使用RPC做網路服務開發時，通常只需要實現伺服器端的一個處理函式，其餘的客戶端呼叫，序列化反序列化，方法派發等都由框架或者生成的程式碼來完成，較大地減輕了網路服務開發和呼叫的複雜性。RPC框架更多的在內網中應用間呼叫使用，http 除了內網傳輸，更習慣用在跨網間，跨語言間呼叫。
猿天地2020-05-27 19:29:16一種協議更統一化，兩種協議混著用也不是不可以，具體還是看實際需求。比如你們內部有個 ID 分發的服務，呼叫量很高，就是對效能有這極致的要求。那麼這個場景你就可以用 Rpc 來代替 Http 了。其他的正常使用 Http 協議就行，特殊場景的就用 Rpc 協議，互補而已。
用 Http 最好的點在於簡單，傳輸內容就是文字，除錯什麼的都很方便。比如我要單獨測試某個服務的介面，直接 PostMan 上呼叫這個 Http 介面就可以了，或者用 Swagger。
如果是 Dubbo 的 Rpc， 我可能需要用 telnet 來呼叫。
其實在 Spring Cloud 慢慢進入企業後，有很多人都會遇到一個問題就是老的服務都是用 Dubbo 來通訊的，如果轉 Spring Cloud 技術棧，那麼勢必要去掉 Dubbo。
如果規模不大直接重構掉也沒關係，但是對於大規模的應用，服務數量眾多。不太可能一口吃成個胖子。就算要重構那也是一個一個的方式來，也就意味著在沒重構完之前，老的服務還是 Dubbo，但有一些服務已經變成 Spring Cloud 體系了。這個時候相容就是一個迫切需要解決的問題。
還有就是閘道器層的轉發，如果是 Http 協議，直接轉發過去了。如果是 Rpc 協議，閘道器內部需要轉特殊處理，當然目前也有支援 Rpc 的閘道器。如果我們是兩種協議，閘道器這邊還是直接 Http 轉發過去即可，內部服務之前想用什麼協議讓使用者自己決定。
冒泡的肥皂2020-05-30 00:47:44效率
春衫不薄2020-08-09 02:32:19一句話，http在效能上滿足不了。
山羊AM2020-05-28 23:37:21現在確實用http了，rpc就像是dubbo時代，http就像springcloud時代，總之技術無好壞，關鍵看怎麼實現
碼農452021-05-19 12:26:15從某種意義上來說，http也屬於rpc。
大部分公司開發，基本很少選擇rpc，除非是介面設計不得不用rpc，因為http呼叫目前比較廣泛，例如restfulAPI，基本是個web開發的程式設計師都知道，而rpc難度更高。
從效能上來說，http不如rpc的，http包含的內容太多，所以相比於rpc，http更佔記憶體和頻寬，在超高併發情況下，一般首選rpc。
從開發效率來說，http優勢比較大，如果開發效率比效能更重要的程式，還是選擇http比較好。如果需要支援高效能，高併發，其實還是選擇用rpc會比較好，例如配合protobuf序列化反序列化。
而有一些rpc框架，是支援雙向傳輸的，比如基於netty實現的，可以由服務端主動推送資料到客戶端，而http則不行，需要建立websocket連線。
對白、2020-07-20 09:28:25回答問題言簡意賅，
其實就是因為更快，效率更高
