gRPC 一种现代、开源、高性能的远程过程调用 （RPC） 可以在任何地方运行的框架

背景介绍

gRPC 是一种现代开源高性能远程过程调用 （RPC） 可以在任何环境中运行的框架。它可以有效地连接服务 在数据中心内和数据中心之间，具有对负载平衡、跟踪、 运行状况检查和身份验证。它也适用于最后一英里 分布式计算，用于连接设备、移动应用程序和浏览器 后端服务。

主要使用场景

• 在微服务风格架构中高效连接多语言服务
• 将移动设备、浏览器客户端连接到后端服务
• 生成高效的客户端库

  使其出色的核心功能

• 11 种语言的惯用客户端库
• 高效的线路和简单的服务定义框架
• 使用基于 http/2 的传输进行双向流式传输
• 可插拔身份验证、跟踪、负载平衡和运行状况检查

gRPC 可以使用 protocol buffers 作为其接口定义语言 （IDL） 和基础消息 交换格式。

在 gRPC 中，客户端应用程序可以直接调用服务器应用程序上的方法 在不同的计算机上，就好像它是本地对象一样，使您可以更轻松地 创建分布式应用程序和服务。与许多 RPC 系统一样，gRPC 是 基于定义服务的思想，指定可以 使用其参数和返回类型远程调用。在服务器端， 服务器实现此接口并运行 gRPC 服务器来处理客户端调用。 在客户端，客户端有一个存根（在某些中称为客户端 语言），提供与服务器相同的方法。

gRPC 客户端和服务器可以在各种 环境 - 从 Google 内部的服务器到您自己的桌面 - 并且可以 以任何 gRPC 支持的语言编写。因此，例如，您可以轻松地 在 Java 中创建 gRPC 服务器，并使用 Go、Python 或 Ruby 中的客户端。另外 最新的 Google API 将具有其接口的 gRPC 版本，让您 轻松将 Google 功能构建到您的应用程序中。

使用协议缓冲区

核心概念、架构和生命周期

服务定义

与许多 RPC 系统一样，gRPC 基于定义服务的思想， 指定可以使用其参数远程调用的方法，以及 返回类型。默认情况下，gRPC 使用协议 缓冲区作为接口 定义语言 （IDL），用于描述服务接口和 有效负载消息的结构。

gRPC 允许您定义四种服务方法：

• 一元 RPC，其中客户端向服务器发送单个请求并获得 单响应返回，就像正常的函数调用一样。

• 服务器流式处理 RPC，其中客户端向服务器发送请求并获取 用于读回消息序列的流。客户端从 返回流，直到没有更多消息。gRPC 保证消息 在单个 RPC 调用中排序。

• 客户端流式处理 RPC，其中客户端写入一系列消息并发送 它们到服务器，再次使用提供的流。一旦客户有 写完消息，它等待服务器读取它们并返回 它的回应。同样，gRPC 保证单个 RPC 中的消息排序 叫。

• 双向流式处理 RPC，其中双方发送一系列消息 使用读写流。这两个流独立运行，因此客户端 服务器可以按照他们喜欢的任何顺序读取和写入：例如， 服务器可以等待接收所有客户端消息，然后再写入其 响应，或者它可以交替阅读消息然后编写消息，或者 读取和写入的其他一些组合。每个消息的顺序 流被保留。

使用接口

从文件中的服务定义开始，gRPC 提供协议 生成客户端和服务器端代码的缓冲区编译器插件。gRPC 用户 通常在客户端调用这些 API 并实现相应的 API 在服务器端。.proto

在服务器端，服务器实现服务声明的方法 并运行 gRPC 服务器来处理客户端调用。gRPC 基础结构解码 传入请求、执行服务方法并对服务响应进行编码。 在客户端，客户端有一个称为存根的本地对象（对于某些 语言，首选术语是客户端），它实现与 服务。然后，客户端可以在本地对象上调用这些方法， 并且这些方法将调用的参数包装在适当的协议缓冲区中 消息类型，将请求发送到服务器，并返回服务器的 协议缓冲区响应。 同步与异步 在响应从服务器到达之前阻止的同步 RPC 调用是 最接近过程调用 RPC 的抽象 渴望。另一方面，网络本质上是异步的，并且在许多 能够在不阻塞当前的情况下启动 RPC 非常有用的方案 线。

大多数语言的 gRPC 编程 API 都有同步和 异步风格。您可以在每种语言的教程中找到更多信息，并且 参考文档（完整的参考文档即将推出）。

