社区编辑申请
注册/登录
聊聊为什么 IDL 只能扩展字段而非修改
大数据 数据分析
本文聊聊 grpc proto 变更时的兼容问题,核心只有一条:对扩展开放,对修改关闭,永远只增加字段而不修改。

本文转载自微信公众号「董泽润的技术笔记」,作者董泽润  。转载本文请联系董泽润的技术笔记公众号。

前几年业界流行使用 thrift, 比如滴滴。这几年 grpc 越来越流行,很多开源框架也集成了,我司大部分服务都同时开放 grpc 和 http 接口

相比于传统的 http1 + json 组合,这两种技术都用到了 IDL, 即 Interface description language 接口描述语言,相当于增加了 endpoint schema 约束,不同语言只需要一份相同的 IDL 文件即可生成接口代码。

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

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

测试修改兼容性

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

  1. syntax = "proto3"
  2.  
  3. option go_package = "google.golang.org/grpc/examples/helloworld/helloworld"
  4. package helloworld; 
  5.  
  6. // The greeting service definition. 
  7. service Greeter { 
  8.   // Sends a greeting 
  9.   rpc SayHello (HelloRequest) returns (HelloReply) {} 
  10.  
  11. // The request message containing the user's name
  12. message HelloRequest { 
  13.   string name = 1; 
  14.  
  15. // The response message containing the greetings 
  16. message HelloReply { 
  17.   string message = 1; 
  18.   string additional = 2; 
  19.   int32 age = 3; 
  20.   int64 id = 4; 

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

  1. protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative helloworld/helloworld.proto 

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

  1. // SayHello implements helloworld.GreeterServer 
  2. func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) { 
  3.  log.Printf("Received: %v"in.GetName()) 
  4.  return &pb.HelloReply{ 
  5.   Message:    "Hello addidional " + in.GetName(), 
  6.   Additional: "this is addidional field"
  7.   Age:        10, 
  8.   Id:         12345, 
  9.  }, nil 

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

修改字段编号

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

  1. zerun.dong$ ./greeter_client 
  2. ...... 
  3. 2021/12/08 22:23:38 Greeting: { 
  4.  "message""Hello addidional world"
  5.  "additional""this is addidional field"
  6.  "id": 12345 

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

修改字段 name

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

  1. // The response message containing the greetings 
  2. message HelloReply { 
  3.   string message = 1; 
  4.   string additional = 2; 
  5.   int32 age = 3; 
  6.   int64 score = 4; 

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

  1. zerun.dong$ ./greeter_client 
  2. ...... 
  3. 2021/12/08 22:29:18 Greeting: { 
  4.  "message""Hello addidional world"
  5.  "additional""this is addidional field"
  6.  "age": 10, 
  7.  "id": 12345 

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

修改类型

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

1.字符串与字节数组

  1. // The response message containing the greetings 
  2. message HelloReply { 
  3.   string message = 1; 
  4.   bytes additional = 2; 
  5.   int32 age = 3; 
  6.   int64 id = 4; 

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

  1. // The response message containing the greetings 
  2. type HelloReply struct { 
  3.  Message    string `protobuf:"bytes,1,opt,name=message,proto3" json:"message,omitempty"
  4.  Additional []byte `protobuf:"bytes,2,opt,name=additional,proto3" json:"additional,omitempty"
  5.  Age        int32  `protobuf:"varint,3,opt,name=age,proto3" json:"age,omitempty"
  6.  Id         int64  `protobuf:"varint,4,opt,name=id,proto3" json:"id,omitempty"

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

  1. zerun.dong$ ./greeter_client 
  2. ...... 
  3. 2021/12/08 22:35:43 Greeting: { 
  4.  "message""Hello addidional world"
  5.  "additional""this is addidional field"
  6.  "age": 10, 
  7.  "id": 12345 

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

2.int32 int64 互转

  1. message HelloReply { 
  2.   string message = 1; 
  3.   string additional = 2; 
  4.   int64 age = 3; 
  5.   int64 id = 4; 

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

  1. zerun.dong$ ./greeter_client 
  2. ...... 
  3. 2021/12/08 22:43:32 Greeting: { 
  4.  "message""Hello addidional world"
  5.  "additional""this is addidional field"
  6.  "age": -2147483648, 
  7.  "id": 12345 

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

3.非兼容类型互转

  1. message HelloReply { 
  2.   string message = 1; 
  3.   string additional = 2; 
  4.   string age = 3; 
  5.   int64 id = 4; 

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

  1. zerun.dong$ ./greeter_client 
  2. ...... 
  3. 2021/12/08 22:55:21 Greeting: { 
  4.  "message""Hello addidional world"
  5.  "additional""this is addidional field"
  6.  "id": 12345 
  7. 2021/12/08 22:55:21 message:"Hello addidional world" additional:"this is addidional field" id:12345 3:"this is age" 
  8. 2021/12/08 22:57:56 r.Age is 0 

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

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

删除字段

  1. message HelloReply { 
  2.   string message = 1; 
  3.   string additional = 2; 
  4.   // string age = 3; 
  5.   int64 id = 4; 

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

  1. zerun.dong$ ./greeter_client 
  2. ...... 
  3. 2021/12/08 23:02:12 Greeting: { 
  4.  "message""Hello addidional world"
  5.  "additional""this is addidional field"
  6.  "id": 12345 
  7. 2021/12/08 23:02:12 message:"Hello addidional world"  additional:"this is addidional field"  id:12345 
  8. 2021/12/08 23:02:12 0 

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

为什么 required 在 proto3 中取消了?

  1. message SearchRequest { 
  2.   required string query = 1; 
  3.   optional int32 page_number = 2; 
  4.   optional int32 result_per_page = 3; 

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

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

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

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

小结

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

 

本文能过测试 case 想告诉大家,IDL 只能追加杜绝修改 (产品测试阶段随变改,无所谓)

 

责任编辑:武晓燕 来源: 董泽润的技术笔记
相关推荐

2022-04-14 10:10:59

Nginx开源Linux

2022-05-24 08:21:16

数据安全API

2022-05-16 07:35:21

Windows远程桌面远程服务器

2022-05-16 08:50:23

2022-04-21 08:09:18

Spark字段血缘Spark SQL

2022-05-23 09:41:27

2022-05-25 10:04:43

Go编程

2022-05-24 14:26:11

云原生数据库云架构

2022-05-10 08:59:25

2022-05-23 09:18:55

RocketMQ存储中间件

2022-05-23 09:16:46

新华三

2022-05-07 15:31:19

物联网5G智慧城市

2022-04-02 10:23:12

MySQL数据库

2022-05-06 09:40:48

智能云原生云原生人工智能

2022-05-17 09:00:00

Next.js餐厅网站Cosmic

2022-05-19 13:33:39

系统客户端链路追踪

2022-04-20 22:04:58

物联网安全勒索软件网络攻击

2022-05-09 13:35:56

2022-05-09 15:01:51

运维转型技术

2022-05-13 07:21:58

谷歌IO大会安卓13

同话题下的热门内容

2022年优秀预测分析工具和软件大数据技术的成功案例及趋势使用替代数据的五个隐性成本为什么不能忽视建筑物中的数据分析?数据驱动业务的18个有效策略

编辑推荐

什么是数据分析的漏斗模型?数据分析师还吃香吗?用数据告诉你对比解读五种主流大数据架构的数据分析能力《狄仁杰之四大天王》影评分析(爬虫+词云+热力图)22个免费的数据可视化和分析工具推荐
我收藏的内容
点赞
收藏

51CTO技术栈公众号