Json VS Protobuf

@est

感谢推荐 ，不过非主流格式 是从来就不会考虑的。
毕竟 是要在不同语言之间 交换数据的。 所以还是得用 通用点的

json在后期大规模使用的时候，如果文档不完善或者相关接口资料更新不及时，绝对是个灾难

感觉 http 接口还是用 json 好一点，可读性强，也方便扩展，pb两端都要重新编译。内部模块传输的话 pb 体积小，性能好。

@alpha1130 你说的这个问题, 如果规划不档, 或者 msg 校验不严格, 任何 msg 格式都有这问题

推荐 lz 看看 JSON schema, 可以做跨语言的 JSON msg 严格校验
http://json-schema.org/examples.html
http://json-schema.org/implementations.html

@yueyoum msgpack优势在size和speed，我们序列化数据存储和计算模块优先选择了它

@dcoder

我倒不知道有个 json-schema 来规定这种事情

不过我以前自己想过类似的实现：

{
"version": xxx,
"fields": ["a", "b"],
"a": xxx,
"b": xxx
}


带有 version， 这样在一定程度上做到 不同版本兼容
fiels， 就是来说明这个 json 有那些 key 是带着数据的


就如同你说的， 规划好了， 其他方式也能做到这样

Apache Thrift呢？

@neoblackcap

以前看过，觉得有点复杂， 就没再研究了

@dcoder

@dcoder
json存在这个问题，不过像protobuf, thrift不会有那么大的问题

我说 NBT 你会不会打我？

https://github.com/XadillaX/mcnbt

只是开个玩笑 2333333。

@alpha1130 赞同，Protobuf 相比 JSON 的优势在于它本身带有严格的 schema validation，一份 .proto 文件既作为 input/output 的入口，又作为规定数据格式的文档，在跨语言多人协作的项目上用起来不能更爽。实际上我觉得 Protobuf 和 JSON 是完全不同的两种东西，Protobuf 是 schema + data format，schema 是我们可以看见的 proto 文件里的定义，data format 是它序列化成二进制数据的格式，JSON 只有 data format…至于 JSON schema，个人觉得是一种很勉强的实现，在本身没有 schema 的数据格式上做 schema 的事情，无论是写起来还是用起来都很麻烦，说到底，JSON 只是一种轻量的、面向 Web 的 data format 罢了。

protobuf在Google大规模的使用 是最好的例子

@alpha1130
@reorx
很好的讨论, 看完对 Protobuf 更感兴趣了

不过我再提个问题, 如果后端 service 多用 JSON 存储, 比如各种 NoSQL database 都流行存 JSON. 不只是 MongoDB, 还有很多重量级的产品都是直接用 JSON 来描述数据的, 严格与否只是 JSON format 制定者的严谨程度决定的. 比如 DynamoDB, ElasticSearch.

这样的话, 用 Protobuf 的数据还是得再做一次到 JSON 的转化.
我设计时候, 喜欢 Layers 尽量少, 一堆 Layer 和 data format 之间转换, 我觉得设计比较笨重.
比如我存 JSON-based log 到 MongoDB/DynamoDB/ElasticSearch 的话, 直接用 JSON 是非常方便和简洁的设计.

@yueyoum
还有, 一般的 JSON on Mono 库在 iOS 上是有 AOT 坑的, 所以我才专门推荐了一个 JSON .NET 库.
同理, 你可以 Google 一下 protobuf-net Unity/Mono AOT 这些关键词组合, 应该也是有坑的.

@dcoder
protobuf-net 在IOS确实有 AOT的问题， 我在 github中的说明里 特别提过了，以及解决办法。

估计是 那篇说明太长， 大部分都没仔细看。

就像上面还有些同学总说 web 什么的， 显然我不是做web的啊。


关于 Layers， 我的感觉是 Layers 肯定是不会少的，

毕竟你不会直接把数据库中的数据返回给客户端，也不会直接把客户端发来的数据存入数据库。
肯定要加

一层数据校验 用于接收客户端消息
一层数据打包 用于给客户端发送消息
一层事件发送 （可选），用于hook，或者统计

你的意思应该是 这么多层 你都想用同样的方式， 比如json， 而不想各种格式都有 对吧？



还有 其实说的那些 JSON SCHEMA 格式校验，
我觉得根本没必要。

无论是客户端还是服务器， 对于接收到的消息， 按照 预设的方式去解析， 如果解析出错
直接报 消息格式 错误就行。

@yueyoum
是的, 只是在 JSON 这一个通用格式上做各种逻辑, 这种统一格式的设计会非常简洁
JSON SCHEMA 是说基本的 filed 校验逻辑不用再写了, 因为在不同语言中再写一遍还是挺麻烦

另外, 抱歉我没看到你处理 protobuf-net AOT 的方法, 能麻烦你贴一下链接么, 学习一下 :)

@dcoder 其实 JSON 和 Protobuf 我都很喜欢，两者都有自己的优点，根据场景恰当地挑选要使用的技术就好了。

我觉得 JSON 使用的场景一般是，不太需要考虑内部协定的 schema，或者说多个服务之间使用的数据格式并不强要求是一致的。比如一个 Web 后端 A，内部依赖服务 B，A 暴露给客户端的接口是 RESTful 的 JSON API，A 调用 B 时通过 B 提供的 RPC library，整个服务场景中存在两种接口和数据格式，互相没有什么关联，也不要求一致，这时用 JSON 就很好（原本 JSON 就是所有数据格式中最 human readable 的），每个服务自己维护自己的解析和参数验证。

Protobuf 一般是涉及到多个服务之间的数据交换，且每个服务内部用的数据要求用一致的 schema，这种大部分都不是 Web 项目，一般都是用网络编程框架做的传统后端，非常依赖 RPC 调用的服务。这时用 Protobuf 或者 Thrift 就非常好了，因为其实 Protobuf、Thrift 都是提供了一种序列化结构数据的方法，然后提供了一种用于描述结构数据的语法规则，在这个基础上其实已经把 data format 给抽象不见了，我们不需要知道它底下序列化后的二进制数据长什么样子，我们只关心每个使用同一份 proto 定义的服务内部的数据都是对应一致的 schema，且可以无缝转移到另一个服务中使用（这个过程我们也不需要关心）。如果我选择 Protobuf 而非 JSON，必然是因为它在打通跨服务的数据一致性上的优点，而不是它相比 JSON 性能有何优势。

当然最终选择的时候还有个很关键的因素，就是整个大环境的技术选型，如果你所依赖的其他组件用 JSON 的较多，那么也不要刻意用 Protobuf 搞得大家都很麻烦。如果一个大型项目在一开始就用了 Protobuf 作为数据格式的约定，后期在数据一致性上可能出现很多麻烦就可以避免掉呢。

最后说点我使用 Protobuf 的经验，项目里的每个 proto 文件都会在最上面标注一个 version number，所有的 required 字段一经定下允许再更改，对 proto 文件的提交必须保证严格的 review，不能随便 merge 到 master，如果被多个项目需要甚至会把 proto 文件单独放到一个 git repo 里，在其他需要它的地方用 git submodule 引用。

P.S. 写完发现用了好多个「一致」，有点啰嗦，赶吃饭就先这样了…

「所有的 required 字段一经定下允许再更改」→「所有的 required 字段一经定下 **不允许** 再更改」orz

@dcoder

用 precompile 来应对 IOS 的 AOT 问题
我是参考的这个帖子： http://game.ceeger.com/forum/read.php?tid=13479

我直接写一个 命令行工具来做这些事情： https://github.com/yueyoum/pg