我最近遇到了一个非常大的关键任务项目,其中所有配置文件都是使用文本 protobuf 定义定义的。配置文件旨在供人类阅读和编辑。
例如
message ServerSettings {
required int32 port = 3022;
optional string name = "mywebserver";
}
我个人觉得这很幽默。但它实际上是一种合理的保持简单的技术,还是明显的愚蠢?!
换句话说,这是否存在真正的、实际的问题?
我最近遇到了一个非常大的关键任务项目,其中所有配置文件都是使用文本 protobuf 定义定义的。配置文件旨在供人类阅读和编辑。
例如
message ServerSettings {
required int32 port = 3022;
optional string name = "mywebserver";
}
我个人觉得这很幽默。但它实际上是一种合理的保持简单的技术,还是明显的愚蠢?!
换句话说,这是否存在真正的、实际的问题?
如果那是格式的文本原型,那么......无论如何,我猜。如果它有效,那么它与任何其他序列化格式一样合理。
如果那是原始模式,那么它是非法的(= 之后的值是字段编号)。
Json 或 XML 可能更典型,但只要它有效,它就不是“愚蠢的”。所以最终的问题是:它有效吗?
我认为这很聪明。我猜他们通过 protoc --encode 传递它来生成一个实际解析的二进制文件。
优点: 1. 生成代码来解析配置 2. 类型验证 3. 与键/值相比更健壮的配置文件,因为它支持结构、联合、映射和数组 4. 配置数据现在是可序列化的,这意味着它可以很容易地公开到 RPC 或 IPC 接口。
缺点: 1. 映射/数组的语法可能有点冗长。2. 如果您在内存限制严格的系统上,则需要在目标上安装 protoc 以及 libprotobuf.so。