RPC：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。

RPC名稱是遠端服務呼叫。這裡面實際是沒有限制一定會是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呼叫，只是需要更具開發工作量以及效能指標做技術抉擇。

socket通訊起個名字叫rpc確實洋氣了不少，http也是rpc的一種，只是有些資料頭而已，看似效率會稍微低一些。

看業務量和計算量。一般小網站，那幾臺機器，多此一舉。

業務多型化用rpc，基本都是自動生成程式碼，業務簡單api足夠

本文介紹了gRPC服務與HTTP API（包括ASP.NET Core Web API）在微服務呼叫下的比較。為您的應用程式提供API的技術是一個重要的選擇，與HTTP API相比，gRPC具有獨特的優勢。本文討論了gRPC的優點和缺點，並建議了將gRPC應用於其他技術的方案。

高層比較

下表對gRPC和帶有JSON的HTTP API之間的功能進行了高階比較。

gRPC的優勢效能

gRPC訊息使用Protobuf（一種有效的二進位制訊息格式）進行序列化。Protobuf在伺服器和客戶端上非常快速地序列化。Protobuf序列化可產生較小的訊息負載，這在移動應用程式等頻寬有限的情況下很重要。

gRPC專為HTTP / 2（HTTP的主要版本）而設計，與HTTP

1.x

相比，它提供了顯著的效能優勢：

二進位制成幀和壓縮。HTTP / 2協議在傳送和接收方面都是緊湊高效的。在單個TCP連線上多個HTTP / 2呼叫的複用。多路複用消除了行頭阻塞。

程式碼生成

所有gRPC框架都為程式碼生成提供了一流的支援。gpro開發的核心檔案是.proto檔案，該檔案定義gRPC服務和訊息的約定。gRPC框架將從該檔案中程式碼生成服務基類，訊息和完整的客戶端。

透過在伺服器和客戶端之間共享.proto檔案，可以從頭到尾生成訊息和客戶端程式碼。客戶端的程式碼生成消除了客戶端和伺服器上訊息的重複，併為您建立了一個強型別的客戶端。無需編寫客戶端，可以在具有許多服務的應用程式中節省大量的開發時間。

嚴格規格

帶有JSON的HTTP API的正式規範不存在。開發人員在爭論URL，HTTP動詞和響應程式碼的最佳格式。

該GRPC規範是規定有關GRPC服務必須遵循的格式。gRPC消除了爭論，並節省了開發人員時間，因為gRPC在各個平臺和實現中都是一致的。

流媒體

HTTP / 2為長期的實時通訊流提供了基礎。gRPC為透過HTTP / 2進行流傳輸提供了一流的支援。

gRPC服務支援所有流組合：

無串流；伺服器到客戶端流；客戶端到伺服器流；雙向流。

截止日期/超時和取消

gRPC允許客戶端指定他們願意等待RPC完成多長時間。該期限被髮送到伺服器，伺服器可以決定它是否超出了限期採取什麼行動。例如，伺服器可能會在超時時取消正在進行的gRPC / HTTP /資料庫請求。

透過子gRPC呼叫傳播截止日期和取消，有助於強制執行資源使用限制。

gRPC建議方案

gRPC非常適合以下情況：

微服務。gRPC專為低延遲和高吞吐量通訊而設計。gRPC對於效率至關重要的輕量級微服務非常有用。點對點實時通訊。gRPC對雙向流具有出色的支援。gRPC服務可以實時推送訊息而無需輪詢。多種語言環境。gRPC工具支援所有流行的開發語言，因此gRPC是多語言環境的理想選擇。網路受限的環境。gRPC訊息使用Protobuf（一種輕量級訊息格式）進行了序列化。gRPC訊息始終小於等效的JSON訊息。gRPC的弱點

有限的瀏覽器支援

今天，不可能從瀏覽器直接呼叫gRPC服務。gRPC大量使用HTTP / 2功能，並且沒有瀏覽器提供支援gRPC客戶端的Web請求所需的控制級別。例如，瀏覽器不允許呼叫者要求使用HTTP / 2，或提供對基礎HTTP / 2框架的訪問。

gRPC-Web是gRPC團隊的另一項技術，可在瀏覽器中提供有限的gRPC支援。gRPC-Web由兩部分組成：一個支援所有現代瀏覽器的JavaScript客戶端，以及伺服器上的一個gRPC-Web代理。gRPC-Web客戶端呼叫代理，代理將根據gRPC請求轉發到gRPC伺服器。

gRPC-Web並非支援所有gRPC的功能。不支援客戶端和雙向流，並且對伺服器流的支援有限。

不可讀

HTTP API請求以文字形式傳送，並且可以由人類讀取和建立。

預設情況下，gRPC訊息使用Protobuf編碼。儘管Protobuf可以高效地傳送和接收，但其二進位制格式不是人類可讀的。Protobuf要求在.proto檔案中指定的訊息介面描述才能正確反序列化。需要額外的工具來分析網上的Protobuf有效載荷並手動撰寫請求。

