反射
解释了如何使用反射来提高 RPC 的透明度和可解释性。
反射
概述
反射是一种 协议，gRPC 服务器可以使用它通过标准化的 RPC 服务来声明其导出的 Protobuf 定义的 API，包括请求和响应消息引用的所有类型。客户端随后可以使用此信息以人类可读的方式编码请求和解码响应。
反射被调试工具广泛使用，例如 grpcurl 和 Postman。来自 REST 领域的人可能会将 gRPC 反射 API 比作在提供 REST API 的 HTTP 服务器上提供 OpenAPI 文档。
透明度和可解释性
gRPC 卓越性能的一个重要因素是使用 Protobuf 进行序列化——这是一种二进制的、非人类可读的协议。虽然这大大加快了 RPC，但它也可能使手动与服务器交互变得更加困难。假设要使用 curl 通过 HTTP/2 手动向服务器发送 gRPC 请求，您必须：
- 知道服务器公开了哪些 RPC 服务。
- 知道请求消息及其引用的所有类型的 Protobuf 定义。
- 知道响应消息及其引用的所有类型的 Protobuf 定义。
然后，您必须利用这些知识手工将您的请求消息编码为二进制格式，并费力地解码响应消息。这将耗时、令人沮丧且容易出错。相反，反射协议使工具能够自动化整个过程，使其不可见。
在 gRPC 服务器上启用反射
gRPC 服务器上不会自动启用反射。服务器作者必须调用一些额外的函数来添加反射服务。这些 API 调用在不同语言中略有不同，并且在某些语言中，需要添加对独立包（例如 grpc-reflection）的依赖。
有关特定语言的详细信息，请点击下方链接：
| 语言 | 示例 |
|---|---|
| Java | Java 示例 |
| Go | Go 示例 |
| C++ | C++ 示例 |
| Python | Python 示例 |
| Javascript | Javascript 示例 |
提示
反射与 grpcurl 等工具无缝协作，以至于人们常常甚至没有意识到它在幕后发生作用。但是，如果未公开反射，事情将完全无法无缝进行。相反，客户端将因棘手的错误而失败。人们在编写 gRPC 服务的路由配置时经常会遇到这种情况。除了应用程序的主 RPC 服务之外，反射服务也必须路由到适当的后端。
如果您的 gRPC API 可供公共用户访问，您可能不想公开反射服务，因为您可能认为这是一个安全问题。最终，您需要在此处权衡安全性和易用性，为您和您的用户找到最佳平衡点。