最近在项目中遇到了一个奇怪的 coredump 问题,排查过程并不顺利。经过不断分析,找到了一个复现的步骤,经过合理猜测和谨慎验证,最终才定位到原因。
复盘下来,发现这类 coredump 问题确实比较罕见,排查起来也不是很容易。只有项目代码编译依赖管理不是很合理的时候,才可能出现。另外,在复盘过程中,对这里的 coredump 以及 C++ 对象内存分布也有了更多理解。于是整理一篇文章,如有错误,欢迎指正。
某次变更,在服务 A 的 service.proto
文件中,对某个 rpc 请求参数增加了一个字段(比如下面的 age):
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply) {}
}
message HelloRequest {
string name = 1;
string age = 2; // 增加了参数
}
message HelloReply {
string message = 1;
}
然后增加了这个字段的相关逻辑,随后编译上线了该模块。我们知道在微服务架构中,经常有多个服务共用同一个 proto 对象。如果要修改 proto 的话,一般都是增加字段,这样对调用方和被调用方都是兼容的。这里服务 A 上线后,用新的 proto ,其他用到这个 proto 的服务在重新编译前都会用老的版本,这样不会有问题。其实严格来说这样也是可能有问题的,之前踩过坑,主要是 Merge 的兼容问题,可以参考我之前的文章 Protobuf 序列化消息引起的存储失败问题分析。
正常来说,如果其他服务想更新 proto ,只需要重新编译就能用到新的 proto ,肯定不会有问题。不过这次就出问题了,服务 A 的 proto 增加字段上线后,其他通过 client 调用 A 的服务,只要重新编译上线,就会 coredump。
1
root71370 282 天前
proto 是不是很常用?我还没接触过
|
3
liberize 282 天前 via Android
大部分情况都没必要用 pb ,用 json 性能足够了,用 pb 徒增运维调试难度。
|
5
iceheart 281 天前 via Android
改动公用的接口方法的参数?
那崩溃就是最好的结果。 |