RPC 生命周期

在本部分中，你将详细了解 gRPC 客户端发生的情况 调用 gRPC 服务器方法。有关完整的实现详细信息，请参阅 特定于语言的页面。

一元 RPC

首先考虑客户端发送单个请求的最简单类型的 RPC 并得到一个回复。

一旦客户端调用存根方法，服务器 通知已使用此调用的客户端元数据、方法名称和指定的截止时间调用 RPC，如果 适用。 然后，服务器可以发回自己的初始元数据（必须 在任何响应之前发送）立即，或等待客户的请求 消息。首先发生的是特定于应用程序的。 一旦服务器收到客户端的请求消息，它就会做任何工作 需要创建和填充响应。然后返回响应 （如果成功）与状态详细信息（状态代码和 可选状态消息）和可选的尾随元数据。 如果响应状态为“正常”，则客户端将获得响应，即 在客户端完成调用。 服务器流式处理 RPC 服务器流式处理 RPC 类似于一元 RPC，不同之处在于服务器返回 响应客户端请求的消息流。发送完所有后 消息、服务器的状态详细信息（状态代码和可选状态消息） 并将可选的尾随元数据发送到客户端。这样就完成了处理 在服务器端。客户端在拥有服务器的所有消息后完成。

客户端流式处理 RPC

客户端流式处理 RPC 类似于一元 RPC，不同之处在于客户端发送 发送到服务器的消息流，而不是单个消息。服务器 使用单个消息响应（以及其状态详细信息和可选 尾随元数据），通常但不一定要在它收到所有 客户端的消息。

双向流式处理 RPC

在双向流式处理 RPC 中，调用由客户端发起 调用方法和接收客户端元数据的服务器，方法名称， 和截止日期。服务器可以选择发回其初始元数据或 等待客户端开始流式传输消息。

客户端和服务器端流处理是特定于应用程序的。由于两者 流是独立的，客户端和服务器可以读取和写入消息 任何订单。例如，服务器可以等到它收到所有 客户端的消息在写入其消息之前，或者服务器和客户端可以播放 “乒乓球” – 服务器收到请求，然后发回响应，然后 客户端根据响应发送另一个请求，依此类推。

截止时间/超时 gRPC 允许客户端指定他们愿意等待 RPC 的时间 在 RPC 因错误而终止之前完成。上 服务器端，服务器可以查询查看特定 RPC 是否已超时， 或完成 RPC 还剩多少时间。DEADLINE_EXCEEDED

指定截止时间或超时是特定于语言的：某些语言 API 可以工作 在超时（持续时间）方面，某些语言 API 在超时方面工作 的截止日期（固定时间点），可能有也可能没有默认截止日期。

RPC 终止

在 gRPC 中，客户端和服务器都对 电话的成功，他们的结论可能不匹配。这意味着， 例如，您可能有一个在服务器端成功完成的 RPC （“我已经发送了我所有的回复！但在客户端失败（“响应 在我的截止日期之后到达！服务器也可以决定 在客户端发送其所有请求之前完成。

取消 RPC

客户端或服务器可以随时取消 RPC。取消 立即终止 RPC，以便不再执行任何进一步的工作。

元数据

元数据是有关特定 RPC 调用（如身份验证）的信息 详细信息）以键值对列表的形式，其中 键是字符串，值通常是字符串，但可以是二进制数据。

键不区分大小写，由 ASCII 字母、数字和特殊字符 组成，并且不得以 （为 gRPC 本身保留）开头。 二进制值键以 结尾，而 ASCII 值键不以结尾。-_.grpc--bin

gRPC 不使用用户定义的元数据，这允许客户端提供信息 与对服务器的调用相关联，反之亦然。

对元数据的访问取决于语言。

渠道

gRPC 通道提供与指定主机上的 gRPC 服务器的连接，并且 港口。它在创建客户端存根时使用。客户端可以指定通道 用于修改 gRPC 默认行为（如切换消息）的参数 打开或关闭压缩。通道具有状态，包括和 。connectedidle

gRPC 如何处理关闭通道取决于语言。有些语言也 允许查询通道状态。

谁在使用 gRPC，为什么？

许多公司已经在使用 gRPC 来连接其中的多个服务 环境。用例从连接少数服务到 在本地或云环境中提供数百种不同语言的服务。 以下是我们一些早期采用者的详细信息和引述。

本文由博客一文多发平台 OpenWrite 发布！