前几年业界流行使用 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 官方用例，感兴趣自查

syntax = "proto3";  option go_package = "google.golang.org/grpc/examples/helloworld/helloworld"; package helloworld; &n聊聊bsp;// The greeting service definition. service Greeter {   // Sends a greeting   rpc SayHello (HelloRequest) returns (HelloReply) {} }  // The request message containing the user's name. message HelloRequest {   string name = 1; }  // The response message containing the greetings message 为什HelloReply {   string message = 1;   string additional = 2;   int32 age = 3;   int64 id = 4; } 

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

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

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

// SayHello implements helloworld.GreeterServer func (s *server) SayHello(ctx&nb么 sp;context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {  log.Printf("Received: %v", in.GetName())  return &pb.HelloReply{   Message:    "Hello addidional " + in.GetName(),   Additional: "this is addidional field",   Age:        10,   Id:         12345,  },&nbsIDp;nil } 

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

修改字段编号

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

zerun.dong$ ./greeter_client ...... 2021/12/08 22:23:38 Greeting: {  "message": "Hello addidional world",  "additional": "this is addidional field",  "id": 12345 } 

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

修改字段 name

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

// The response message containing the greetings&nbsL p;message HelloReply {   string message = 1;   string additional = 2;   int32 age = 3;   int64 score = 4; } 

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

zerun.dong$ ./greeter_client ...... 2021/12/08 22:29:18 Greeting: {  "message": "Hello addidional world",  "additional": "this is addidional field",  "age": 10,  "id":只能 12345 } 

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

修改类型

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

1.字符串与字节数组

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

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

// The response message containing the 扩展;greetings type HelloReply struct {  Message    string `protobuf:"bytes,1,opt,name=message,proto3" json:"message,omitempty"`  Additional []byte `protobuf:"bytes,2,opt,name=additional,proto3" json:"additional,omitempty"`  Age        int32  `protobuf:"varint,3,opt,name=age,proto3" json:"age,omitempty"`  Id         int64  `protobuf:"varin字段t,4,opt,name=id,proto3" json:"id,omitempty"` } 

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

zerun.dong$ ./greeter_client ...... 2021/12/08 22:35:43 Greeting: {  "message": "Hello addidional world",  "additional": "this is addidional field",  "age": 10,  "id": 12345 } 

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

2.int32 int64 互转

message HelloReply {   string message = 1;  而非; string additional = 2;   int64 age = 3;   int64 id = 4; } 

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

zerun.dong$ ./greeter_client ...... 2021/12/08 22:43:32 Greeting: {  "message": "Hello addidional world",  "additional": "this is addidional field",  "age": -2147483648,  "id": 12345 } 

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

3.非兼容类型互转

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

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

zerun.dong$ ./greeter_client ...... 2021/12/08 22:55:21 Greeting: {  "message": "Hello addidional world",  "additional": 聊聊;"this is addidional field",  "id": 12345 } 2021/12/08 22:55:21 message:"Hello addidional world" additional:"this is addidional field" id:12345 3:"this is age" 2021/12/08 22:57:56 r.Age is 0 

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

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

删除字段 message HelloReply {   string message = 1;   string additional =&nbs为什p;2;   // string age = 3;   int64 id = 4; } 

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

zerun.dong$ ./greeter_client ...... 2021/12/08 23:02:12 Greeting: {  "message": "Hello addidional world",  "additional": "this is addidional field",  "id": 12345 } 2021/12/08 23:02:12 message:"Hello addidional world"  additional:"this is addidional 么 field"  id:12345 2021/12/08 23:02:12 0 

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

为什么 required 在 proto3 中取消了? message SearchRequest {   required string query = 1;   optional int32 page_number = 2;   optional int32 result_per_page = 3; } 

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

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

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

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

小结

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

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

• ·标签: 豆包 微信 努比亚 手机助手
• ·AlphaFold2鍘熺悊锛氭敞鎰忓姏鏈哄埗鍙栦唬鍗风Н缃戠粶锛岄�娴嬪噯纭�€ф彁鍗囪秴30%
• ·标签: 大众汽车 奥迪 保时捷 斯柯达
• ·标签: 连连数字 章征宇 沈恩光 孙大利
• ·零一万物大调整：李开复押注ToB，三位新高管上任加速商业化突围
• ·濡備綍閫氳繃鍔犲瘑鏈哄櫒浜鸿幏鍒╋細浜ゆ槗鏈哄櫒浜鸿В閲�
• ·DeepSeek招人 建GW级算力基础设施
• ·95%PyTorch库都会中招的bug！特斯拉AI总监都没能幸免
• ·人工智能和物联网等技术可以在缓解气候变化风险方面发挥巨大作用
• ·IDC：2022年中国人工智能软件市场规模10年来首现负增长
• ·云安全日报210326：Ubuntu OpenSSL传输协议工具包发现拒绝服务漏洞，需要尽快升级
• ·华为加大数据中心能源领域的投入 发布最新伙伴政策
• ·影禾医脉联合北京天坛医院发布全球首个全疾病覆盖颅脑CT辅助报告大模型
• ·标签: 网易 有道 云音乐 燕云十六声
• ·在多云世界中维持对您的安全基础架构的控制
• ·标签: Mobileye Mentee Robotics 阿莫农·沙舒亚 自动驾驶