protobuf json
为什么大厂这么爱用protobuf？ https://mp.weixin.qq.com/s/COQu3rckfZJUelSVBV6IMA
为什么大厂这么爱用protobuf？
话题背景
在protobuf在国内兴起的时候，json over http 的 RESTful ，api也在国内同步兴起了。司内也有很多api是tRPC写的，很多是基于protobuf的，也有很多就是 json over http 的。那么有同事就有这个疑问了：这里面只有protobuf的数据结构最复杂，而且打开任意一个 protobuf 的 java 文件都会让机器卡顿很厉害，很难想象前人在通过protobuf 来理解数据结构的时候，是不是一样非常麻烦？
那么推动我们使用这项技术，让它们在很多团队之间占据统治地位的根本原因是什么？是某些历史团队的背景偏好么？该如何解决打开文件卡顿的问题？
今天就让我们来一起聊聊“为什么大厂这么爱用protobuf？”
鹅厂工程师的看法
@ashui-IEG后台开发工程师
▼
protobuf 的好处很多的，不只是序列化还有一些微服务接口声明(IDL)。
序列化反序列化
序列化与反序列化的性能 这个不用多说，简单了解下原理就能理解，性能肯定比json快。
这里也有一个图，之前同事分享的：
序列化：
反序列化：
这些在内部一些rpc 请求之间还是很可观的。
IDL (Interface description language)
我们不妨回顾一下 如果 直接使用 json over http 开发接口的过程。
1. 编写接口 定义路由 eg: /a/b/c
2. 定义好入参/出参结构 req struct rsp struct
3. 解析入参(解析http从 query or body 拿到入参 放入 req
4. 业务处理逻辑
5. 准备rsp struct 返回
对于小规模业务来说，或者说不怎么迭代的系统来说，这样确实还行。
但是随着业务的发展，你现在有100个接口你其实根本无法维护这些接口的，比如 前端来找你 要知道 /a/b/c 接口的入参出参（接口文档），如果你们有维护 swagger 那还好说，不然你只能说一句我先去看下代码.....protobuf 的好处通过 pb 去定义Interface ，并且提供插件能力能让你自己去解析pb，开发自己。
比如 trpc-go 就是基于pb的接口定义+自行开发的插件 去生成代码桩。
甚至如果你真的还是想用 json over http 的模式也行，用 pb 定义接口，通过自己开发插件将 pb 生成http 代码桩，业务开发只需要关注 核心的 业务处理逻辑，其他都可以代码生成。
对于接口文档的维护完全都不需要专门去写文档，你改了pb，文档就自己生成了....
当然你也可以去生成 swagger，前端 ts 结构，客户端 java 接口..... 一套pb 大家一起享福。
随着这些插件开发的越多(生态也就好起来了）
@titus-IEG运营开发工程师
▼
说实话，我觉得jce比protobuf要好用，但是没办法，生态位置还是领先，开源组件全在用它。
@thomas-TEG后台开发工程师
▼
举个例子，json 没有 schema，今天加个字段，明天改个类型，到时候上下游对接都不知道 json里面到底传什么类型。选 protobuf，变更的时候在代码仓库里至少知道改了那个字段，上下游对接只要根据 schema 定义就知道。
@jinlong-PCG后台开发工程师
▼
上家公司用过json，在c++里面解析json简直就是灾难，因为不知道上游会传过来啥，每次要先判断是否存在这个字段，然后再判断类型是否正确，稍不注意就可能导致core。pb强 schema 且强制兼容，在开发的时候能省不少工作量，减少一些异常失误。当然缺点就是要看里面的内容每次都要解析。
@ronaldo-IEG后台开发工程师
▼
绝大多数用pb的团队，考虑的首要问题都不是序列化性能。主要考虑
1. 需要一种统一的编程语言无关的方式来定义服务的接口，它就是文档，而且一定是最新的文档。它需要足够有表达力，又足够简洁明了，其实就是IDL（可选：pb thrift）
2. 在IDL的前提下，找生态最好的，支持语言最多的（pb）
3. 在2的前提下找性能尽可能高的（不用挑了）
@erien-TEG数据工程师
▼
主要是强schema化吧，跨语言序列化需求才是其次的。数据结构复不复杂是业务的问题，你说的proto是ams大仓里的proto吧，经过了这么多年迭代也正常，idea使用的话建议忽略编译生成的java文件，直接用proto插件识别proto文件里的字段。
@andy-TEG应用研究工程师
▼
如果从实际使用情况来看：
1. rpc上的 capn proto, flatbuffers这些效率更高但社区不够大
2. big data上基本都用上arrow了，protobuf现在很少了
3. web和相关的社区一直是json为主
另外从纯编解码效率来看，protobuf对比json的优势不是格式问题而是实现问题(如果不是用json over http1.1 vs protobuf vs http2 aka grpc来对比的话)，所以感觉还是各个社区的历史原因吧。
@quinn-TEG应用开发工程师
▼
Json重在可读性，一般前端交互用很广泛，小巧且便于调试。Protobuf重在高性能，在性能要求较高的地方，比如后端协议这块比较有优势，调试起来没json顺手，因为是二进制的，非明文。
@chair -IEG SRE工程师
▼
手游当年刚起来的时候， 世界移动网络大多处于2G和3G的状态，当时我去了神奇公司内，入职要算八字的那家。他们的大厅就是用json传的数据。我过去之后，看了一下pb的特征，就选定用pb替换json。结果原本要12秒才加载完毕的大厅列表，用了pb，3秒，用户反应快了很多。
