悠閒風箏v2021-03-24 08:57:05現實中兩者區別不大，這點速度可以忽略不計，都是基於tcp實現的，不過傳輸資料格式不一樣，rpc可以基於http也可以基於tcp連結。
shermanz2020-10-11 20:05:29http 對應 tcp，RPC 對的是rest。這問題是orange vs apple， 不是一回事。jsonRPC 是可以走tcp protocal 也可以走 http。 但rest只能走http， 因為rest METHOD 在tcp 不存在。 gPRC 也可以走http通常走tcp。 如果是edge service， 一般要支援http協議。 TCP協議效率更高，不需要在http header上浪費很多不必要的資料，而且支援duplex很自然，這一點即使是http2也不完善，除非用websocket。 Micro service， 如果不是edge service，一般用tcp效率高，jsonRPC比較容易測試， gRPC資料可讀性差，但介面更嚴格效率更高，尤其是binary data 傳輸效率高，不需要轉換為base64。
每日精彩科技2021-03-24 22:56:42很高興能夠看到和回答這個問題！
RPC已經成為領先工程師（無論公司規模大小）必須掌握的技能之一，在微服務中得到了應用，一些大型企業還在繼續使用自己的微服務，這也是微服務發展前景很好的主要原因。
什麼是RPC框架？
RPC(remote procedure call)是指遠端計算機上的計算機程式在不熟悉子系統技術的情況下，可以透過網路請求服務的一種約定。
例如，兩個不同的服務A和B分別託管在兩臺不同的計算機上，但如果你想透過某種方式呼叫服務B，服務A怎麼辦？RPC來解決這個問題。
RPC主要是基於TCP/IP協議，而HTTP服務主要是基於HTTP協議，我們都知道HTTP是高於TCP傳輸層協議的，所以RPC在效率上無疑會發揮更大的作用。
當RPC主要應用於大型企業的時候，其優勢是顯而易見的，因為大型企業的系統多，業務流程複雜，效率優勢明顯。在實際的開發過程中，通常會使用maven來管理專案。
比如我們有一個系統服務處理訂單，先把所有的介面（特別是Java的介面）命名，然後把整個專案打包成jar包，注入這個雙向庫，然後執行相應的函式，然後客戶需要注入這個雙向庫來呼叫。
RPC框架是機器間的交流方式。
RPC的核心不是用什麼協議。RPC的目的是讓你能夠呼叫遠端方法，這個呼叫對你來說是透明的，你不知道具體在哪裡使用。用RPC來解耦服務，這才是使用RPC的真正目的。PKK原理主要用於動態代理模式，對於http：//tool協議，它只是一個傳輸協議。
微服務是在應用技術棧範疇，跟其他的應用技術一樣都是具有系統分析、建模的能力，並不是一個純粹的框架或技術，而是一個綜合性的架構模式。微服務是進化出來的。“解釋一個概念需要用另外幾個概念來解釋，但是解釋另外幾個概念還需要其他概念來解釋”，所以要聚焦領域，每個領域都是深不見底，都有他的知識體系，都有他的技術棧。
分散式RPC框架如下如所示：
比如在IM系統中，當使用短HTTP連線時（釋放後呼叫建立socket連線，呼叫IM建立IM例項時），吸收一個IM例項的效率至少可以達到幾萬甚至幾十萬QPS。）效率低下（每次呼叫必須經過三次TCP握手和四次普攻），這勢必會導致整個IM組的吞吐量下降。
對於RPC來說，這種套接字通訊對高場景下的效能影響很大。
微服務呼叫為什麼用RPC框架，http不更簡單嗎？
RPC的主要目標是簡化分散式計算（應用）的結構，同時提供強大的遠端呼叫功能，同時又不失本地呼叫的語義簡單。
為了實現這個目標，RPC框架需要建立一個透明的呼叫機制，使使用者無法明確區分本地呼叫和遠端呼叫。
RPC是一個軟體框架概念，它為開發分散式應用提供了一個理論框架。
舉個例子，為什麼你們家可以使用電廠提供的電？因為電是可以傳輸的。那為什麼大家更喜歡使用銅線？因為銅線傳輸電時損耗更小。其實這和微服務呼叫為什麼用RPC框架的道理是相通的，因為RPC框架能夠使微服務執行過程更為流暢！
以上便是我的一些見解和回答，可能不能如您所願，但我真心希望能夠對您有所幫助！不清楚的地方您還可以關注我的頭條號“每日精彩科技”我將竭盡所知幫助您！
碼字不易，感覺寫的還行的話，還請點個贊哦！
程式猿觀天下2020-02-29 12:07:26實際原因應該是比較簡單的，阿里構建dubbo應該是為了將單一系統分拆程多個系統，為了最小化減少已有系統改造的工作量，所以出現了rpc，目前在金融行業定長報文，變長報文等都是很成熟的，還有spring cloud，如果是一開始就搭建框架，建議用springcloud這樣的http協議，不建議用rpc這些框架，在跨語言呼叫的時候就會出現很大的問題
德藝雙馨抬槓藝術家2019-05-08 13:38:51什麼叫軟體工程，就是我們不管做什麼事，都不選最好的，只選最複雜的。
咱倆誰喝多了呢2020-11-27 08:10:22還有人把協議跟概念混為一談？rpc的動作可以依賴於各種協議，http也算是一種，restful只是基於http協議呼叫的一種變成風格。rpc=remote procedure call，直譯為“遠端過程呼叫”，它不是協議。例如dubbo，它是一個rpc框架，它有自己的dubbo協議，呼叫時基於tcp/ip協議傳送接受資料。springcloud的rpc就是restful風格的http協議傳輸方式。我甚至還看過我一本書上在對比http協議跟rpc？
LKC4442020-02-28 11:23:42RPC名稱是遠端服務呼叫。這裡面實際是沒有限制一定會是tcp，也可以是http或者其他基於tcp協議的服務。
遠端服務呼叫，有多種 ，http的介面呼叫，基於http的webservice，java中的rmi 實際都算是rpc。為什麼都向長連線改動。是因為技術性能的要求越來越高，必然帶來這樣的發展趨勢。
http介面，簡單通用，但是呼叫放需要編寫大量的程式碼去解析返回結果，並且http效能並不高效，除了header的問題之外，早期的http還不能多路複用。
webservice實際上是http協議之上的封裝，它更多是為了解決http介面呼叫需要編寫大量客戶端解析引數程式碼產生的，它能幫助少寫程式碼，但無法改善http的效能。
java的rmi 典型的就是ejb 現在新的java程式設計師可能都沒聽過這玩意，這也是基於長連線實現，基於java的序列化。它能夠解決客戶端引數解析的問題，也能多路複用socket 但是ejb本身的複雜性以及java序列化低效的問題導致它也是被放棄，並且它是不能跨語言的。
現在的rpc框架大多都是基於socket長連線，自定義協議實現。採用的序列化方式也會比較高效和跨語言。比如grpc 採用protobuf做序列化，採用http2做傳輸協議。
從某種意義上來講，http介面也能算是rpc呼叫，只是需要更具開發工作量以及效能指標做技術抉擇。
一笑638441112020-11-25 16:51:14基本都是複製黏貼，全是一個答案，沒看到有真正深入思考過的答案，還是我來說說吧。
前言：
其實計算機裡面的很多概念都是來源於現實世界的，透過現實裡面具體的例子來理解RPC。
A：
代表一棟大樓（相當於一個大的服務端內網叢集），
B：
代表大樓內的一個個房間（每個房間相當於一個應用框架），
C：
代表人員管理機構（相當於樓管處或者各級人口管理部門）。首先，在專案架構比較簡單的時候，可能一個專案就一個統一的框架，一種語言，這時候我們程式裡面的一個方法裡面可能會呼叫N個其他的方法，但因為都是在同一個框架內，都屬於框架級的內部呼叫，這個時候自然用不到RPC，RESTful足以滿足當前場景。 但是當你的專案架構越來越複雜，訪問量越來越多的時候，可能上了N多框架，N個語言，當你在業務裡面呼叫其他框架的方法或者呼叫其他獨立部署的服務的時候，自然沒法像最初那樣直接在框架/容器的內部去呼叫，當這種框架和容器間的這種呼叫量不是很大的時候依然可以選擇用RESTful方式去呼叫，但是當這種呼叫量很大，服務很多的時候，RESTful顯然是無法滿足需求的。
打個比方，最初的內部呼叫相當於你要找的人和你在同一個房間內，直接就可以找到。但當要找的人分散在大樓的各個房間的時候，你怎麼找他呢？你可以去區里人口部門查，查不到去市裡 - 省裡 - 國家人口管理部門查，最終肯定總能找到他，但這樣的方式是不是效率很低，路徑很長？所以這個時候就來了RPC解決了這個問題，我們在該大樓一樓建立了統一的樓管處（服務註冊中心），該出記錄了大樓裡面每個人的詳細資訊，每個人要先去登記（服務註冊），要查的時候直接去樓管處查（服務發現）就可以了。當然你可以直接走路（HTTP協議）去查，也可以直接打電話（TCP協議）去樓管處查，也可以微信群（自定義協議）去查。 首先該樓管處記錄的資訊量非常小（只記錄你們大樓的人），非常垂直和精確，所以你去查的速度會非常快，路徑會非常短。 如果你還用傳統RESTful的方式，首先查詢範圍會非常大，因為你根本不知道這個人到底在哪裡，他可能在你們大樓內，也可能在本市某個角落的大樓裡面，還可能在幾千公里外的另一個城市，你查詢的目標範圍會非常大，路徑會非常長，不確定性非常大。所以最終的效率肯定是非常低的。
完整的 RPC 框架
在一個典型 RPC 的使用場景中，包含了服務發現、負載、容錯、網路傳輸、序列化等元件，其中“RPC 協議”就指明瞭程式如何進行網路傳輸和序列化。
圖完整 RPC 架構圖
RPC和RESTful的區別
RPC的優勢：
是查詢的精確性，快速性，短路徑，和確定性，因為屬於內網查詢，獨立的註冊中心，所以查詢的速度更快。
而且由於做了精簡和最佳化，刪去了RESTful方式裡面很多多餘的資訊，比如Header，而且做了壓縮和序列化，透過二進位制方式傳輸，傳輸的內容更少，傳輸的速度也更快。
環節和流程更少，因為RESTful需要經過路由，負載均衡，閘道器，防火牆和一系列的身份識別和校驗，就像大樓內來了個不認識的人，樓管大叔肯定要查你的身份證等等資訊核實你的資訊。 而且RPC就省去了這些環節，就像你天天出來進去，樓管大媽早就對你很熟了，不需要每次核實你的資訊，RPC省去了很多環節。
RESTful的優勢：
通用性更好，RESTful可以供任何接入網際網路的終端呼叫，各種平臺，各種終端都可以用RESTful傳輸和交換資料，而且有一套標準和規範的傳輸格式，所以格式更加標準化和通用化。
呼叫及測試都很方便。RPC 實現需要實現編碼，序列化，網路傳輸等。而 RESTful 不要關注這些，RESTful 實現更簡單。
移植性更好，從一個伺服器遷移到另一個伺服器，從一個節點遷移到另一個節點，從一個架構移植到另一種架構，都可以輕鬆完成。
RPC的應用場景：
當你的框架和語言種類也比較多，內部子系統較多、介面非常多的情況下，RPC是最佳的選擇。RPC更多是內網之間的資料傳輸，效能消耗低，傳輸效率高，實現複雜。一般是部署在服務層的分散式系統裡面，或者微服務系統。有服務治理，服務限流、服務降級、服務熔斷、服務監控等等，類似於大樓裡面配了治安處，物業處、後勤處、監控中心等。
長連結。不必每次通訊都要像 HTTP 一樣去 3 次握手，減少了網路開銷。
註冊釋出機制。RPC 框架一般都有註冊中心，有豐富的監控管理；釋出、下線介面、動態擴充套件等，對呼叫方來說是無感知、統一化的操作。
安全性，沒有暴露資源操作。
微服務支援。就是最近流行的服務化架構、服務化治理，RPC 框架是一個強力的支撐。
RESTful的應用場景：
資料更多是公網上的傳輸，主要用於對外的異構環境，瀏覽器介面呼叫，App 介面呼叫，第三方介面呼叫等。
程式猿W2020-10-20 10:55:29RPC是一種概念，http是RPC實現的一種方式，用http互動其實就已經屬於rpc了！
RPC 協議名詞解釋
在一個典型RPC的使用場景中，包含了服務發現、負載、容錯、網路傳輸、序列化等元件，其中RPC協議就指明瞭程式如何進行網路傳輸和序列化 。也就是說一個RPC協議的實現就等於一個非透明的RPC呼叫，如何做到的的呢？
RPC 協議的組成
1。地址：服務提供者地址
2。埠：協議指定開放的埠
3。執行服務
netty
mina
RMI服務
servlet容器（jetty/tomcat/Jboss）
4。報文編碼：協議報文編碼 。注①：http 報文編碼 。注②：Dubbo 報文編碼
5。序列化方式
Hessian2Serialization
DubboSerialization
JavaSerialization
JsonSerialization
RPC協議報文編碼與實現詳解
1、HTTP協議報文
2、Dubbo協議報文
協議編解碼過程
Dubbo 支援的RPC協議列表
1、dubbo
實現描述：
傳輸服務： mina， netty（預設）， grizzy
序列化： dubbo， hessian2（預設）， java， fastjson 自定義報文
連線描述：
單個長連線
NIO非同步傳輸
適用場景：
1、常規RPC呼叫
2、傳輸資料量小 3、提供者少於消費者
2、rmi
實現描述：
傳輸：java rmi 服務
序列化：java原生二進位制序列化
連線描述：
多個短連線
BIO同步傳輸
適用場景：
1、常規RPC呼叫
2、與原RMI客戶端整合 3、可傳少量檔案 4、不支援防火牆穿透
3、hessian
實現描述：
傳輸服務：servlet容器
序列化：hessian二進位制序列化
連線描述：
基於Http 協議傳輸，
依懶servlet容器配置
適用場景：
1、提供者多於消費者
2、可傳大欄位和檔案 3、跨語言呼叫
4、http
實現描述：
傳輸服務：servlet容器
序列化：http表單
連線描述：
依懶servlet容器配置
適用場景：
1、資料包大小混合
RPC 傳輸實現
RPC的協議的傳輸是基於 TCP/IP 做為基礎使用Socket 或Netty、mina等網路程式設計元件實現。但有個問題是TCP是面向位元組流的無邊邊界協議，其只管負責資料傳輸並不會區分每次請求所對應的訊息，這樣就會出現TCP協義傳輸當中的拆包與粘包問題
拆包與粘包產生的原因
們知道tcp是以流動的方式傳輸資料，傳輸的最小單位為一個報文段（segment）。tcp Header中有個Options標識位，常見的標識為mss（Maximum Segment Size）指的是，連線層每次傳輸的資料有個最大限制MTU（Maximum Transmission Unit），一般是1500位元，超過這個量要分成多個報文段，mss則是這個最大限制減去TCP的header，光是要傳輸的資料的大小，一般為1460位元。換算成位元組，也就是180多位元組。
tcp 為 提高效能，傳送端會將需要傳送的資料傳送到緩衝區，等待緩衝區滿了之後，再將緩衝中的資料傳送到接收方。同理，接收方也有緩衝區這樣的機制，來接收資料。這時就會出現以下情況：
應用程式寫入的資料大於MSS大小，這將會發生拆包
應用程式寫入資料小於MSS大小，這將會發生粘包
接收方法不及時讀取套接字緩衝區資料，這將發生粘包。
拆包與粘包解決辦法
設定定長訊息，服務端每次讀取既定長度的內容作為一條完整訊息
{“type”：“message”，“content”：“hello”}\n
使用帶訊息頭的協議、訊息頭儲存訊息開始標識及訊息長度資訊，服務端獲取訊息頭的時候解析出訊息長度，然後向後讀取該長度的內容。
Yan1420409652020-01-15 13:39:33都沒說到點子上。微服務使用的RPC是基於HTTP2的gRPC，傳輸格式使用binary的protobuf，比json更快，HTTP2支援multiplexing， concurrency， streaming。
會點程式碼的大叔2020-02-27 09:04:41RPC：Remote Procedure Call，中文意思就是遠端過程呼叫。
那麼我們先看看題目中的問題，其實，這個問題本身就是有問題的！
01。 既然有 HTTP ，為什麼還要用 RPC ？
HTTP 和 RPC 並不是兩個並行的概念，雖然很多書或文章，都介紹 HTTP 和 RPC 是在“應用層”，但實際上可以把應用層細分成多層，RPC 的所處的位置是高於 HTTP 的；HTTP 是網路協議，而RPC 可以看做是一種程式設計模式或實現方案；
RPC 通常包含傳輸協議和序列化協議，單說傳輸協議，RPC 可以建立在 TCP 協議之上（比如 Dubbo），也可以建立在 HTTP 協議之上（比如 gRPC）；如果是基於資料形式分類，RPC 又可以分成基於二進位制、XML 和 JSON 三種；
而現在非常流行的開源 RPC 框架，比如上文中提到的Dubbo 和 gRPC 分別出身於阿里和谷歌，它們更多地是封裝了服務註冊發現、負載均衡、鏈路跟蹤等功能，也可以這麼理解，RPC 框架是對服務更高階的封裝。
02。 RPC VS Restful 風格的 API
如果非要比較的話，可以比較 RPC 和 Restful 風格的 API。
RPC：
面向過程，也就是要做一件什麼事情，只發送 GET 和 POST 請求；GET 用來查詢資訊，其他情況下一律用 POST；請求引數是動詞。
RESTful：
面向資源，這裡的資源可以是一段文字、一個檔案、一張圖片，總之是一個具體的存在，可以使用 GET、POST、DELETE、PUT 請求，對應了增刪查改的操作；請求引數是名詞。
比如按照id 查詢使用者：
如果是 RPC 風格的 url 應該是這樣的：GET /queryUser？userid=xxx；
而 RESTful 風格通常是這樣的：GET /user/{userid}
03。 究竟選擇哪一個？
RPC 特別適用於是分散式環境；它讓客戶端進行遠端呼叫時，可以像呼叫本地方法一樣方便；RPC 框架遮蔽了很多底層的細節，開發人員不需要關注這些細節，比如序列化和反序列化、網路傳輸協議；一些功能強大的 RPC 框架還提供了連線池管理、負載均衡、故障轉移、超時管理、上下文管理器、非同步回撥、收發包佇列、工作執行緒等功能。
RPC 和 Restful 風格的 API，如果非要爭出來個第一第二，那麼也要結合具體的使用場景，選擇更適合的那個。
如果是偏向內部的 API，提供的 API 很難進行資源的抽象，沒有規範的 API 的設計，效能要求更高，這些情況下更適合使用 RPC ；如果偏向外部 API，需要有更為規範的 API 設計，並且 API 天生是以資源為維度展開的，這時候可以選擇 Restful 風格的 API。
我將持續分享Java開發、架構設計、程式設計師職業發展等方面的見解，希望能得到你的關注。
