ToB企服应用市场:ToB评测及商务社交产业平台

标题: gRPC编译与字段编号的细节探讨 [打印本页]
作者: 灌篮少年    时间: 2025-1-2 09:47
标题: gRPC编译与字段编号的细节探讨
上次我们专门通过一个简朴的HelloWorld示例来了解了gRPC的基本概念和使用方法。本日，我们将继承深入探讨gRPC，重点讨论一些在实际应用中须要特别注意的要点。实际上，gRPC的核心目标是简化远程调用的过程，它通过定义清晰的接口，利用Protocol Buffers（简称proto协议）来天生不同编程语言的接口代码，从而实现跨语言、高效的通讯。
在回首了gRPC的基本工作原理之后，我们本日将进一步扩展视野，继承探讨一些更细节的部分。
gRPC

是否会覆盖

本日，我特别添加了一个新的测试接口，目的是测试在举行重新编译时，系统是否会丢失之前定义的接口和相干业务逻辑。为了简化说明，实体类部分就不再重新编写了，它与之前定义的内容完全同等。详细细节请见下图：

在我重新举行编译后，我发现除了这个特定的类须要单独手动编写之外，其他的内容都已经主动天生完毕。这意味着，我们不须要担心会因编译过程而导致已有内容被直接覆盖掉。
实际上，Maven 工具本身也可以设置，以控制在执行时是否删除目录中的某些内容并重新天生。虽然这里不作详细讨论，但从正常业务操纵的角度来看，我们通常都不盼望本身辛苦编写的代码在没有任何警告的情况下，因他人的误操纵或一键执行而被完全删除。

字段编号有何用

在我们讨论实体类消息体中为何会出现数字时，首先要明白的是，虽然我们在定义字段时已经给它们起了详细的名字，但这远不敷。特别是在使用 gRPC 举行服务通讯时，你须要从传统的 JSON 格式（键值对结构）中跳脱出来，重新理解字段的表示方式。
在 gRPC 中，数据是通过 Protocol Buffers（Protobuf） 举行序列化和传输的，而 Protobuf 的一个关键概念就是 字段编号（Field Numbers）。如图所示：

其实作用最主要的就是序列化和反序列化，当 Protobuf 序列化消息时，它并不直接存储字段名（如 name、age 等），而是存储字段编号和字段值的对应关系。如许，这使得数据传输时比使用 JSON 或 XML 更加紧凑。
我们简朴看下后台输出的日志，你大概就能理解了，如图所示：

我们把这些字节全拿出来看下。好比：
因此，57 6f 72 6c 64 对应的字符串是 "World"。
同理，我们看下返回的数据也是一样的字节。然后反序列化成我们所须要的字段值，详细的我们就不探讨了。了解下他的优点即可。
这串字节 00000000150a137869616f79753a2048656c6c6f20576f726c64 可以被解释为：
还有一个须要注意的就是，既然他有字段编号，所以你不要轻易去修改编号，就算不消了，也要去用新的编号举行标识处理。这是因为如果有老客户端仍在继承使用，会导致无法精确解析新版消息，会出现兼容性错误。
总结

通过本日的探讨，我们进一步加深了对gRPC和Protocol Buffers的理解，特别是在实际应用中可能碰到的一些细节和注意事项。我们了解了在重新编译时，系统如何主动天生接口代码并避免覆盖已有内容，从而减少了手动操纵的风险。同时，深入探讨了Protocol Buffers中的字段编号机制，它不仅有助于数据的高效序列化和传输，也在版本兼容性上起到了至关重要的作用。尽管字段名称对开发者来说更具可读性，但最终传输的数据依赖于字段编号，而对编号的管理和修改必须小心谨慎，以确保不同版本之间的兼容性。
盼望通过本日的讲解，大家能更好地理解gRPC的应用场景和实际操纵中的细节。
我是努力的小雨，一名 Java 服务端码农，潜心研究着 AI 技术的奥秘。我热爱技术交换与分享，对开源社区布满热情。同时也是一位腾讯云创作之星、阿里云专家博主、华为云云享专家、掘金优秀作者。


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4