反射
解释如何使用反射来提高 RPC 的透明度和可解释性。
反射
概述
反射是 一种协议,gRPC 服务器可以使用它来声明它们通过标准 RPC 服务导出的 protobuf 定义的 API,包括请求和响应消息引用的所有类型。然后,客户端可以使用此信息以人类可读的方式编码请求和解码响应。
反射被调试工具大量使用,例如 grpcurl
和 Postman。来自 REST 领域的人可能会将 gRPC 反射 API 与在 HTTP 服务器上提供 OpenAPI 文档来描述 REST API 进行比较。
透明度和可解释性
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 可供公共用户访问,您可能不想公开反射服务,因为您可能会认为这是一个安全问题。最终,您需要在此处做出决定,以在安全性和您和您的用户的易用性之间取得最佳平衡。