在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秒，用户反应快了很多。