gRPC(一)-扫盲篇

RPC&gRPC

RPC

 刚工作两年的时候，首次被人问到公司使用的rpc是什么。
 我很羞愧不知道，下去查了查，原来rpc是（Remote Procedure Call ），远程过程调用的意思。也有人喜欢叫他Remote Procedure Call Protocol，突出了其协议的本质。
 可能很多公司的同仁和我一样也没有rpc的明确使用意识，但是想必大家一定会有如下的使用场景：

	A业务模块可能经常会向B数据平台模块请求一些数据，这时候B会向A模块提供一个网络服务；
	A需要连接到B的对应IP及端口，并发送特定格式的请求报文。
	B模块收到该消息后整理数据，之后将该模块请求对应的内容发送回去。这些服务通常基于以下方式：
	tcp
	telnet
	http1.1等
	或者更通俗讲，MySQL，redis的接口大家一定调用过，某种意义上也是rpc！

今天我们说的rpc其实就是对于这些使用场景做了标准化，标准化以后有以下红利：
 1：在语言层面之上进行抽象，无论是c/c++,，c#，go还是java，python，ruby编写的功能模块，统统可以使用同一个rpc服务进行过程调用，也就是服务的请求。同时服务模块也只需要向rpc提供统一的服务接口即可。
 2：因为大家都基于同一个rpc框架，所以可以集中力量办大事，可以把功夫更多的放在特性支持（如身份验证，负载均衡，日志）和性能优化上；

总的来说，rpc可以让我们像调用本地对象一样发起远程调用。其凭借强大的治理功能，成为解决分布式系统通信问题的一大利器。

gRPC

 那么本帖的主角，gRPC其实已经呼之欲出了，目前流行以下几种rpc框架：

1. gRPC：gRPC 是由 Google 开发的高性能、通用的开源 RPC 框架。它使用 Protocol Buffers 作为接口定义语言，底层基于HTTP/2 实现，并支持多种编程语言。gRPC 提供了强大的代码生成能力和各种特性，如双向流、认证和负载均衡等。

2. Apache Thrift：Apache Thrift 是一款跨语言的高效 RPC 框架，支持多种传输协议和序列化格式。它可以根据接口定义文件自动生成不同语言的客户端和服务器端代码，并提供了丰富的选项和特性，如数据类型映射、异步调用、连接池等。

3. Dubbo：Dubbo 是阿里巴巴开源的一款高性能 Java RPC 框架，支持分布式服务治理和面向企业级应用场景。Dubbo 提供了灵活可配的配置管理、服务注册与发现、负载均衡和容错处理等功能，并且具备良好的扩展性。

4. brpc： brpc是百度公司开源的基于C++的高性能RPC（远程过程调用）框架。它采用异步I/O模型，在网络通信上具有较低的延迟和较高的吞吐量，同时支持双向流传输和负载均衡等特性。brpc适用于构建分布式系统中的服务调用和数据传输，被广泛应用于百度内部以及其他互联网公司中。

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

gRPC的意义

gRPC是一个现代的、高性能、开源的和语言无关的通用 RPC 框架，基于 HTTP2 协议设计，序列化使用PB(Protocol Buffer)，PB 是一种语言无关的高性能序列化框架，基于 HTTP2+PB 保证了的grpc的高性能，安全性以及高兼容性。

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并没有直接实现负载均衡和服务发现的功能，但是已经提供了自己的设计思路。已经为命名解析和负载均衡提供了接口

基于http2协议的特性：gRPC允许定义如下四类服务方法

1. 一元RPC：客户端发送一次请求，等待服务端响应结构，会话结束，就像一次普通的函数调用这样简单
2. 服务端流式RPC：客户端发起一起请求，服务端会返回一个流，客户端会从流中读取一系列消息，直到没有结果为止
3. 客户端流式RPC：客户端提供一个数据流并写入消息发给服务端，一旦客户端发送完毕，就等待服务器读取这些消息并返回应答
4. 双向流式RPC：客户端和服务端都一个数据流，都可以通过各自的流进行读写数据，这两个流是相互独立的，客户端和服务端都可以按其希望的任意顺序独写

grpc的动机和原则

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

gRPC的基本通信框架

层次	说明
TCP层	底层通信协议，基于TCP连接。
TLS层	该层是可选的，基于TLS加密通道。
HTTP2层	gRPC承载在HTTP2协议上，利用了HTTP2的双向流、流控、头部压缩、单连接上的多路复用请求等特性。
gRPC层	远程过程调用，定义了远程过程调用的协议交互格式。
编码层	gRPC通过编码格式承载数据，包括GPB（Google Protocol Buffer）编码格式。
数据模型层	业务模块的数据。通信双方需要了解彼此的数据模型，才能正确调用信息。当前设备提供了订阅、配置、查询业务模块。

小结

 本章节主要是为了对于grpc有一个初步的理解，介于题主当前还未完成开发环境的部署，需要一定时间继续学习与深入。后续会带来进阶内容，敬请期待。

最后给大家推荐个高质量超值小课，适合想快速深入掌握某领域技术栈以及需要项目经验的朋友：宝藏入口