GRPC - Go语言中文社区

GRPC


RPC

Remote Procedure Call,远程过程调用。简单来说就是两个进程之间的数据交互。正常服务端的接口服务是提供给用户端(在Web开发中就是浏览器)或者自身调用的,也就是本地过程调用。和本地过程调用相对的就是:假如两个服务端不在一个进程内怎么进行数据交互?使用RPC。尤其是现在微服务的大量实践,服务与服务之间的调用不可避免,RPC更显得尤为重要。


rpc.jpg

上图描述了一个RPC的完整调用流程:

1:client向client stub发起方法调用请求。

2:client stub接收到请求后,将方法名,请求参数等信息进行编码序列化。

3:client stub通过配置的ip和端口使用socket通过网络向远程服务器server发起请求。

4:远程服务器server接收到请求,解码反序列化请求信息。

5:server将请求信息交给server stub,server stub找到对应的本地真实方法实现。

6:本地方法处理调用请求并将返回的数据交给server stub。

7:server stub 将数据编码序列化交给操作系统内核,使用socket将数据返回。

8:client端socket接收到远程服务器的返回信息。

9:client stub将信息进行解码反序列化。

10:client收到远程服务器返回的信息。

注:stub负责接收本地方法调用,并将它们委托给各自的具体实现对象。server端stub又被称为skeleton(骨架)。可以理解为代理类。而实际上基于Java的RPC框架stub基本上也都是使用动态代理。我们所说的client端和server端在RPC中一般也都是相对的概念。

GRPC

gRPC是Google的开源产品,是跨语言的通用型RPC框架,基于HTTP2协议,使用Go语言编写。 Java语言的应用同样使用了Netty做网络通信,Go采用了Goroutine做网络通信。序列化方式采用了Google自己开源的Protobuf。请求的调用和返回使用HTTP2的Stream。

GRPC原理

一个RPC框架必须有两个基础的组成部分:数据的序列化和进程数据通信的交互方式。

****Protobuf:Google Protocol Buffer(简称 Protobuf)是一种轻便高效的结构化数据存储格式,平台无关、语言无关、可扩展,可用于通讯协议和数据存储等领域。

上句有几个关键点:它是一种数据存储格式,跨语言,跨平台,用于通讯协议和数据存储。

这么看和我们熟悉的JSON类似,但其实着重点有些本质的区别。JSON主要是用于数据的传输,因为它轻量级,可读性好,解析简单。Protobuf主要是用于跨语言的IDL,它除了和JSON、XML一样能定义结构体之外,还可以使用自描述格式定于出接口的特性,并可以使用针对不同语言的protocol编译器产生不同语言的stub类。所以天然的适用于跨语言的RPC框架中。

而关于进程间的通讯,无疑是Socket。Java方面gRPC同样使用了成熟的开源框架Netty。使用Netty Channel作为数据通道。传输协议使用了HTTP2。

通过以上的分析,我们可以将一个完整的gRPC流程总结为以下几步:

  • 通过.proto文件定义传输的接口和消息体。
  • 通过protocol编译器生成server端和client端的stub程序。
  • 将请求封装成HTTP2的Stream。
  • 通过Channel作为数据通信通道使用Socket进行数据传输。

HTTP2

HTTP2 通过支持标头字段压缩和在同一连接上 进行多个并发交换,让应用更有效地利用网络资源,减少 感知的延迟时间。具体来说,它可以对同一连接上的请求和响应消息进行交错 发送并为 HTTP 标头字段使用 有效编码。 HTTP/2 还允许为请求设置优先级,让更重要的请求更快速地完成,从而进一步 提升性能。

HTTP2协议更有利于网络,因为与 HTTP/1.x 相比,可以使用更少的 TCP 连接。 这意味着与其他流的竞争减小,并且连接的持续时间变长,这些特性反过来提高 了可用网络容量的利用率。 最后,HTTP2 还可以通过使用二进制消息分帧对消息进行更高效的处理。

二进制分帧层

HTTP/2 所有性能增强的核心在于新的二进制分帧层,它定义了如何封装 HTTP 消息并在客户端与服务器之间传输。

二进制帧.png

这里所谓的“层”,指的是位于套接字接口与应用可见的高级 HTTP API 之间一个经过优化的新编码机制:HTTP 的语义(包括各种动词、方法、标头)都不受影响,不同的是传输期间对它们的编码方式变了。 HTTP/1.x 协议以换行符作为纯文本的分隔符,而 HTTP2 将所有传输的信息分割为更小的消息和帧,并采用二进制格式对它们编码。

这样一来,客户端和服务器为了相互理解,都必须使用新的二进制编码机制:HTTP/1.x 客户端无法理解只支持 HTTP2 的服务器,反之亦然。 不过不要紧,现有的应用不必担心这些变化,因为客户端和服务器会替我们完成必要的分帧工作。

数据流、消息和帧

新的二进制分帧机制改变了客户端与服务器之间交换数据的方式。 为了说明这个过程,我们需要了解 HTTP2 的三个概念:

  • 数据流:已建立的连接内的双向字节流,可以承载一条或多条消息。
  • 消息:与逻辑请求或响应消息对应的完整的一系列帧。
  • :HTTP2 通信的最小单位,每个帧都包含帧头,至少也会标识出当前帧所属的数据流。

这些概念的关系总结如下:

  • 所有通信都在一个 TCP 连接上完成,此连接可以承载任意数量的双向数据流。
  • 每个数据流都有一个唯一的标识符和可选的优先级信息,用于承载双向消息。
  • 每条消息都是一条逻辑 HTTP 消息(例如请求或响应),包含一个或多个帧。
  • 帧是最小的通信单位,承载着特定类型的数据,例如 HTTP 标头、消息负载等等。 来自不同数据流的帧可以交错发送,然后再根据每个帧头的数据流标识符重新组装。
Free-Converter.com-streams_messages_frames01-78815424.png

简言之,HTTP2 将 HTTP 协议通信分解为二进制编码帧的交换,这些帧对应着特定数据流中的消息。所有这些都在一个 TCP 连接内复用。 这是 HTTP2 协议所有其他功能和性能优化的基础。

版权声明:本文来源简书,感谢博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://www.jianshu.com/p/7a26e45b8ae9
站方申明:本站部分内容来自社区用户分享,若涉及侵权,请联系站方删除。
  • 发表于 2020-02-02 14:53:19
  • 阅读 ( 1700 )
  • 分类:

0 条评论

请先 登录 后评论

官方社群

GO教程

猜你喜欢