将消息类型更改为类似消息类型会破坏向后兼容性吗？

Question

我想保留我的应用程序以免将来出现向后兼容的问题。现在，我有了test.proto的这个版本：

syntax = "proto3";

service TestApi {
    rpc DeleteFoo(DeleteFooIn) returns (BoolResult) {}
    rpc DeleteBar(DeleteBarIn) returns (BoolResult) {}
}

message DeleteFooIn {
    int32 id = 1;
}

message DeleteBarIn {
    int32 id = 1;
}

message BoolResult {
    bool result = 1;
}

我对将DeleteBar()的结果消息更改为“ DeleteBarOut”之类的消息感兴趣：

syntax = "proto3";

service TestApi {
    rpc DeleteFoo(DeleteFooIn) returns (BoolResult) {}
    rpc DeleteBar(DeleteBarIn) returns (DeleteBarOut) {}
}

message DeleteFooIn {
    int32 id = 1;
}

message DeleteBarIn {
    int32 id = 1;
}

message DeleteBarOut {
    reserved 1;
    string time = 2;
}

message BoolResult {
    bool result = 1;
}

问题是与旧版.proto在线向后兼容。我可以将结果消息的名称从“ BoolResult”更改为“ DeleteBarOut”吗？

还是我应该保存消息的旧名称并编辑“ BoolResult”的字段列表？但是，如何从该解决方案的任何更改中保存DeleteFoo()？

Answer 1

当对这样的API进行重大更改时，通常的做法是在过渡时同时支持两个版本。为此，您需要在请求消息中添加一个version字段，然后在请求处理程序中，根据指定的版本将消息路由到不同的后端。一旦不再有流量流向v1后端，您就可以硬切换到v2并停止支持v1。

不幸的是，如果仅更改RPC定义而不进行版本控制，就不可能避免服务器和客户端之间的版本不兼容。当然，另一种选择是添加新的RPC端点，而不是修改现有的RPC端点。

通常，如果您要对API进行重大更改，那将是不愉快的时光。