在 Pub-Sub 中发布和消费的最佳数据格式是什么？我正在查看 Avro 消息格式，因为它是二进制格式。 用例是实时微服务应用程序将 Avro 消息发布到 pub-sub。鉴于 avro 消息最适合批处理消息（以及附加二进制消息的模式）然后发布消息，那么对于涉及微服务的这个用例来说，这是否是一种更适合的格式？
【问题讨论】：
标签： google-cloud-platform google-cloud-messaging publish-subscribe google-cloud-pubsub
Google Cloud 文档包含一些 JSON 示例，但在寻找效率时，主要建议是使用 available client libraries，除非您的需求不能满足客户端库可以提供的功能，或者您在 Google App Engine standard environment 上运行，在在这种情况下，建议使用两个 API。
事实上，提高效率的最重要因素是使用 gRPC API 而不是 REST API（库的调用默认情况下会这样做）。如前所述here：
这里有两个主要因素在起作用：更高效的数据编码 和 HTTP/2。 gRPC 将数据以二进制形式保存在客户端内存和 通过构建在 HTTP/2 和协议缓冲区上进行连接。这消除了 字符串编码方案所需的处理和空间，例如 Base64 或 JSON。此外，HTTP/2 本身使事情变得更快 通过单个连接和标头压缩多路复用请求。
我没有在任何地方找到明确提及的数据格式。我建议您使用您喜欢的消息语言，例如 Python。 Client library description here 和 sample code here。
基于this * post，您可以通过以下方式有效地优化您的 PubSub 系统：
- 确保您使用的是 gRPC
- 尽可能进行批处理，以减少调用次数并消除延迟。
- 仅在需要时和基准测试之后进行压缩（意味着应用程序中的额外逻辑）
最后，如果您打算部署一个强大的 PubSub 系统，请查看on this Anusha Ramesh post。她现在是 Google 的项目经理，她提出并详细阐述了三个技巧：
- 不要低估容量规划的重要性。
- 确保您的发布/订阅系统具有容错能力。
- NSM：永不停止监控。
【讨论】：
对于用于所有用例的消息的最佳格式，没有一个正确答案。 Avro 无疑是一个受欢迎的选择。 Protocol buffers 是另一种可能性，Thrift 也是如此。对于 Pub/Sub，数据都只是字节，由发布者和订阅者决定对这些数据的解释。人们已经针对不同的数据格式运行了comparisons，因此您可能需要根据性能和消息大小方面的需求做出决定。
Pub/Sub 本身使用 defining its data types 的协议缓冲区。关于批处理，Cloud Pub/Sub client libraries 自己进行批处理以进行发布，因此您不必自己担心。您可以控制批处理设置以根据您的用例优化吞吐量和延迟，例如，在 Java 的 Publisher.Builder 中调用 setBatchSettings（其他语言也有等效项）。如果您想将一些元数据与一组消息而不是与每条单独的消息相关联，或者您对如何将消息批处理在一起有非常特定的需求，您可能会决定进行自己的批处理。否则，根据客户端库进行批处理可能是正确的决定。
【讨论】：