protobuf gRPC 这种写配置文件生成代码的形式 "流行"的原因是什么?

[chaleaoch]

再比如 mybatis 用 xml 写 sql.
在比如 spring 初期用 xml 做 IOC...
诸如此类. 这么做的目的是什么?

作为一个 python 程序员不是很习惯.


第二个问题是, 为什么讲 go 和 node 什么的 从 gRPC 里面扯出去新搞了一个仓库.
类似的还有 protoc vs protobuf-gen-go


谢谢大佬们.

[12101111]

@bwangel 一个字段不许少，一个字段不许多是你选的 json 解析器的问题, 我用 rust 的 serde 就没有这么多麻烦, 结构体上面加几个属性就完事了

[uselessVisitor]

历史原因

[luozic]

网络和 cpu 都是比较昂贵的资源，计算机上为了节约资源，各种骚操作多得是。 了解一下，字符集编码

[paoqi2048]

其实这个在游戏领域还挺普遍的

[bwangel]

@12101111

这不是语言的问题，这是程序的设计问题。前端版本由 V1 升级成了 V2，它们说不用 A，B，C 三个字段，这时候更新文档，告知后端，这是不可靠的，没准后端忙就忘了，反正也不会出错。如果前后端共用一份 protobuf 文件，那么就会强制后端更新接口，如果不更新会出错。

另外顺口问一句，哪家公司的 web 接口是用 rust 写的，让我膜拜一下。或者不一定是公司，哪个网站是用 rust 写的，让我膜拜膜拜。

[bwangel]

@wellsc

这不仅仅是后端的事情，而是前后端要共同维护一份协议，告知双方现在在用哪些字段。维护一份 proto 文件，比维护一个 Markdown 文件要可靠的多。

[bwangel]

很多回复里都说 protobuf 的优势是编译后数据体积小。但我觉得这不是一个主要的优点，文本内容的压缩率很高的，Nginx 开启 gzip 压缩后，json 响应并不一定比 protobuf 响应要大很多。

我觉得主要优点就是强制性，定好一个规范后，通信的双方必须完全遵守它。

JSON 也可以做到这一点，但没有跨语言的解决方案，例如 21 楼老哥说的 rust 的 serde 就可以做到，但它不能跨语言，前后端无法使用同一份约束文件，那维护协议还是得靠 Markdown，还是不靠谱。

支持这几种主流语言（ Java，PHP，Python，JS，Object-C，Swift，C++, Go ）的数据序列化解决方案中，protobuf 是最好的选择。

[wellsc]

@bwangel 这……贵司还在用 markdown 维护接口文档？

[Evilk]

json+http
走遍天下

[bwangel]

@wellsc

额，是的，有什么更好的方案可以推荐一下吗？我用过 swagger，但它没办法要求客户端，感觉是一个交互式的 Markdown 。

[jim9606]

@bwangel JSON 想做到这点的可以用 JSON schema，前后端都老实点在 encode/decode 时用 schema validator 验证一遍。
( https://json-schema.org/implementations.html )

自描述的数据格式理论上都可以用 schema 验证，protobuf 由于不是自描述结构，所以等于强制所有程序实现了 schema 的功能。

[dayeye2006199]

面向协议编程的胜利。
凡是接口文档另外开 markdown 靠人来写作的，基本都不怎么靠谱。
主要靠良好的接口声明+代码内注释，自动生成接口文档。

[dcoder]

@jim9606
JSON schema 的思想是好，但是实现略复杂，用起来感觉重
要是有个简化版的 JSON schema + 统一标准的各语言实现就好了

[wweir]

我理解很重要的一个原因是标准化：
平时合作过程中不得不面对各种接口对接的事情，很多人习惯不同，更有很多人自创一些奇奇怪怪的标准。这时使用 GRPC 这个事实标准会省事很多，避免了很多对接的麻烦。
更爽的是，用 GRPC 可以避免流控、追踪等一大堆通用型、难度都很高的事情，专注于自己的业务

[iyaozhen]

可能楼主主要是相对比较 json+http 吧
其实 protobuf 也可以和 http 配合，我们几乎都这样。

protobuf 主要是对标 json 。
1. 协议字段严格约束，比如一个 list，如果没有应该返回 []，但被调方有可能返回 false 。轻则调用失败，重则客户端 crash 。不要觉得这个很低级，我已经见过很多次了。
2. protobuf 解析的更快，这个就要从 socket 编程说起，那时候都是定义一个 c 结构体，传输数据，其它语言按 c 的实现。但有个问题，没有中间 IDL 文件，别的语言都是对着着.c 文件自己实现，用现在的话说就是会被 C 掐脖子，实现个新功能还得看 c 支不支持。随着 web 2.0 c 也没落了。有些同学可能了解，中间出现过 msgpack 用的人也很多。但 pb 的爹好呀。
看 https://msgpack.org/ 就知道为什么二进制打包的格式更好了。
3. pb 更近一步的是 gRPC 生态繁荣，虽然大公司都是自研的 rpc 框架，但肯定得对标 gRPC，就很自然的选择了 pb

这里的流行更多的是随着微服务的发展，rpc 更加的流行带来的。为了效率就必然有很多工具生成代码。
protoc 只是把发起一个请求的 request/response 的数据结构生成了，方便.set 各种方式赋值，组成请求。但 protobuf-gen-go 更进一步是吧 client 和 server 的代码框架都生成了。类似于脚手架

[evilStart]

@bwangel openapi

[evilStart]

@bwangel openapi 比 markdown 好多了吧。不光是一个接口文档，各语言和框架应该都有支持通过 Open API 生成接口、validation 甚至 stub 的工具。更新一份文档各端都能保证同步啊。

[Joway]

这是一个很长的问题，前面有些人说的 json+http 走遍天下，首先对计算机历史而言，json 是一个很新的技术，以前的人就没这玩意可用。再者，很多时候 json 走不遍天下。如果你们公司有 10 种编程语言，用 json 你需要人肉维护 10 种 json 的 struct，如果有类型变化或者字段新增，也需要人肉去维护这个变更，这在大规模 RPC 服务场景下是不太可能的。何况有些字段是 required，靠人力手动在 10 种编程语言里实现这个约束是不现实的。而这个仅仅是序列化层面的事情，

我建议把这几个问题串起来看 RPC 在这几十年中的演变会更加明白其中的意义，最新在写一个 RPC 系列： https://blog.joway.io/tags/rpc/ ，可以看看序列化和连接这部分，就能够明白为什么 RPC 是一个语言强相关的活，很难用一个语言 implement 走遍天下（现在的 Service Mesh 其实就是想要用一个语言实现走天下）。

[henryhu]

我们刚使用上 pb， 有下面两点（亮点），真香：
1. 体积小，而且系列化 /反系列化结构化数据速度快。我们处理 3D 模型， 模型文件通常体积大，处理相当耗时，所以这个功能对我们来说是刚需。
2. 跨语言。我们要在多个平台共享数据，涉及 JS，c#，Ruby 。