聊聊gRPC的特性和背后设计的原则（一）

开一个gRPC学习的专题，感兴趣的一起参与，一周一篇，下一篇聊聊protocol buffer

什么是gRPC？

1. RPC全称(Remote Procedure Call)，远程过程调用，指的是一台计算机通过网络请求另一台计算机的上服务，从而不需要了解底层网络细节，RPC是构建在已经存在的协议（TCP/IP，HTTP等）之上的，RPC采用的是客户端，服务器模式。
2. gRPC是云原生计算基金会（CNCF）项目, gRPC 一开始由 google 开发，是一款语言中立、平台中立的服务间通信框架，使用gRPC可以使得客户端像调用本地方法一样，调用远程主机提供的服务。可以在任何地方运行，它使客户端和服务器应用程序能够透明地进行通信，并使构建连接系统变得更加容易。
3. gRPC目前最新版本是v1.22.0

gRPC的一些特性

1. gRPC基于服务的思想：定义一个服务，描述这个服务的方法以及入参出参，服务器端有这个服务的具体实现，客户端保有一个存根，提供与服务端相同的服务
2. gRPC默认采用protocol buffer作为IDL(Interface Description Lanage)接口描述语言,服务之间通信的数据序列化和反序列化也是基于protocol buffer的，因为protocol buffer的特殊性，所以gRPC框架是跨语言的通信框架（与编程语言无关性），也就是说用Java开发的基于gRPC的服务，可以用GoLang编程语言调用
3. gRPC同时支持同步调用和异步调用，同步RPC调用时会一直阻塞直到服务端处理完成返回结果， 异步RPC是客户端调用服务端时不等待服务段处理完成返回，而是服务端处理完成后主动回调客户端告诉客户端处理完成
4. gRPC是基于http2协议实现的，http2协议提供了很多新的特性，并且在性能上也比http1提搞了许多，所以gRPC的性能是非常好的
5. gRPC并没有直接实现负载均衡和服务发现的功能，但是已经提供了自己的设计思路。已经为命名解析和负载均衡提供了接口
6. 基于http2协议的特性：gRPC允许定义如下四类服务方法
   1. 单项RPC：客户端发送一次请求，等待服务端响应结构，会话结束，就像一次普通的函数调用这样简单
   2. 服务端流式RPC：客户端发起一起请求，服务端会返回一个流，客户端会从流中读取一系列消息，直到没有结果为止
   3. 客户端流式RPC：客户端提供一个数据流并写入消息发给服务端，一旦客户端发送完毕，就等待服务器读取这些消息并返回应答
   4. 双向流式RPC：客户端和服务端都一个数据流，都可以通过各自的流进行读写数据，这两个流是相互独立的，客户端和服务端都可以按其希望的任意顺序独写

gRPC支持的编程语言

• C ++，Java（包括对Android的支持），Objective-C（对于iOS），Python，Ruby，Go，C＃，Node.js都在GA中，并遵循语义版本控制。

gRPC的使用场景

1. 低延迟，高度可扩展的分布式系统
2. 开发与云服务器通信的客户端
3. 设计一个准确，高效，且与语言无关的新协议时
4. 分层设计，以实现扩展，例如。身份验证，负载平衡，日志记录和监控等

谁在使用gRPC

• 谷歌长期以来一直在gRPC中使用很多基础技术和概念。目前正在谷歌的几个云产品和谷歌面向外部的API中使用。Square，Netflix，CoreOS，Docker，CockroachDB，Cisco，Juniper Networks以及许多其他组织和个人也在使用它。

gRPC设计之初的动机和原则

1. 自由，开放：让所有人，所有平台都能使用，其实就是开源，跨平台，跨语言
2. 协议可插拔：不同的服务可能需要使用不同的消息通信类型和编码机制，例如，JSON、XML和 Thirft,所以协议应允许可插拔机制，还有负载均衡，服务发现，日志，监控等都支持可插拔机制
3. 阻塞和非阻塞：支持客户端和服务器交换的消息序列的异步和同步处理。这对于在某些平台上扩展和处理至关重要
4. 取消和超时：一次RPC操作可能是持久并且昂贵的，应该允许客户端设置取消RPC通信和对这次通信加上一个超时时间
5. 拒绝：必须允许服务器通过在继续处理请求的同时拒绝新请求的到来并优雅地关闭。
6. 流处理：存储系统依靠流和流控制来表达大型数据集，其他服务，如语音到文本或股票行情，依赖于流来表示与时间相关的消息序列
7. 流控制：计算能力和网络容量在客户端和服务器之间通常是不平衡的。流控制允许更好的缓冲区管理，以及过度活跃的对等体提供对DOS的保护。
8. 元数据交换 - 认证或跟踪等常见的跨领域问题依赖于不属于服务声明接口的数据交换。依赖于他们将这些特性演进到服务，暴露API来提供能力。
9. 标准化状态码 - 客户端通常以有限的方式响应API调用返回的错误。应约束状态码名称空间，以使这些错误处理决策更加清晰。如果需要更丰富的特定领域的状态，则可以使用元数据交换机制来提供该状态。
10. 互通性：报文协议(Wire Protocol)必须遵循普通互联网基础框架

信息来源 https://grpc.io/faq/