都市在线 | 漳州发展网
ad1
您所在的位置: 都市在线 > 新闻

聊聊为什么IDL只能扩展字段而非修改

来源:TechWeb    发布时间:2021-12-09 13:51   作者:子墨   阅读量:7707   

很多人喜欢问:proto buf 与 json 比起来有哪些优势。比较经典的面试题

聊聊为什么IDL只能扩展字段而非修改

IDL 文件管理每个公司不一样,有的保存在单独 gitlab 库,有的是 mono repo 大仓库。当业务变更时,IDL 文件经常需要修改,很多新手总是容易踩坑,本文聊聊 grpc proto 变更时的兼容问题,核心只有一条:对扩展开放,对修改关闭,永远只增加字段而不修改

测试修改兼容性

本文测试使用 grpc—go example 官方用例,感兴趣自查

每次修改后使用 protoc 重新生成代码

protoc——go_out=.——go_opt=paths=source_relative——go—grpc_out=.——go—grpc_opt=paths=source_relativehelloworld/helloworld.proto

Server 每次接受请求后,返回 HelloReply 结构体

//SayHelloimplementshelloworld.GreeterServerfuncSayHellolog.Printf)returnamp,pb.HelloReplyMessage:"Helloaddidional"+in.GetName(),Additional:"thisisaddidionalfield",Age:10,Id:12345,,nil

Client 每次只打印 Server 返回的结果

修改字段编号

将 HelloReply 结构体字段 age 编号变成 12, 然后 server 使用新生成的 IDL 库,client 使用旧版本

zerun.dong$./greeter_client......2021/12/0822:23:38Greeting:"message":"Helloaddidionalworld","additional":"thisisaddidionalfield","id":12345

可以看到 client 没有读到 age 字段,因为 IDL 是根据序号传输的,client 读不到 seq 3, 所以修改序号不兼容

修改字段 name

修改 HelloReploy 字段 id, 变成 score 类型和序号不变

//TheresponsemessagecontainingthegreetingsmessageHelloReplystringmessage=1,stringadditional=2,int32age=3,int64score=4,

重新编译 server, 并用旧版本 client 访问

zerun.dong$./greeter_client......2021/12/0822:29:18Greeting:"message":"Helloaddidionalworld","additional":"thisisaddidionalfield","age":10,"id":12345

可以看到,虽然修改了字段名,但是 client 仍然读到了正确的值 12345, 如果字段含义不变,那么只修改名称是兼容的

修改类型

有些类型是兼容的,有些不可以,而且还要考虑不同的语言。这里测试三种

1.字符串与字节数组

//TheresponsemessagecontainingthegreetingsmessageHelloReplystringmessage=1,bytesadditional=2,int32age=3,int64id=4,

我们将 additional 字段由 string 类型修改为 bytes

//TheresponsemessagecontainingthegreetingstypeHelloReplystructMessagestring`protobuf:"bytes,1,opt,name=message,proto3"json:"message,omitempty"`Additionalbyte`protobuf:"bytes,2,opt,name=additional,proto3"json:"additional,omitempty"`Ageint32`protobuf:"varint,3,opt,name=age,proto3"json:"age,omitempty"`Idint64`protobuf:"varint,4,opt,name=id,proto3"json:"id,omitempty"`

可以看到 go 结构体由 string 变成了 byte, 我们知道这两个其实可以互换

zerun.dong$./greeter_client......2021/12/0822:35:43Greeting:"message":"Helloaddidionalworld","additional":"thisisaddidionalfield","age":10,"id":12345

最后结果也证明 client 可以正确的处理数据,即修改成兼容类型没有任何问题

2.int32 int64 互转

messageHelloReplystringmessage=1,stringadditional=2,int64age=3,int64id=4,

这里我们将 age 由 int32 修改成 int64 字段,位数不一样,如果同样小于 int32 最大值没有问题,此时我们在 server 端将 age 赋于 2147483647 + 1 刚好超过最大值

zerun.dong$./greeter_client......2021/12/0822:43:32Greeting:"message":"Helloaddidionalworld","additional":"thisisaddidionalfield","age":—2147483648,"id":12345

我们可以看到 age 变成了负数,如果业务刚好允许负值,那么此时一定会出逻辑问题,而且难以排查 bug, 这其实是非常典型的向上向下兼容问题

3.非兼容类型互转

messageHelloReplystringmessage=1,stringadditional=2,stringage=3,int64id=4,

我们将 age 由 int32 变成 string 字符串,依旧使用 client 旧版本测试

zerun.dong$./greeter_client......2021/12/0822:55:21Greeting:"message":"Helloaddidionalworld","additional":"thisisaddidionalfield","id":123452021/12/0822:55:21message:"Helloaddidionalworld"additional:"thisisaddidionalfield"id:123453:"thisisage"2021/12/0822:57:56r.Ageis0

可以看到结构体 json 序列化打印时不存在 Age 字段,但是 log 打印时发现了不兼容的 3:"this is age", 注意 grpc 会保留不兼容的数据

同时 r.Age 默认是 0 值,即非兼容类型修改是有问题的

删除字段 messageHelloReplystringmessage=1,stringadditional=2,//stringage=3,int64id=4,

删除字段 age 也就是说序号此时有空洞,运行 client 旧版本协义

zerun.dong$./greeter_client......2021/12/0823:02:12Greeting:"message":"Helloaddidionalworld","additional":"thisisaddidionalfield","id":123452021/12/0823:02:12message:"Helloaddidionalworld"additional:"thisisaddidionalfield"id:123452021/12/0823:02:120

没有问题,打印 r.Age 当然是默认值 0, 即删除字段是兼容的

为什么 required 在 proto3 中取消了。 messageSearchRequestrequiredstringquery=1,optionalint32page_number=2,optionalint32result_per_page=3,

熟悉 thrift 或是使用 proto2 协议的都习惯使用 required optional 来定义字段属于,扩展字段一般标记为 optional, 必传字段使用 required 来约束

官方解释如下 issues2497,简单说就是 required 打破了更新 IDL 时的兼容性

永远不能安全地向 proto 定义添加 required 字段,也不能安全地删除现有的 required 字段,因为这两个操作都会破坏兼容性 在一个复杂的系统中,proto 定义在系统的许多不同组件中广泛共享,添加/删除 required 字段可以轻松地降低系统的多个部分 多次看到由此造成的生产问题,并且 Google 内部几乎禁止任何人添加/删除 required 字段

上面是谷歌得出的结论,大家可以借鉴一下,但也不能唯 G 家论

小结

IDL 修改还有很多测试用例,感兴趣的可以多玩玩,比如结构体间的转换问题,比如 enum 枚举类型上文测试的都是 server 端使用新协义,client 使用旧协义,如果反过来呢

本文能过测试 case 想告诉大家,IDL 只能追加杜绝修改

郑重声明:此文内容为本网站转载企业宣传资讯,目的在于传播更多信息,与本站立场无关。仅供读者参考,并请自行核实相关内容。