段勇賓
本文介紹了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。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 接口調用，第三方接口調用等。
