讯享网

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