反射

概述

反射是一个协议，gRPC 服务器可以使用它来声明通过标准化 RPC 服务公开的 Protobuf 定义的 API，包括请求和响应消息引用的所有类型。客户端随后可以使用这些信息以人类可读的方式编码请求和解码响应。

反射被调试工具广泛使用，例如 grpcurl 和 Postman。来自 REST 世界的人可能会将 gRPC 反射 API 比作在 HTTP 服务器上提供描述 REST API 的 OpenAPI 文档。

透明度和可解释性

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

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

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

在 gRPC 服务器上启用反射

反射不会在 gRPC 服务器上自动启用。服务器作者必须调用一些额外的函数来添加反射服务。这些 API 调用因语言而异，在某些语言中，还需要添加对单独包（例如名为 grpc-reflection）的依赖。

请点击以下链接获取特定语言的详细信息

提示

反射与诸如 grpcurl 之类的工具无缝协作，以至于人们常常没有意识到它在后台运行。然而，如果反射没有暴露，事情将完全无法无缝工作。相反，客户端会遇到严重的错误。人们在为 gRPC 服务编写路由配置时经常遇到这个问题。该反射服务必须路由到适当的后端，就像应用程序的主要 RPC 服务一样。

如果您的 gRPC API 可供公共用户访问，您可能不希望暴露反射服务，因为您可能认为这存在安全问题。最终，您需要在此处做出权衡，为您和您的用户在安全性与易用性之间取得最佳平衡。