说到gRPC，实际应用还是第一次，之前只是看到过很多地方都在使用，例如咱们常用的腾讯QQ管家，就会看到在进程中有个RPC的进程一直在运行。

那么什么是gRPC，为什么要用gRPC呢，带着这样的问题跟随我一步步去揭开gRPC的神秘面纱。

 

gRPC 是一种与语言无关的高性能远程过程调用 (RPC) 框架。

gRPC 的主要优点是：

• 现代高性能轻量级 RPC 框架。
• 协定优先 API 开发，默认使用协议缓冲区，允许与语言无关的实现。
• 可用于多种语言的工具，以生成强类型服务器和客户端。
• 支持客户端、服务器和双向流式处理调用。
• 使用 Protobuf 二进制序列化减少对网络的使用。

这些优点使 gRPC 适用于：

• 效率至关重要的轻量级微服务。
• 需要多种语言用于开发的 Polyglot 系统。
• 需要处理流式处理请求或响应的点对点实时服务。 　

 

以下这段文章摘录自：https://www.cnblogs.com/qingfenglin/p/12028763.html

>>>

首先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通信。

ClientRequest：1，ServerResponse：1

(2) 服务端数据流模式（Server-side streaming RPC）

这种模式是客户端发起一次请求，服务端返回一段连续的数据流。典型的例子是客户端向服务端发送一个股票代码，服务端就把该股票的实时数据源源不断的返回给客户端。

ClientRequest：1，ServerResponse：N

(3) 客户端数据流模式（Client-side streaming RPC）

与服务端数据流模式相反，这次是客户端源源不断的向服务端发送数据流，而在发送结束后，由服务端返回一个响应。典型的例子是物联网终端向服务器报送数据。

ClientRequest：N，ServerResponse：1

(4) 双向数据流模式（Bidirectional streaming RPC）

这是客户端和服务端都可以向对方发送数据流，这个时候双方的数据可以同时互相发送，也就是可以实现实时交互。比如聊天应用。

ClientRequest：N，ServerResponse：N

<<<

 

有了 gRPC， 我们可以一次性的在一个 .proto 文件中定义服务并使用任何支持它的语言去实现客户端和服务器，反过来，它们可以在各种环境中，从Google的服务器到你自己的平板电脑—— gRPC 帮你解决了不同语言间通信的复杂性以及环境的不同。

之后便可以无限制的进行通讯了。