gRPC介绍

原创

已于 2024-09-20 17:29:22 修改 · 2.2k 阅读

17 ·

CC 4.0 BY-SA版权

文章标签：

#网络协议 #websocket #http

于 2024-09-19 17:30:33 首次发布

gRPC 是一个由谷歌开发的现代开源高性能 RPC 远程过程调用（ Remote Procedure Calls）框架，具备良好的兼容性，可在多个开发环境下运行。

相较于目前主流的 HTTP API 接口，gRPC 接口采用了领先的 HTTP/2 底层架构设计作为底层传输协议，能够在大规模数据传输场景（例如视频流传输）和大量服务相互调用的微服务架构场景下大展身手。

数据交换采用轻量化的 Protobuf 序列化协议，使得它能够在资源受限场景（常见于手机等移动端设备）提供更快的数据处理速度的同时，减少网络传输的数据量并节省网络带宽，从而降低功耗并提升电池寿命。

在正式开始介绍 gRPC 之前，我们不妨先弄清楚到底什么是 RPC 以及它的作用，这对于后续的理解十分有帮助。

RPC简介

RPC 协议是一种远程过程调用的实现方式。假设现在有两台服务器 A 和 B。部署在 A 服务器上的服务，想调用正在 B 服务器上运行的另一个进程。但由于双方服务并不在一个内存空间而导致无法直接调用，那么就必须通过网络通讯来达到调用效果。

在这里插入图片描述

要建立网络通讯的无非是在传输层发起 TCP 连接。TCP 的握手机制确保了数据包能可靠地传输给对方，并且它具备以下三个特点：面向连接、可靠、基于字节流。前面两种特性都可以胜任这个场景，但唯独在基于字节流这一点恐怕值得商榷。为什么？

因为它没有边界。字节流本质上是在传输层双向通道中流淌的数据，也就是计算机能够理解的二进制 0 1 数据。所以当发送端使用 TCP 发送“南京市”+“长江大桥”字符时，接收端有可能收到的就是“南京市长”+“江大桥”，也有可能是“南京市长江大桥”等。

过于简单的 TCP 连接过程无法保证信息的唯一性和确定性，因此才需要在数据中定义消息头、消息体，并且发送方与接收方共同认可这套沟通方式，由此衍生出了 HTTP 协议和 RPC 调用等方案，它们本质上都是对数据的传递和调用方式作出了规范化定义，避免出现信息失真。

例如现在有一个购物网站，存在订单服务与用户服务（例如账号管理）两项微服务。订单服务需要使用函数查询到用户服务下的一些数据，但是两者相隔离。此时订单服务就必须通过远程调用方式获取数据。

下图的示例中，服务端（用户服务）仅需暴露出一个能够调用数据库的 getConsumerByld() 函数，客户端（订单服务）使用 RPC 便能够像在本地中直接调用 getConsumerByld() 函数并获取到所需的响应结果。RPC 成功隐藏了内部通信的复杂性，为双方提供了稳定统一的接口，使得开发者只需要关注业务逻辑，而无需关注底层网络通信细节。

在这里插入图片描述