关于RPC与HTTP以及GRPC的个人理解和应用场景分析

    刚接触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面向移动应用，当然它是通用的，后端也可以用，比较强大，支持双向通信。