任何人都可以解释何时在微服务架构中使用协议缓冲区而不是 JSON(反之亦然)吗?既适用于同步通信,也适用于异步通信。
当我们讨论这个问题时,你看过flatbuffers吗?
这里涵盖了一些方面google协议缓冲区与json与XML
参考:
https://codeclimate.com/blog/choose-protocol-buffers/
https://codeburst.io/json-vs-protocol-buffers-vs-flatbuffers-a4247f8bda6f
当消费者使用或可能使用内置对 JSON 的本机支持的语言(Javascript 就是一个例子)、Web 浏览器或需要人类可读性的语言编写时,我会使用 JSON。 说到这里,至少对于异步调用,许多开发人员享受直接检查队列内容以进行调试甚至在正常开发过程中的便利。根据所使用的技术堆栈,仅仅为了减少网络负载而使用 protobuf 可能值得也可能不值得,因为在异步世界中任何性能提升都不会给你带来太多好处。 我们不再需要像以前在大多数语言中使用 JSON 编组和解组那样编写一堆样板代码。
我会使用 protobuf 来做其他事情……如果考虑到上述考虑还有其他用例的话。您可能会看到一些优点,例如性能、网络负载、版本控制方案提供的向后兼容性、原始文件神奇地附带的可爱文档以及一些验证!如果由于某种原因,您在微服务之间有大量 REST 或其他同步调用,则可以通过线路发送 protobuf 而不是 JSON,无需太多权衡(如果有的话),同时提供大量优势。
JSON(使用 OpenAPI)与 Protobuf(使用 GRPC)的一般优势是 JSON 具有更丰富的模式定义。 (例如正则表达式模式、最小值、最大值等等。)
JSON 的主要问题是工具。 OpenAPI Generator 提供了一个为数据生成存根的工具。 还有 Swagger CodeGen 但在我看来它们在文档和支持方面非常糟糕。
使用 Protobuf(加上 GRPC),您可以获得更小的网络占用空间和为您生成的高性能服务器实现。 但是,.proto 文件在架构定义方面没有太多内容。 它是一种用于机器到机器的二进制数据传输协议。即使它可以通过 HTTP 作为二进制发送,它也只会增加复杂性,因为您需要专门的工具来调试它。
在微服务架构中,我将使用 JSON 进行以下操作:
我会使用 Protobuf + GRPC