下面介绍gRPC的核心概念，并概述gRPC架构和RPC生命周期。
综述
服务的定义
与许多RPC系统一样，gRPC基于定义服务、指定可以通过其参数和返回类型远程调用的方法的思想。默认情况下，gRPC使用protocol buffers作为接口定义语言(IDL)来描述服务接口和有效负载消息的结构。如果需要，也可以使用其他替代方案。
service HelloService {
rpc SayHello(HelloRequest) returns (HelloResponse);
}
message HelloRequest {
string greeting = 1;
}
message HelloResponse {
string reply = 1;
}
gRPC允许你定义四种服务方法:
- 一元rpc，客户端向服务器发送单个请求并得到单个响应，就像普通的函数调用一样。
rpc SayHello(HelloRequest) returns (HelloResponse);
- 服务器流的rpc，客户端向服务器发送请求并获取一个流来读取返回的消息序列。客户端从返回的流中读取消息，直到没有更多的消息为止。gRPC保证单个RPC调用中的消息顺序。
rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);
- 客户端流rpc，客户端写入一系列消息并将它们发送到服务器，同样使用提供的流。一旦客户机完成了消息的编写，它就等待服务器读取消息并返回响应。同样，gRPC保证了单独RPC调用中的消息顺序。
rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);
- 双向流rpc，其中双方使用读写流发送消息序列。两个流独立运作,因此客户端和服务器可以读和写在他们喜欢的任何顺序:例如,服务器可以等待收到所有客户端消息之前写的反应,也可以交替阅读一条消息然后写一个消息,或其他一些读写的结合。每个流中的消息顺序被保留。
rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);
使用API
从.proto文件中的服务定义开始，gRPC提供了protocol buffers编译器插件，用于生成客户端和服务器端代码。gRPC用户通常在客户端调用这些API，并在服务器端实现相应的API。
- 在服务器端，服务器实现服务声明的方法，并运行gRPC服务器来处理客户端调用。gRPC基础架构对传入请求进行解码，执行服务方法，并对服务响应进行编码。
- 在客户端，客户端有一个称为存根(对于某些语言，首选术语是客户端)的本地对象，它实现了与服务相同的方法。然后客户端可以调用本地对象上的这些方法，将调用的参数包装在适当的protocol buffers消息类型中——gRPC在向服务器发送请求并返回服务器的protocol buffers响应后进行查找。
同步与异步
阻塞直到服务器响应到达的同步RPC调用是最接近RPC所期望的过程调用抽象的方法。另一方面，网络本身是异步的，在许多场景中，能够在不阻塞当前线程的情况下启动rpc是很有用的。
大多数语言中的gRPC编程API都有同步和异步两种风格。你可以在每种语言的教程和参考文档中找到更多信息(完整的参考文档即将发布)。
RPC的生命周期
在本节中，您将进一步了解gRPC客户端调用gRPC服务器方法时会发生什么。要了解完整的实现细节，请参见特定于语言的页面。
一元RPC
首先考虑最简单的RPC类型，其中客户端发送单个请求并返回单个响应。
1、一旦客户机调用了存根方法，服务器就会收到通知，RPC已经调用客户端请求的元数据、方法名称和指定的截止日期(如果兼容的话)。
2、然后，服务器可以直接发送自己的初始元数据(必须在任何响应之前发送)，或者等待客户机的请求消息。首先发生的是特定于应用程序的。
3、一旦服务器获得了客户端的请求消息，它将执行创建和填充响应所需的任何工作。然后将响应(如果成功的话)返回给客户端，同时返回的还有状态详细信息(状态码和可选的状态消息)和可选的尾部元数据。
4、如果响应状态为OK，则客户端获得响应，响应将在客户端完成调用。
服务器流RPC
服务器流RPC与一元RPC相似，不同之处是服务器返回一个消息流来响应客户端的请求。在发送所有消息之后，服务器的状态详细信息(状态代码和可选的状态消息)和可选的跟踪元数据被发送到客户端。这就完成了服务器端的处理。一旦客户端拥有了所有的服务器消息，它就完成了。
客户端流RPC
客户端流RPC与一元RPC类似，不同之处是客户机向服务器发送消息流，而不是单个消息。服务器用一条消息(连同它的状态详细信息和可选的尾部元数据)响应，通常在它收到所有客户机消息之后，但不一定是这样。
双向流RPC
在双向流RPC中，调用由调用方法的客户端和接收客户端元数据、方法名称和截止日期的服务器发起。服务器可以选择发送回其初始元数据或等待客户端开始流式消息。
客户端和服务器端流处理是特定于应用程序的。由于这两个流是独立的，客户端和服务器可以以任何顺序读写消息。例如,一个服务器可以等到它已经收到了客户的所有信息之前写它的消息,或者是服务器和客户端可以玩“乒乓球”——服务器收到一个请求,然后发回一个响应,然后客户端根据响应发送另一个请求,等等。
截止时间/超时
gRPC允许客户端指定他们愿意等待RPC完成的时间，在RPC被一个DEADLINE_EXCEEDED错误终止之前。在服务器端，服务器可以查询特定RPC是否超时，或者还有多少时间来完成RPC。
指定期限或超时是特定于语言的:一些语言api根据超时情况(持续时间)工作，而一些语言api根据截止时间(一个固定的时间点)工作，可能有也可能没有默认的截止时间。
终止RPC
在gRPC中，客户端和服务器都对调用的成功做出独立和本地的判断，他们的结论可能不匹配。这意味着，例如，您可以有一个在服务器端成功完成的RPC(“我已经发送了所有的响应!”)，但在客户端失败(“响应在我的截止日期之后到达!”)。服务器也可以在客户端发送所有请求之前决定是否完成。
取消一个RPC
客户端或服务器都可以在任何时候取消RPC。取消操作会立即终止RPC，这样就不会再做其他的工作了。
元数据（ Metadata ）
元数据是键-值对列表形式的关于特定RPC调用的信息(比如身份验证细节)，其中键是字符串，值通常是字符串，但也可以是二进制数据。元数据对gRPC本身是不透明的——它让客户端提供与服务器调用相关的信息，反之亦然。
对元数据的访问依赖于语言。
通道（Channel）
gRPC通道在指定的主机和端口上提供与gRPC服务器的连接。它在创建客户端存根时使用。客户端可以指定通道参数来修改gRPC的默认行为，比如打开或关闭消息压缩。通道有状态，包括连接和空闲。
gRPC如何处理关闭通道是与语言相关的。有些语言还允许查询通道状态。
