Protocol Buffer高阶玩法：如何优雅地批量修改proto文件

2021年3月26日

每个程序员少不了和Protocol Buffer打交道。Protobuf现在几乎已经是业界标准了，设计rpc接口协议不会考虑其他的选择。可能也有人喜欢造轮子发明自己的一套协议，但是请相信我，造这种轮子除了可以用来汇报之外（前提是先说服老板允许你浪费时间造轮子），基本上不会给公司业务、后台服务上带来什么效率的提升。Protobuf有诸多家喻户晓的优点，比如广泛的支持各种语言、具有良好的版本兼容性、体积小解析快等等。作为后台协议这些特性可以说是基本的要求。但是protobuf之所以这么优秀，我认为还离不开它丰富的api和可扩展性。

Protobuf的api让我们可以实现一些非常定制化的需求。虽然protobuf的Generated Code可以涵盖绝大多数使用场景，但是还有些边缘需求仅仅通过Generated Code是完成不了的。遇到这些特殊的场景，去翻一翻protobuf的api文档总会有意外的收获。我就非常享受这种自由自在的感觉。从这一点上来讲，protobuf有点类似于Emacs，都具有良好的可扩展性。开发者的需求一定是千奇百怪的，创造的时候根本无法预测将来会有什么需求。但是也没问题，给开发者留好各种接口，你们有需求自己去实现就好了。

今天就结合我在实际工作中遇到的一个问题，介绍如何使用protobuf的api来高效地完成任务。

痛点

公司有一套基于Hadoop的分布式数据仓库系统(Tencent distributed Data Warehouse，简称TDW)，各个业务的海量数据都会存储在tdw中，可以通过Hive sql进行查询计算。Hive支持很多的文件格式，比如Sequence File、Avro、Parquet、ORC文件等等。但是有很多业务的数据都是protobuf格式的，比如广告的曝光点击日志。TDW为了解决这些业务的问题，支持了存储protobuf序列化之后的二进制数据，也支持用sql进行查询。

TDW既然支持pb数据的解析，那么它一定需要知道数据对应的proto，这样才能通过sql查询。因此在tdw上创建pb表的流程会有一些复杂。用户需要将数据所对应的proto文件通过页面上传，tdw内部会再把proto编译成java，才能用于数据的解析。当数据的proto文件更新后，也要在tdw上执行同样的操作来更新表结构。

proto比较简单时这套更新表的流程完全没有问题，只要上传一个proto就好了，用户没有什么额外的负担。但是在具体的业务场景下，proto会变得非常非常复杂，比如广告业务的日志proto就依赖了多达50个proto文件，依赖关系错综复杂，通常是A依赖B，B依赖C，C再依赖D，所依赖的proto又会分散在不同的文件夹下。以如下的目录结构为例。

.
├── A.proto
├── D.proto
└── dir1
    ├── B.proto
    └── dir2
        └── C.proto

几个proto的内容如下：

// A.proto
import "dir1/B.proto";

// B.proto
import "dir1/dir2/C.proto";

// C.proto
import "D.proto";

这种情况下更新pb表结构就非常痛苦了。首先在页面上是无法上传目录的，tdw也不支持先把proto打包再上传，只能一次性上传多个proto文件。这样一来就丢失了目录层级结构，同时也破坏了proto之间的依赖关系。import "dir1/B.proto";是无法成功的，因为已经没有dir1这个目录了。这种情况下，只能手动编辑proto文件，修改50多个proto中的import路径。这是第一个痛点。

第二个痛点是tdw使用2.5版本的protobuf，但是业务后台服务用的是3.7。这就导致tdw不认识proto里的一些新选项，比如cc_enable_arenas。为了顺利的更新表结构，还需要把每个proto里的这个选项清除掉。

