Protobuf 二进制解码与 Buf Reflection API 技术解析

Protobuf 二进制格式因其紧凑高效的特性和灵活的功能而备受青睐。它支持多种模式更改，能够实现向后和向前兼容。然而，如果缺乏数据的模式信息，理解 Protobuf 数据将变得非常困难。其字段由整数标识，而非语义化的名称，同时采用简单的有线格式，这为不同值类型复用了多种编码策略。因此，在没有模式的情况下，甚至无法正确解读编码值，例如无法区分一个值是文本字符串、二进制 blob 还是嵌套消息结构。

运行时解码的必要性

在某些系统和用例中，运行时解码数据对于不具备模式先验知识的进程或用户代理来说是必要的。以下是一些典型场景：

1. RPC 调试

   对于开发者来说，使用工具（如 tcpdump、Wireshark 或 Charles Proxy）对 RPC 请求和响应进行检查、修改是非常有价值的。然而，如果没有模式信息，这些有效载荷只是难以理解的字节序列。

2. 持久存储调试

   这一场景与 RPC 调试类似，但针对的是数据库或消息队列中的数据 blob。开发者需要对这些数据进行可视化分析。

3. 数据管道模式和转换

   这一场景更多用于数据验证和转换，而非人机交互。生产者将编码的 Protobuf 二进制 blob 推送到队列或发布/订阅系统中，系统需要验证这些 blob 是否符合预期类型。此外，消费者可能需要将二进制数据转换为其他格式，而这只能通过模式来实现。为了避免数据丢失，必须使用与发布者版本兼容的模式，否则新增字段可能会在转换过程中被忽略。

以上所有情况都需要一种机制，能够轻松下载特定消息类型的模式版本，以便正确解读二进制数据。

Buf Reflection API 的作用

在 Protobuf 中，描述符是实现反射的核心。文件描述符包含 .proto 源文件中定义的所有消息、枚举和服务的结构化表示。描述符不仅是 Protobuf 插件生态系统进行代码生成的基础，也是动态用例中处理 Protobuf 消息数据的关键。

通过结合支持描述符和动态消息的 Protobuf 运行时，可以实现许多强大的功能，例如动态消息处理器、动态 RPC 客户端以及 RPC 网关或网桥。

FileDescriptorSetService 接口是由 BSR 实现的，但理论上也可以由其他软件实现，例如其他模式注册表或缓存代理。

原型转换的应用

以下是一个示例，展示如何使用消息处理器将二进制 Protobuf 消息转换为 JSON 格式，以支持更广泛的下游消费者：

// 示例代码展示了如何实现二进制到 JSON 的转换

通过这种“转换器”，可以轻松处理来自消息队列或发布/订阅系统的消息。此外，用户还可以提供自定义过滤器，在生成输出之前对消息内容进行操作。例如，可以通过过滤器从消息中移除敏感数据，具体实现可参考相关文档。

展望未来

BSR 的新反射 API 和 Prototransform 库为优化 Protobuf 消息在大型数据系统中的应用提供了重要支持。这些工具不仅简化了调试二进制编码文件或 RPC 消息的流程，还为其他工作流的改进奠定了基础。

未来，我们可以基于这些 API 构建更多创新的功能，同时也期待社区能够利用这些工具开发出更多令人惊叹的应用。

原文链接: https://buf.build/blog/buf-reflection-api