反射

解释如何使用反射来提高 RPC 的透明度和可解释性。

反射

解释如何使用反射来提高 RPC 的透明度和可解释性。

概述

反射是 一种协议,gRPC 服务器可以使用它来声明它们通过标准 RPC 服务导出的 protobuf 定义的 API,包括请求和响应消息引用的所有类型。然后,客户端可以使用此信息以人类可读的方式编码请求和解码响应。

反射被调试工具大量使用,例如 grpcurlPostman。来自 REST 领域的人可能会将 gRPC 反射 API 与在 HTTP 服务器上提供 OpenAPI 文档来描述 REST API 进行比较。

透明度和可解释性

gRPC 卓越性能的一个重要贡献因素是使用 Protobuf 进行序列化——一种二进制非人类可读协议。虽然这大大加快了 RPC 的速度,但也可能使其更难以手动与服务器交互。假设,为了使用 curl 通过 HTTP/2 手动向服务器发送 gRPC 请求,您必须

  1. 知道服务器公开了哪些 RPC 服务。
  2. 知道请求消息的 protobuf 定义及其引用的所有类型。
  3. 知道响应消息的所有类型引用的 protobuf 定义。

然后,您必须使用这些知识将您的请求消息手工制作成二进制格式,并费力地解码响应消息。这将是耗时、令人沮丧且容易出错的。相反,反射协议使工具能够自动化整个过程,使其不可见。

在 gRPC 服务器上启用反射

反射不会在 gRPC 服务器上自动启用。服务器作者必须调用一些额外的函数来添加反射服务。这些 API 调用在不同的语言之间略有不同,并且在某些语言中,需要添加对单独包的依赖,名称类似于 grpc-reflection

请关注以下链接,了解有关您特定语言的详细信息

语言指南
JavaJava 示例
GoGo 示例
C++C++ 示例
PythonPython 示例
JavascriptJavascript 示例

提示

反射与 grpcurl 等工具无缝协作,因此人们通常甚至没有意识到它在后台发生。但是,如果反射没有公开,事情就不会顺利进行。相反,客户端将会失败并出现令人讨厌的错误。人们在编写 gRPC 服务的路由配置时经常会遇到这种情况。反射服务必须路由到适当的后端以及应用程序的主要 RPC 服务。

如果您的 gRPC API 可供公共用户访问,您可能想公开反射服务,因为您可能会认为这是一个安全问题。最终,您需要在此处做出决定,以在安全性和您和您的用户的易用性之间取得最佳平衡。

上次修改时间:2024 年 6 月 6 日:添加指向 javascript 反射示例的链接 (#1292) (de015fd)