Protocol Buffer 与 Json - 何时选择其中之一？

Question

任何人都可以解释何时在微服务架构中使用协议缓冲区而不是 JSON（反之亦然）吗？既适用于同步通信，也适用于异步通信。

Answer 1

何时使用 JSON

• 您需要或希望数据可供人类阅读
• 来自服务的数据直接由网络浏览器使用
• 您的服务器端应用程序是用 JavaScript 编写的
• 您还没有准备好将数据模型与模式联系起来
• 您没有足够的带宽向您的武器库中添加其他工具
• 运行不同类型的网络服务的运营负担 太厉害了

ProtoBuf 的优点

• 尺寸相对较小
• 保证类型安全
• 防止架构违规
• 为您提供简单的访问器
• 快速序列化/反序列化
• 向后兼容性

当我们讨论这个问题时，你看过flatbuffers吗？

这里涵盖了一些方面google协议缓冲区与json与XML

参考：

https://codeclimate.com/blog/choose-protocol-buffers/

https://codeburst.io/json-vs-protocol-buffers-vs-flatbuffers-a4247f8bda6f

Answer 2

当消费者使用或可能使用内置对 JSON 的本机支持的语言（Javascript 就是一个例子）、Web 浏览器或需要人类可读性的语言编写时，我会使用 JSON。 说到这里，至少对于异步调用，许多开发人员享受直接检查队列内容以进行调试甚至在正常开发过程中的便利。根据所使用的技术堆栈，仅仅为了减少网络负载而使用 protobuf 可能值得也可能不值得，因为在异步世界中任何性能提升都不会给你带来太多好处。 我们不再需要像以前在大多数语言中使用 JSON 编组和解组那样编写一堆样板代码。

我会使用 protobuf 来做其他事情……如果考虑到上述考虑还有其他用例的话。您可能会看到一些优点，例如性能、网络负载、版本控制方案提供的向后兼容性、原始文件神奇地附带的可爱文档以及一些验证！如果由于某种原因，您在微服务之间有大量 REST 或其他同步调用，则可以通过线路发送 protobuf 而不是 JSON，无需太多权衡（如果有的话），同时提供大量优势。

Answer 3

JSON（使用 OpenAPI）与 Protobuf（使用 GRPC）的一般优势是 JSON 具有更丰富的模式定义。 （例如正则表达式模式、最小值、最大值等等。）

JSON 的主要问题是工具。 OpenAPI Generator 提供了一个为数据生成存根的工具。 还有 Swagger CodeGen 但在我看来它们在文档和支持方面非常糟糕。

使用 Protobuf（加上 GRPC），您可以获得更小的网络占用空间和为您生成的高性能服务器实现。 但是，.proto 文件在架构定义方面没有太多内容。 它是一种用于机器到机器的二进制数据传输协议。即使它可以通过 HTTP 作为二进制发送，它也只会增加复杂性，因为您需要专门的工具来调试它。

在微服务架构中，我将使用 JSON 进行以下操作：

1. 任何外出的事情（即 HTTP 请求/响应）
2. 数据存储在 Kafka 中（使调试更容易）
3. 存储在 MySQL 中的数据（具有 JSON 数据类型）
4. （泛化查看数据并将其保存到磁盘的任何位置）

我会使用 Protobuf + GRPC

1. 远程过程调用。 这样就不必运行完整的 HTTP 堆栈，GRPC 服务器要轻得多。
2. 值存储在Redis中。 这主要是因为 Redis 将所有数据存储在内存中，因此最好使其尽可能小。 我强调了values，因为最好还是保持keys可读。 但这是在您需要多种语言来阅读数据的情况下。 否则，请使用您拥有的最快的序列化机制。