存在諸如伺服器反射和gRPC命令列工具之類的功能來輔助二進位制Protobuf訊息。另外，Protobuf訊息支援與JSON之間的轉換。內建的JSON轉換提供了一種在除錯時將Protobuf訊息與人類可讀格式之間相互轉換的有效方法。

替代框架方案

在以下情況下，建議在gRPC上使用其他框架：

瀏覽器可訪問的API。瀏覽器不完全支援gRPC。gRPC-Web可以提供瀏覽器支援，但是它有侷限性並引入了伺服器代理。廣播實時通訊 。gRPC支援透過流傳輸進行實時通訊，但是不存在將訊息廣播到註冊的連線的概念。例如，在聊天室場景中，應將新的聊天訊息傳送到聊天室中的所有客戶端，要求每個gRPC呼叫將新的聊天訊息單獨流式傳輸到客戶端。SignalR是此方案的有用框架。SignalR具有持久連線的概念，並內建了對廣播訊息的支援。程序間通訊。程序必須託管HTTP / 2伺服器才能接受傳入的gRPC呼叫。對於Windows，程序間通訊管道是一種快速，輕便的通訊方法。

簡單點，HTTP是協議，RPC是概念！實現RPC可以基於HTTP協議（Feign），TCP協議(Netty)，RMI協議（Soap），WebService（XML—RPC）框架。傳輸過程中，也因為序列化方式的不同，又有一些框架和協議，比如Dubbo中的Dubbo協議，gRpc—Protobuf序列化協議等等。其實，都是基於遠端呼叫的概念，何為遠端呼叫？

重點是，RPC就是遠端呼叫，遠端呼叫就是客戶端把呼叫的介面，引數，引數型別，方法，返回值，返回值型別等（這些稱為方法簽名），透過如上的協議，傳送給服務端，告知服務端需要呼叫的介面方法，這個過程就是RPC的實現過程！HTTP和RPC是不同層面的兩個東西！

效能方面，HTTP本身是基於TCP協議的，屬於應用層協議，所以HTTP協議本身在實現過程中就會佔用大量的資源（記憶體，頻寬等），效能上肯定沒有透過TCP直接實現RPC協議快，不管HTTP如何最佳化肯定的是不如TCP的！而TCP則是依靠位元組碼，現在普遍採用的是將客戶端呼叫的介面資訊，序列化的方式傳送給服務端，序列化框架又包含很多（Hession，Protobuf，Kryo等等，序列化效能最高的是Kryo，序列化後位元組碼最小的是Protobuf），序列化後的位元組碼越小，佔用頻寬越少，序列化時間越短，執行緒IO等待時間就會越小。所以，在具體應用層面有很多可探討的技術，可以根據自己的硬體能力來選擇相應的技術就可以了！

RPC，遠端過程呼叫，透過網路從遠端計算機程式上請求服務。瀏覽器請求 web 服務完成可以理解為就是 RPC 呼叫，現在你搞清楚了嗎？RPC 是概念名詞，http 是資料傳輸協議，這兩者是不同的。我們來看看市面上的一些 RPC 框架

gRPC，支援的傳輸協議 http/2dubbo，支援的傳輸協議 Dubbo，http 等

接下來順便講下 RPC 框架一般會有的功能

服務註冊，微服務啟動起來後，肯定要告訴下服務註冊中心，本服務已經啟動起來服務發現，透過服務註冊中心拿到所有啟動起來的服務的服務地址客戶端負載均衡，我現在透過服務註冊中心拿到一組服務地址了，總得選擇一個，那麼應該選擇哪個？這時候就需要依賴於負載均衡演算法了傳輸協議，資料傳輸前自然是要序列化，然後透過客戶端與服務端都支援的協議進行交流，協議可以是自研的協議，也可以是 http 協議

RPC 框架的設計自然不止我講的這些，但是作為了解其實已經足夠了

http 對應 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.

RPC是一種概念，http是RPC實現的一種方式，用http互動其實就已經屬於rpc了！

RPC 協議名詞解釋

在一個典型RPC的使用場景中，包含了服務發現、負載、容錯、網路傳輸、序列化等元件，其中RPC協議就指明瞭程式如何進行網路傳輸和序列化 。也就是說一個RPC協議的實現就等於一個非透明的RPC呼叫，如何做到的的呢？

RPC 協議的組成

1.地址：服務提供者地址

2.埠：協議指定開放的埠

3.執行服務

nettyminaRMI服務servlet容器(jetty/tomcat/Jboss)

4.報文編碼：協議報文編碼 。注①:http 報文編碼 。注②:Dubbo 報文編碼

5.序列化方式

Hessian2SerializationDubboSerializationJavaSerializationJsonSerializationRPC協議報文編碼與實現詳解

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使用帶訊息頭的協議、訊息頭儲存訊息開始標識及訊息長度資訊，服務端獲取訊息頭的時候解析出訊息長度，然後向後讀取該長度的內容。

基本都是複製黏貼，全是一個答案，沒看到有真正深入思考過的答案，還是我來說說吧。

前言：其實計算機裡面的很多概念都是來源於現實世界的，透過現實裡面具體的例子來理解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 介面呼叫，第三方介面呼叫等。