一个proto里面有多个message，tdw如何知道哪个message才是数据所对应的呢？它采用了一种简单的解决方案，认为表名就是对应message的名称，比如表名为A，那proto里面一定要有一个message的名字也是A。这点也会令人非常痛苦，在实际的使用场景中，是极有可能message名称和表的名字不同的。比如需要为同一个message创建多张表，表名又不能重复。这时候就要修改message名称了。如果这个message里没有内嵌其他message，手动改动一下也还好。如果有内嵌的message并且被很多地方引用了，那就需要做很多的改动了。

message SearchResponse {
  message Result {
    required string url = 1;
    optional string title = 2;
    repeated string snippets = 3;
  }
  repeated Result result = 1;
}

message SomeOtherMessage {
  optional SearchResponse.Result result = 1;
}

以上面的proto为例，如果把上面的SearchResponse改为NewSearchResponse，那么SomeOtherMessage中的result字段的类型也要一并改为NewSearchResponse.Result，proto才能正常解析。

需求

为了解决上面这些问题，我们可以提炼出几个小的需求。

1. 将所有的proto放到同一个目录下，并且保持原有的依赖关系。
2. 去掉2.5版本的protobuf所不识别的option。
3. 修改message的名称为表名，并且修改所有跟该message相关的字段类型。

这些需求也可以通过脚本编辑proto文件完成，但是一定会非常复杂，不够优雅。我们需求的本质就是修改proto，能否通过api来完成这些事情呢？

api的探索

把大象装进冰箱都分为3步，我们解决这几个需求也可以大概分为3步：解析proto、修改proto、生成新的proto。只要api能提供这些能力，那整个需求就是可行的。

打开protobuf的api文档，我们可以看到有一个namespace叫做google::protobuf::compiler，看起来就像是与proto本身的编译相关的，里面果然有一个parser.h。再看看Parser这个类的介绍，文档说Parser是一个非常底层的类，只会把proto文件转换为FileDescriptorProto，用户应该会对Importer这个类更感兴趣。那就再看看Importer的文档。

看到这里大概明白了，Parser这个类只能parse单个的proto文件，Importer除了解析proto本身之外，还会递归地处理它的依赖。有了Importer，解析的问题就可以解决了。

那下一步咱们应该如何去修改proto呢？Importer的文档已经明确告诉我们会把proto解析成FileDescriptor，那么看来一定要通过这个类来进行修改了。但是仔细看了下FileDescriptor类的方法，只有读取的函数没有修改的函数。忽然想到Parser也是解析proto，但是它是把proto解析成FileDescriptorProto的，这个类有没有什么不同？

但是找了半天好像也没有FileDescriptorProto这个类的文档，protobuf的文档里面，各个类都是有链接的，点击就可以跳转过去。但是这个类就比较特殊，凡是涉及到这个类的地方，都没有链接。最终让我在descriptor.pb.h这个文件里面找到了。原来FileDescriptorProto是一个proto的message，并不是c++的类，难怪没有链接了。

FileDescriptorProto的概念是非常巧妙的：Protocol buffer representations of descriptors. descriptor.h里面都是各种Descriptor类，descriptor.pb.h都是这些类的protobuf的表达。FileDescriptor是描述proto文件的类，那么FileDescriptorProto就是这个类所对应的protobuf message。我是这么理解的，FileDescriptorProto就是proto文件的proto，用一个message来描述整个proto文件的内容。

message FileDescriptorProto {
  optional string name = 1;
  optional string package = 2;

  repeated string dependency = 3;
  repeated int32 public_dependency = 10;
  repeated int32 weak_dependency = 11;

  repeated DescriptorProto message_type = 4;
  repeated EnumDescriptorProto enum_type = 5;
  repeated ServiceDescriptorProto service = 6;
  repeated FieldDescriptorProto extension = 7;

  optional FileOptions options = 8;
  optional SourceCodeInfo source_code_info = 9;
  optional string syntax = 12;
}

proto里面的各种option、message定义以及import依赖，不过是FileDescriptorProto中的一个个字段罢了。修改proto文件，只要像修改正常的pb一样，改这些字段就可以了。

