通过三篇笔记简单介绍下 gRPC，后续进行代码实践。
gRPC 介绍
gRPC 是一个高性能、跨平台、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计。
当前几乎所有主流语言都支持 gRPC，在 gRPC 里客户端应用可以像调用本地方法一样直接调用另一台机器上服务端应用的方法。
要使用 gRPC ：首先使用接口定义语言（interface definition language， IDL）定义一个服务，定义能够被远程调用的方法（包含参数和返回类型）。借助服务定义，可以生成服务端代码，也就是服务端骨架（skeleton）和客户端代码，即客户端存根（stub）。这样客户端就能够调用我们在服务接口中指定的方法。
服务定义
gPRC 使用 protocol buffers 作为 IDL 来定义接口，protocol buffers 是语言中立、平台无关、实现结构化数据序列化的可扩展机制。
服务接口定义在 proto 文件中指定，下面给出一个使用 protocol buffers 定义服务的文件。
// protocol buffers版本为 proto3
syntax = "proto3";
// 用来防止协议消息类型命名冲突的包名，也可用来生成代码
package helloproto;
// 定义gRPC服务接口
service Greeter {
// 远程调用方法，可以添加多个
rpc sayHello(HelloRequest) returns (HelloReply) {}
}
// 定义 HelloRequest 的消息格式
message HelloRequest {
string name = 1;
string description =2;
}
// 定义 HelloReply 的消息格式
message HelloReply {
string value = 1;
}
服务就是一组可以被远程调用的方法，其输入参数和返回参数可以是用户定义类型（例如我们的示例），也可以是 protocol buffers 中的类型，它们被构造成消息。消息中包含一系列的字段，每个字段有唯一的编号。
消息传输
在调用 gRPC 服务时，客户端会将 RPC 请求封装（marshal）为 protocol buffers 格式，然后将其通过 HTTP/2 进行发送。服务端接收到请求后会解析（unmarshal），对应的过程调用同样使用 protocol buffers 执行，然后遵循与请求类似的流程返回响应报文。
gRPC 通信模式
gRPC 主要包含四种通信模式：
简单/一元RPC模式（Simple RPC）。客户端发起请求，然后等待服务端响应。
服务端流RPC模式（Server-side streaming RPC）。客户端发起一次请求，服务端可以连续返回数据流。
客户端流RPC模式（Client-side streaming RPC）。与服务端数据流模式相反，客户端持续向服务端发送数据流，在发送结束后，由服务端返回一个响应。
双向流RPC模式（Bidirectional streaming RPC）、客户端和服务端都可以向对方发送数据流。
gRPC的特点
gRPC优势
gRPC 越来越受欢迎，是因为它有着一些关键的优势。
提供高效的进程间通信。 gRPC 使用的 protocol buffers 是二进制协议，相比传统的 JSON 和 XML这样的文本化格式，效率高很多，另外，gRPC基于 HTTP/2，也使它成为最高效的通信技术之一。
具有简单且定义良好的服务接口和模式。 gROC为应用程序开发提供了一种契约优先的方式。即首先定义服务接口，然后去处理实现细节。因此，相比 RESTful 服务定义中的 OpenAPI/Swagger 和 Web Service 中的WSDL，gRPC提供了简单一直、可靠可扩展的应用程序开发体验。
属于强类型。 gRPC 使用 protocol buffers 清晰定义了应用程序间通信所使用类型，可以减少跨团队合作时的运行时错误和互操作错误，使分布式应用程序的开发更加稳定。
支持多语言。 protocol buffers 是语言中立的，可以支持任意语言与现有的 gRPC 服务器或客户端进行互操作。
支持双工流。 gRPC在客户端和服务端都提供了对流的原生支持，这些功能都被整合到了服务定义本身之中。
内置很多高级特性。 gRPC 内置了很多高级特性，如认证、加密、弹性、元数据交换、压缩、负载均衡、服务发现等。
与云原生生态系统进行了集成。 gRPC 是 CNCF 的一部分，云上很多框架合和技术对 gRPC 提供原生支持，比如 Envoy，就使用 gRPC作为通信协议。
已经发展成熟并被广泛使用。 gRPC已发展成熟，很多大型科技公司都采用了 gRPC，比如Square、Lyft、Netflix等。
gRPC劣势
当然，gRPC也存在着一些劣势：
gRPC可能不太适合面向外部的服务。如果希望给将应用程序或服务通过互联网暴露给外部客户端，gRPC可能不是最合适的协议。gRPC服务具有契约驱动、强类型的特点，这可能会限制我们向外暴露服务的灵活性，同时消费者的控制权会削弱很多。gRPC网关可以解决此问题。
巨大的服务定义变更是复杂的开发流程。如果出现巨大的 gRPC 服务定义变更，通常需要重新生成客户端代码和服务端代码。当然大多数 gRPC 服务定义的变更可以在不破坏服务契约的情况下完成，而且只要不引入破坏性变更，gRPC 就可以与不同版本的 proto 客户端和服务器进行交互。
gRPC生态系统相对较小。 与传统的REST相比，gRPC的生态系统依然相对较小。浏览器和移动端应用程序对 gRPC 的支持依旧处于初级阶段。
