RPC（Remote Procedure Call，远程过程调用），是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。如果涉及的软件采用面向对象编程，那么远程过程调用亦可称作 “远程函数/方法调用”。
简而言之，RPC 就是实现不同服务之间的相互调用的协议，这个不同服务可以是本地服务，也可以是互联网上的远程服务。
A high-performance, open-source universal RPC framework.
gRPC（Google Remote Procedure Call，谷歌远程过程调用）是 Google 发布的基于 HTTP 2.0 协议承载的高性能、开源和通用的 RPC 框架，提供了 C、Java 和 Go 语言版本，分别是：grpc、grpc-java 和 grpc-go。
官方网页：https://grpc.io/gRPC 基于 HTTP/2 协议设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。
gRPC 提供了 protocol buffer 编译插件，能够从一个服务定义的 .proto 文件生成客户端和服务端代码。通常 gRPC 用户可以在服务端实现这些 API，并从客户端调用它们。
在服务侧，服务端实现服务接口，运行一个 gRPC 服务器来处理客户端调用。gRPC 底层架构会解码传入的请求，执行服务方法，编码服务应答。
在客户侧，客户端有一个存根实现了服务端同样的方法。客户端可以在本地存根调用这些方法，用合适的 protocol buffer 消息类型封装这些参数，gRPC 来负责发送请求给服务端并返回服务端 protocol buffer 响应。
gRPC 和 REST 都提供了一套 C/S 通信机制，而且它们都基于 HTTP 作为底层的传输协议。但严格地说，gRPC 使用的是 HTTP/2，REST 则不对协议版本有要求。
gRPC 的优势如下：
gRPC 可以通过 protobuf 来定义接口，从而可以具有更加严格的接口约束条件。gRPC 通过 protobuf 可以将数据序列化为二进制编码，大幅减少了需要传输的数据量，从而大幅提高性能。gRPC 支持流式（Streaming）通信，理论上基于 HTTP/2 就可以使用 Streaming 模式，但是通常使用 REST 的 Web Service 很少这么用。流式数据应用常见与视频流一类，但一般会使用专门的协议如：HLS，RTMP 等。需要对接口进行严格约束的情况，比如我们对外提供了一个公共的服务，这时我们就会希望对传输的数据有更加严格的约束，尤其是考虑到安全性的因素。这时 gRPC 就可以通过 protobuf 来提供严格的接口约束。
对于性能有更高的要求时，也可以考虑使用 gRPC，因为通过 protobuf 我们可以将数据压缩编码转化为二进制格式，通常传递的数据量要小得多，而且通过 HTTP/2 还可以实现异步的请求，从而大大提高了通信效率。
通常的，我们不会单独使用 gRPC，而是将 gRPC 作为一个部件。因为在大并发的生产环境中，我们通常选择使用分布式系统来进行处理，而 gRPC 并没有提供分布式系统相关的一些必要组件。而且，真正的线上服务还需要提供包括负载均衡，限流熔断，监控报警，服务注册和发现等等必要的组件。
Protocol Buffers 是一种更加灵活、高效的数据格式，与 XML、JSON 类似，在一些高性能且对响应速度有要求的数据传输场景非常适用。
Protoco Buffers 在 gRPC 的框架中主要有三个作用：
定义数据结构。定义数据结构。通过序列化和反序列化，提升传输效率。我们使用 XML、JSON 进行数据编译时，数据文本格式会更易于阅读，但进行数据交换时，就需要耗费大量的 CPU 在 I/O 动作上，自然会影响整个传输速率。Protocol Buffers 则会将字符串进行序列化后再进行传输，即二进制数据。
从编码的角度，可以看到其实两者内容相差不大，都非常直观，但 Protocol Buffers 编码的内容是面向操作者阅读的，实际上并不会以这种文本形式进行传输，而是序列化后的二进制数据。字节数会比 JSON、XML 的字节数少很多，速率更快。
Protocol Buffers 自带一个编译器也是其一大优势。前面提到的 .proto 文件就是通过编译器进行编译的，.proto 文件需要编译生成一个类似库文件，基于库文件才能真正开发数据应用。
另外，Protocol Buffers 还具有跨语言的优势。
小结 Protocol Buffers 同比于 XML、JSON 的优势：
简单，体积小，数据描述文件大小只有 1/10 至 1/3；传输和解析的速率快，相比 XML 等，解析速度提升 20 倍甚至更高；可编译性强；跨语言。正如其他 RPC 系统，gRPC 基于如下思想：定义一个服务，指定其可以被远程调用的方法及其参数和返回类型。gRPC 默认使用 protocol buffers 作为接口定义语言，以此来描述服务接口和有效载荷消息结构。当然，如果有需要的话，也可以使用其他替代方案。
service HelloService { rpc SayHello (HelloRequest) returns (HelloResponse); } message HelloRequest { required string greeting = 1; } message HelloResponse { required string reply = 1; }gRPC 支持定义四类服务方法：
单项 RPC，即：客户端发送一个请求给服务端，从服务端获取一个应答，就像一次普通的函数调用。 rpc SayHello(HelloRequest) returns (HelloResponse){} 服务端流式 RPC，即：客户端发送一个请求给服务端，然后服务端可获取一个数据流用来读取一系列消息，客户端从返回的数据流里一直读取直到没有更多消息为止。 rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){} 客户端流式 RPC，即：客户端用提供的一个数据流写入并发送一系列消息给服务端，一旦客户端完成消息写入，就等待服务端读取这些消息并返回应答。 rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {} 双向流式 RPC，即：两边都可以分别通过一个读写数据流来发送一系列消息。这两个数据流操作是相互独立的，所以客户端和服务端能按其希望的任意顺序读写，例如：服务端可以在写应答前等待所有的客户端消息，或者它可以先读一个消息再写一个消息，或者是读写相结合的其他方式。每个数据流里消息的顺序会被保持。 rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){}gRPC 被设计成可以利用插件的形式支持多种安全认证机制。
SSL/TLS：gRPC 集成 SSL/TLS 对客户端和服务端的数据交换进行了加密。对客户端来讲，提供了可选的凭证机制来获得共同的授权。Google OAuth 2.0：值得注意的是，Google OAuth2 凭证应该仅用于连接 Google 的服务，把 Google 对应的 OAuth2 令牌发往非 Google 的服务会导致令牌被窃取用作冒充客户端来访问 Google 的服务。http://doc.oschina.net/grpc?t=60133
