这是一个创建于 288 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在项目中遇到了一个奇怪的 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 288 天前
proto 是不是很常用？我还没接触过
|
 |
3
liberize 287 天前 via Android
大部分情况都没必要用 pb ，用 json 性能足够了，用 pb 徒增运维调试难度。
|
 |
5
iceheart 287 天前 via Android
改动公用的接口方法的参数？
那崩溃就是最好的结果。 |
Select Language