RPC 和 http 能比嗎？RPC 是一個統稱。http也能用作RPC。就好比“食物”和“玉米”，玉米可以用來做食物。

還有人把協議跟概念混為一談?rpc的動作可以依賴於各種協議，http也算是一種，restful只是基於http協議呼叫的一種變成風格。rpc=remote procedure call，直譯為“遠端過程呼叫”，它不是協議。例如dubbo，它是一個rpc框架，它有自己的dubbo協議，呼叫時基於tcp/ip協議傳送接受資料。springcloud的rpc就是restful風格的http協議傳輸方式。我甚至還看過我一本書上在對比http協議跟rpc?

http基於tcp的一種應用層協議，rpc是遠端過程呼叫，是一種概念。基於rpc進行開發的話也需要自定義實現應用層的協議，比如dubbo協議。http協議因為是一種標準協議，更通用，所以http協議的附加資訊會更多，所以在有效資訊相同的情況下http協議的總資料量會更多，所以一般來說http協議傳輸效率更低。

首先微服務也有用http的，現在流行的feign，底層就是http，也是我們經常提到的restful程式設計方式。

Rpc在國內最具有代表的是dubbo，底層可以選擇netty進行通訊，速度肯定是比http快的。

但是微服務不是一個簡單的呼叫，涉及到很多方面，比如容錯，高併發，熔斷，事務等等。普通的http程式碼是無法解決這些問題的。一般需要很多元件來配合，比如feign就要配合robbin，hystrix等來配合，dubbo也需要zookeeper來配合。

所以這兩者在我們的開發中，都很常見。

HTTP 是網路協議，而RPC 可以看做是一種程式設計模式或實現方案。

RPC 通常包含傳輸協議和序列化協議，單說傳輸協議，RPC 可以建立在 TCP 協議之上（比如 Dubbo），也可以建立在 HTTP 協議之上（比如 gRPC）；如果是基於資料形式分類，RPC 又可以分成基於二進位制、XML 和 JSON 三種；

而現在非常流行的開源 RPC 框架，比如Dubbo 和 gRPC 分別出身於阿里和谷歌，它們更多地是封裝了服務註冊發現、負載均衡、鏈路跟蹤等功能，可以理解為，RPC 框架是對服務更高階的封裝。

如果把一個http server容器上封裝一層服務發現和函式代理呼叫，那它就已經可以做一個rpc框架了。

良好的rpc呼叫是面向服務的封裝，針對服務的可用性和效率等都做了最佳化。單純使用http呼叫則缺少了這些特性。

而兩者其實各有千秋，在效能方面，RPC肯定是佔優勢的，但至於這種優勢有多大意義，涉及到的情況就很多了，比如併發，資料量等等。而其他一些方面，比如安全性，開發成本，適用性等方面，可能http優勢更大。

首先http是一種通訊協議，而rpc是遠端過程呼叫，在這裡http只是實現rpc的一種方式，估計你想問的是比較使用tcp/ip socket長連的方式和使用http短連 方式來做rpc，長連在效能上是要高於短連的，http要更加簡單靈活，主要看你專案取捨

先說說RPC和http的概念吧，詳見百度百科。

目前很多主流的RPC框架，底層都有用到http來進行通訊：

例如Dubbo、feign、openfeign底層都有用到http，為什麼大家現在喜歡用RPC

了，個人覺得一個重要的原因是微服架構的盛行，往往一個服務的組成都是由叢集構成，RPC框架這個時候就發揮出了靈活的優勢，不必須要知道後臺服務的IP地址，就可以進行呼叫，HTTP就需要不停的更改配置，靈活易用成都遠遠不如RPC

RPC框架是一種架構理念，能夠通訊獲取資料並建立連線的協議，都可以叫RPC協議。http協議也屬於RPC框架，因為http能建立通訊連線，相對應的，Dubbo、Redis、TCP、hessian等都屬於RPC框架。

另外，RPC框架支援自定義擴充套件自定義協議，而http是一種固定的格式。

Dubbo微服務框架底層如果採用zookeeper加dubbo協議的話本質還是rpc。而Spring Cloud採用的Eureka通訊Feign跟RestTemplate底層還是http協議封裝的服務，透過Ribbon呼叫，也算是rpc呼叫。

阿里Spring Cloud Alibaba既支援Dubbo，也支援Spring Cloud微服務。通訊註冊中心支援Zookeeper和Nacos，RPC和http都支援。

RPC是一個大類，Http屬於RPC中的小類

首先你沒明白啥是RPC，我明白你肯定是說http可以實現服務介面之間的呼叫，你呼叫介面是不是需要需要知道對應服務的域名，後期對方域名改變是不需要同步通知到你，再者服務之間不可能隨便讓你呼叫，是不還有很多鑑權邏輯，你可以用http去做，等你把這一整套完整的邏輯實現，再進行封裝差不多也可以是一個RPC服務了

這兩個根本不是一回事

RPC是一個大系統。包括服務註冊，發現，呼叫，治理，健康檢查等等。

Http只是服務呼叫中資料傳輸的協議。

一個是湖，一個是漁船，毫無可比性，更談不上用http更簡單。因為大家解決的都不是同一個問題。