修改proto的问题也解决了，那下一步就是如何把修改后的proto输出了。回到FileDescriptor这个类，我们可以看到有一个DebugString的方法，可以把proto再重新输出为字符串。FileDescriptorProto如何转换为FileDescriptor呢？文档里面也写了，可以使用DescriptorPool这个类。

经过对文档的这一番探索，我们大概就有思路了。修改proto并且输出到新的文件中大概要经历如下具体的几个步骤：

1. 通过Importer解析需要处理的proto文件以及它的依赖，拿到FileDescriptor对象。
2. 将FileDescriptor对象转换为FileDescriptorProto。
3. 按照需求修改FileDescriptorProto。
4. 通过DescriptorPool将FileDescriptorProto转换回FileDescriptor。
5. 将FileDescriptor的DebugString输出到文件中。

文件路径与依赖的处理

为了将所有的proto都放在一个目录下，并且还保持原来的依赖关系，我们可以采用一种简单的处理方式，就是将路径和文件名拼到一起作为新的文件名，这样可以确保文件名不会冲突。比如dir1/dir2/C.proto修改为dir1_dir2_C.proto。文件名修改后，proto中的import也需要做同样的修改。

const google::protobuf::FileDescriptor *fd = importer.Import(proto);
google::protobuf::FileDescriptorProto fdp;
fd->CopyTo(&fdp);

// iterate through dependencies
for (int i = 0; i < fdp.dependency_size(); i++) {
  string dep(fdp.dependency(i));
  string new_dep(boost::replace_all_copy(dep, "/", "_")); // simple replace

  fdp.set_dependency(i, new_dep);
}

我们通过FileDescriptorProto中的dependency字段遍历proto的依赖，逐个进行简单的字符串替换，再更新dependency字段。这样原来proto中的import "dir1/dir2/C.proto"就变成了import "dir1_dir2_C.proto"。

Depth-first search

前面讲过我们需要通过DescriptorPool将FileDescriptorProto转换回FileDescriptor，再输出最终的proto到文件中，这里需要用到DescriptorPool的BuildFile方法。但是在实际操作时遇到了问题：BuildFile要求当前proto所依赖的全部文件都已经build成功。

假设proto的依赖关系如上图，我们需要处理A，那么应该先确保A的依赖都已经执行了BuildFile。对于A所依赖的proto也是同样的要求。所以我们要处理整棵树的叶子节点，然后再处理父节点，最后才是根节点。处理的顺序我也标注在节点旁边。这不就是深度优先搜索吗？用递归就可以实现了，非常简单。

int fd_to_proto(const po::variables_map &vm,
                const boost::filesystem::path &dir,
                const google::protobuf::FileDescriptor *fd,
                google::protobuf::DescriptorPool &pool) {
  google::protobuf::FileDescriptorProto fdp;
  fd->CopyTo(&fdp);

  for (int i = 0; i < fd->dependency_count(); i++) {
    const google::protobuf::FileDescriptor *deps_fd = fd->dependency(i);
    fd_to_proto(vm, dir, deps_fd, pool);
  }

  // return if this proto has been processed
  if (pool.FindFileByName(fdp.name()) != NULL) {
    return 0;
  }

  // process fdp

  // build
  const google::protobuf::FileDescriptor *new_fd = pool.BuildFile(fdp);

  // output to file

  return 0;
}

最后还剩一些小问题，比如去掉cc_enable_arenas、修改message名称等等，看看FileDescriptorProto也就知道怎么用了，这里就不再赘述。完整代码请参考protobuf-api-examples。

有了这个工具，之前需要花大量时间手工处理的任务，现在一个命令就可以搞定，彻底释放了我的生产力。需求本身确实是非常非常小众的，在stackoverflow上肯定没有解决方案，只能自己探索。如果你跟我不在一个公司没用过tdw，那压根就不会遇到这种场景。这篇文章并不能帮大家解决什么实际的问题，只希望让大家了解到protobuf api的威力，借助api我们确实是可以解决问题的。另外把我解决问题的思路描述出来，下次如果你也有自己的小众需求了，可以用同样的思路尝试解决。