剛接觸RPC時只知道概念是遠程過程調用協議，分為服務端和客戶端，客戶端請求服務端，服務端再回應客戶端，粗看和HTTP一應一答沒有什么區別。既然有着存在即合理的說法，網上找找說法，有的講的太深感覺太啰嗦，有的自己用了也沒了解為什么要用。自己看了后總結一下，可能不是很對。
首先RPC和HTTP不是同層次概念，HTTP是WEB的通信協議，RPC應該是在HTTP更上層的一種通信概念或者規范，PRC框架程序本身需要使用通信協議和數據協議來實現，換句話說就是可以用HTTP作為通信協議來實現RPC框架。以簡單的HTTP和JSON來實現也可以說符合RPC定義，但是幾乎沒有人會這么做，因為低效，和直接使用HTTP請求沒啥區別。
現在一些RPC框架基本用來服務於后端的通信。隨着業務越來越復雜，系統會拆分成不同的服務，比如用中心，財務中心等等，用戶的一個業務請求由多個服務來處理，服務於服務之間有着頻繁的通信。這種場景中如果用curl請求http接口性能上是低效的，因為http請求會帶一大堆頭報文信息，而且http會頻繁的建立連接和斷開連接消耗資源。而目前的主流RPC框架服務端和客戶端之間的通信基本是長連接或者連接復用等來避免頻繁建立斷開連接的情況，而且RPC通信也不會帶很多報文頭信息增加通信成本。因此這些框架是面向服務的。當然在master-slave集群通信中，如果RPC框架程序符合通信需求，也是可以使用的，總比你自己封裝一套socket通信要省力。
關於GRPC，官方的介紹是：gRPC 是一個高性能、開源和通用的 RPC 框架，面向移動和 HTTP/2 設計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多復用請求等特。這些特性使得其在移動設備上表現更好，更省電和節省空間占用。從定義上可以看到這個主要是給移動應用做通信用的，其次他支持雙向的通信，因此可以說GRPC是一個RPC框架沒錯，但是它的功能已經強於RPC，因為普通RPC是定義是一應一答的單向通信模式，而GRPC支持雙向通信，畢竟做不到雙向通信怎么能說是給移動應用設計的呢？
gRPC主要有4種請求／響應模式，分別是：
(1) 簡單模式（Simple RPC）
客戶端發起一次請求，服務端響應一個數據，即標准RPC通信。
(2) 服務端數據流模式（Server-side streaming RPC）
這種模式是客戶端發起一次請求，服務端返回一段連續的數據流。典型的例子是客戶端向服務端發送一個股票代碼，服務端就把該股票的實時數據源源不斷的返回給客戶端。
(3) 客戶端數據流模式（Client-side streaming RPC）
與服務端數據流模式相反，這次是客戶端源源不斷的向服務端發送數據流，而在發送結束后，由服務端返回一個響應。典型的例子是物聯網終端向服務器報送數據。
(4) 雙向數據流模式（Bidirectional streaming RPC）
這是客戶端和服務端都可以向對方發送數據流，這個時候雙方的數據可以同時互相發送，也就是可以實現實時交互。比如聊天應用。
網上看到的一個GRPC雙向通信的示例介紹：https://www.2cto.com/kf/201805/745745.html
總結：RPC框架一般用於后端服務數據通信比較大很頻繁的場景。通信少時RPC和HTTP都可以用，怎么簡單怎么來，滿足需要就可。GRPC面向移動應用，當然它是通用的，后端也可以用，比較強大，支持雙向通信。