Open chen3feng opened 3 years ago
Protobuf 是 Google 2008 年开源的消息格式，在很多开源项目中及很多公司内部得到的很大的应用。
Protobuf 的版本在发布后一直很稳定，只有一些修修补补，直到 2014 年，发布了 2 系列的最后一个版本 2.6.1，然后就突然开始搞 3.0，并引入了新的 proto3 语法，引入了不少不兼容而且匪夷所思的变更。另外 proto3 语法发布后，就把原来的语法称为 proto2，那么有 proto1 吗？我们来扒一下这背后的故事。
proto3
proto2
proto1
Protobuf 最早是 Google 传奇技术大神 Jeff Deam 和他的好基友 Sanjay Ghemawat 设计和实现的，关于这俩人， 可以读一下《Jeff Dean的激荡人生：我和Sanjay在同一台电脑上写代码》这篇报道。
这就是最早的 protobuf。
后来一个叫 Kenton Varda 的工程师做了一系列的改进， 因为不完全兼容原来的版本，所以称为 protobuf2（Google的设计哲学之一是不过分设计，所以经常重新实现一些旧系统，甚至包括他们的那个庞大的单一代码库，叫google3，也是类似的思路。不过我个人觉得golang语言设计方面显得不足可能也是受这个思路影响），并在 2008 年对外开源，这就是为何 protobuf 语言的版本号从 2 开始的原因。据在 Google 工作过的朋友说，升级到proto2用了2年才完成。
后来 Kenton Varda 因为晋级失败等原因离职了。
Google 派了 4 个人接手了 protobuf，这些人就在 pb2 的基础上做了大量改造，就是现在的 protobuf3。 Google 此时改进 protobuf 是为了推广 grpc，而推广 grpc 则是为了卖谷歌的云服务。
新接手的这些人显然有不同的想法，而且在我看来并不完全了解 protobuf 的设计精髓。和 proto2 不兼容的 proto3 确实通过甩包袱修正了 proto2 中的一些问题，比如 enum 的兼容问题，但是居然也做出了把很重要的 UnknownFieldSet 特性都给去掉了的糟糕设计，后来很多人强烈抗议才加回去。
UnknownFieldSet
optional 关键字是这次交接的又一个牺牲品，在消息中，optional 机制可以用来表示一个字段不存在，这对很多应用来说是很有用的，但是 proto3 基于实现方便，支持更多语言等原因给去掉了，这样程序就无法区分一个字段到底是0或者空，还是真的没设置。为了解决在和 JSON 转换时表示不存在的问题，又引入了丑陋的 wrapper 类型。
optional
Kenton Varda 在 Stackoverflow 上的回答也说支持 optioanl 是坚持使用 proto2 的完美理由，proto3 去掉 optional 是为了支持更多的更弱智的语言，“我个人认为缺乏访问器和属性的语言不是很好的语言，protobuf 不应该针对它们进行设计，但这不再是我的项目”。
后来，Protobuf 3.12 版在 proto3 语言规范中也恢复了对的 optional 的支持，并在 3.15 版中设为默认开启。
Kenton Varda 离开 Google 后，创建了一个叫沙尘暴创业公司 ，并搞了个叫Cap'n Proto的开源协议描述系统（有点类似 Google 搞得另一个叫 flatbuffers的东西），努力推广自己这套新东西。
为了回应公司内对 Protobuf 需求堆积的抱怨，Kenton Varda 虚构了一个Protobuf 团队 来回应这个问题， ，
说团队里有几个超级英雄，其实只有他自己。
后来这个页面被放到外网，并在历史记录中写到（为方便阅读，以下为机器翻译）：
该页面最初写于2009年夏天，在有太多人问肯顿这样的问题之后，例如“我还应邀请protobuf团队的其他人参加吗？”，此页面最初在Google内部发布。或“ protobuf-team何时会执行我的功能请求？” 当时，尽管Kenton基本上全职从事Protobufs一两年的工作，包括正式2008年7月开放源代码版本的大部分工作，但他仍被正式分配给搜索基础架构。2009年秋天，肯顿正式成为Protobufs的全职员工，尽管他仍然是唯一的全职工作人员。2010年春季，在管理层的鼓励下，Kenton转到了一个新项目，Protobuf团队中再也没有人。2010年秋天，成立了一个由四人组成的新团队，负责Protobufs，到今天为止，该团队基本上保持完整。同时，肯顿（Kenton）于2013年初离开了Google，现在是Sandstorm.io的联合创始人和首席开发，他在那里更加快乐。
后来 Kenton Varda 可能是创业不怎么顺利（不过我看 sandstorm 网站还在），去了 Cloudflare 当打工人，目前的职位是Principal Engineer。
语言等涉及大量用户的系统，做不兼容修改是一件风险极大的事情，很容易失败。Proto3 是一例，而 Python3 的教训更大，Python 之父 Guido van Rossum 甚至说永远不会有 Python 4，谁提就跟谁急。
增加特性一般没问题，但是去掉特性时，一定要慎之又慎，你不知道多少设计已经依赖了这些特性。
参考资料全部来自公开信息：
Protobuf 的演化历史和背后的恩怨
背景
Protobuf 是 Google 2008 年开源的消息格式，在很多开源项目中及很多公司内部得到的很大的应用。
Protobuf 的版本在发布后一直很稳定，只有一些修修补补，直到 2014 年，发布了 2 系列的最后一个版本 2.6.1，然后就突然开始搞 3.0，并引入了新的
proto3语法，引入了不少不兼容而且匪夷所思的变更。另外 proto3 语法发布后，就把原来的语法称为proto2，那么有proto1吗？我们来扒一下这背后的故事。历史
Protobuf 最早是 Google 传奇技术大神 Jeff Deam 和他的好基友 Sanjay Ghemawat 设计和实现的，关于这俩人， 可以读一下《Jeff Dean的激荡人生：我和Sanjay在同一台电脑上写代码》这篇报道。
这就是最早的 protobuf。
后来一个叫 Kenton Varda 的工程师做了一系列的改进， 因为不完全兼容原来的版本，所以称为 protobuf2（Google的设计哲学之一是不过分设计，所以经常重新实现一些旧系统，甚至包括他们的那个庞大的单一代码库，叫google3，也是类似的思路。不过我个人觉得golang语言设计方面显得不足可能也是受这个思路影响），并在 2008 年对外开源，这就是为何 protobuf 语言的版本号从 2 开始的原因。据在 Google 工作过的朋友说，升级到proto2用了2年才完成。
后来 Kenton Varda 因为晋级失败等原因离职了。
Google 派了 4 个人接手了 protobuf，这些人就在 pb2 的基础上做了大量改造，就是现在的 protobuf3。 Google 此时改进 protobuf 是为了推广 grpc，而推广 grpc 则是为了卖谷歌的云服务。
新接手的这些人显然有不同的想法，而且在我看来并不完全了解 protobuf 的设计精髓。和
proto2不兼容的proto3确实通过甩包袱修正了proto2中的一些问题，比如 enum 的兼容问题，但是居然也做出了把很重要的UnknownFieldSet特性都给去掉了的糟糕设计，后来很多人强烈抗议才加回去。optional关键字是这次交接的又一个牺牲品，在消息中，optional 机制可以用来表示一个字段不存在，这对很多应用来说是很有用的，但是 proto3 基于实现方便，支持更多语言等原因给去掉了，这样程序就无法区分一个字段到底是0或者空，还是真的没设置。为了解决在和 JSON 转换时表示不存在的问题，又引入了丑陋的 wrapper 类型。Kenton Varda 在 Stackoverflow 上的回答也说支持 optioanl 是坚持使用 proto2 的完美理由，proto3 去掉 optional 是为了支持更多的更弱智的语言，“我个人认为缺乏访问器和属性的语言不是很好的语言，protobuf 不应该针对它们进行设计，但这不再是我的项目”。
后来，Protobuf 3.12 版在 proto3 语言规范中也恢复了对的 optional 的支持，并在 3.15 版中设为默认开启。
八卦
Kenton Varda 离开 Google 后，创建了一个叫沙尘暴创业公司 ，并搞了个叫Cap'n Proto的开源协议描述系统（有点类似 Google 搞得另一个叫 flatbuffers的东西），努力推广自己这套新东西。
为了回应公司内对 Protobuf 需求堆积的抱怨，Kenton Varda 虚构了一个Protobuf 团队 来回应这个问题，
，
说团队里有几个超级英雄，其实只有他自己。
后来这个页面被放到外网，并在历史记录中写到（为方便阅读，以下为机器翻译）：
后来 Kenton Varda 可能是创业不怎么顺利（不过我看 sandstorm 网站还在），去了 Cloudflare 当打工人，目前的职位是Principal Engineer。
教训
语言等涉及大量用户的系统，做不兼容修改是一件风险极大的事情，很容易失败。Proto3 是一例，而 Python3 的教训更大，Python 之父 Guido van Rossum 甚至说永远不会有 Python 4，谁提就跟谁急。
增加特性一般没问题，但是去掉特性时，一定要慎之又慎，你不知道多少设计已经依赖了这些特性。
参考资料
参考资料全部来自公开信息：