目录
Google Cloud Pub/Sub 是一种消息队列和数据摄取解决方案，适用于事件驱动系统和流式分析。它是完全托管的，并允许独立应用程序使用发布者/订阅者架构进行异步通信。应用程序将消息发送到 Pub/Sub 服务，其他应用程序可以订阅主题以接收相关消息。Google Cloud Pub/Sub 在 Google Compute Engine 实例中运行良好，可以高效地分发大量数据集。
什么是 Pub/Sub？
发布/订阅 (pub/sub) 消息传递是一种异步消息传递模式，其中消息的发布者不直接向接收者发送消息，而是发送可由其他设备订阅的分类消息，而无需发布者知晓。
Pub/sub 允许发送者和接收者解耦，这可以简化应用程序的设计和实施。使用 pub/sub，订阅者或发布者都不需要了解对方。
pub/sub 消息传递架构通常由三个组件组成：发布者、代理和订阅者。发布者将消息发送到代理，代理又将消息分发给所有当前连接的订阅者。这允许横向扩展，因为随着订阅者的增加，代理可以处理分发更多消息，而不会影响发布者。
Pub/Sub 消息传递的优势
灵活性
借助 Pub/Sub 消息传递架构，开发人员可以通过将消息发送到中央消息代理来解耦其应用程序。这可以更轻松地开发和测试新应用程序，以及修改现有应用程序。
pub/sub 代理通常支持 HTTP 之外的多种不同通信协议。它们还使向系统添加新服务变得容易，因为这些服务只需订阅它们需要信息的Topic，而无需直接了解发布者。
性能和效率
Pub/Sub 消息传递可以帮助减少需要在应用程序不同部分之间发送的消息数量，从而提高性能。
pub/sub 架构可以通过多种方式使应用程序更高效且性能更高。Pub/sub 可以消除轮询设备以进行监控类型工作负载的需求，这将减少受监控设备上的负载，并减少不必要的轮询请求上的带宽使用。Pub/sub 还允许应用程序的不同部分独立扩展或缩减，从而使其更具成本效益。
可靠性
Pub/Sub 消息传递架构可以通过修改消息代理配置来帮助确保消息可靠传递。
可扩展性
发布-订阅系统具有高度可扩展性，因为它可以轻松容纳大量发布者和订阅者，而不会影响性能。如果消息量很大，消息代理可以充当订阅者的负载均衡器或速率限制器，方法是保留消息直到订阅者可以赶上。
pub/sub 应用程序也可以独立扩展各个部分。可以复制代理以处理更多消息吞吐量，可以将一些用于过滤消息的逻辑放入代理中，而不是将无用的消息发送给订阅者。如果需要，订阅者也可以独立于代理进行扩展。
使用 Pub/Sub 消息传递的挑战
延迟
如果订阅者需要在很短的时间内接收消息，则延迟可能会成为 pub/sub 应用程序的主要问题。从发布者到代理，然后再到订阅者的额外网络跃点对于某些用例来说可能开销过大。当消息代理接收到大量请求时，尤其如此。
复杂性
对于简单的应用程序，添加需要管理的代理以及与异步消息传递相关的潜在问题的额外复杂性可能不值得 pub/sub 架构提供的优势。
消息传递保证
pub/sub 架构的常见问题可能与消息如何传递给订阅者有关。消息的传递顺序可能与消息的创建时间顺序不符，如果这是一个问题，则必须在应用程序代码中加以考虑。
消息也可能多次发送到同一订阅者，并且代理可能会在传递消息之前发生故障。
大多数 pub/sub 代理都具有处理上述问题的功能，但它们会对系统性能产生影响。一般来说，您希望消息顺序和传递的保证越多，应用程序的性能就越慢。
Pub/Sub 架构组件
发布者
发布者是发布/订阅系统中生成消息的组件。根据架构，发布者可以将消息直接发送给订阅者，也可以将消息发送给专用消息代理。
订阅者
订阅者是 pub/sub 系统中接收来自发布者消息的组件。在大多数情况下，订阅者必须显式订阅他们感兴趣的Topic才能接收消息。一旦收到消息，订阅者就可以根据消息中包含的数据采取行动，并可能通过发回消息来充当发布者本身。
代理
pub/sub 代理是通过接收和发送发布者和订阅者之间的消息来在它们之间进行调解的组件。
使用代理的价值在于它可以提供以下功能：
- 通过持久化消息实现冗余
- 过滤和路由消息
- 速率限制
- 为消息提供不同级别的传递保证
主题
Topic是用于定义发布/订阅系统中可用消息通道的标签，发布者和订阅者可以发布和订阅该通道。
Topic通常组织成层次结构，层次结构的每个级别代表更具体的Topic。
消息
消息是在发布者和订阅者之间交换的信息单元。消息与特定的Topic关联，并且可以包含任何类型的信息。
可以为某些用例强制执行消息的已定义数据结构，以确保接收消息的订阅者的格式标准化。
Pub/Sub 关键概念
松耦合
pub/sub 设计模式的一个关键部分是发布者和订阅者彼此解耦。这意味着发布者不需要知道谁订阅了其消息，而订阅者也不需要知道发布者是谁。随着发布者和订阅者数量的增长，这种松耦合允许更大的灵活性和可扩展性。
异步通信
发布者和订阅者之间的通信是异步的。这意味着发布者可以发送消息，而无需等待订阅者的响应，反之亦然。异步通信允许更高的效率，因为发布者和订阅者都可以在发送和接收消息时继续工作。
消息过滤
使用 pub/sub，可以过滤消息，以便只有对特定消息感兴趣的订阅者才会收到它。如果为任务配置，代理还可以读取和过滤消息，具体取决于消息的内容。消息过滤可以帮助减少混乱，并确保订阅者仅接收他们感兴趣的信息。
消息路由
消息可以根据某些标准路由到不同的订阅者。例如，消息可以根据消息的Topic或订阅者的位置进行路由。这有助于确保消息传递给最相关的订阅者。
容错
由于 pub/sub 架构的不同部分如上所述是松耦合的，因此有效地内置了容错。处理发布者和订阅者之间通信的代理可以复制以实现可用性，并为消息提供持久性。例如，如果订阅设备因某种原因而关闭，则代理可以保存消息的副本，直到设备重新联机，然后再传递消息。其他设备不需要知道彼此的状态，因为代理会处理这些事情。
Pub/Sub 用例
应用程序消息传递和通知
发布-订阅架构最常见的用例之一是消息传递。使用这种类型的系统，可以将消息发送到大量订阅者，而无需每个订阅者不断轮询新消息。这在各种场景中都很有用，例如向用户发送警报或通知。这种类型的消息传递也可以在内部用于应用程序后端的服务之间的通信。
数据流
发布-订阅架构的另一个常见用例是数据流。使用这种类型的系统，可以将数据流式传输到大量订阅者。这在需要尽快将数据传递给用户的场景中非常有用，例如实时更新或股票价格的情况。
地理位置跟踪
发布-订阅架构也可用于地理位置跟踪。可以实时跟踪资产位置，并且可以在资产进入或离开特定区域时通知订阅者，例如。
物联网应用
发布-订阅架构也可用于 IoT 应用程序。使用 pub/sub 传感器可以将数据实时流式传输到订阅者，这在各种场景中都很有用，例如监控环境或跟踪机器的状态。如果设备发送的值超过某个阈值，则订阅者可以发回一条包含数据的消息，告诉设备关闭或采取其他操作。
事件驱动架构
事件驱动架构 (EDA) 是一种消息传递模式，其中服务通过生成和消费事件来相互通信。这种类型的架构通常用于需要高水平可扩展性和可靠性的应用程序中，例如金融交易系统和社交媒体平台。
Pub/Sub 非常适合事件驱动架构，因为它使服务能够生成和消费事件，而无需显式连接到彼此。这有助于降低分布式系统的复杂性，使其更易于维护和扩展。这也使得将新服务或功能集成到系统中变得更容易，因为它们可以简单地订阅相关事件，而无需这些事件生产者知道新服务。
微服务架构
微服务架构是一种软件开发风格，其中应用程序构建为小型、独立服务的集合。
Pub/Sub 消息传递非常适合微服务，因为它允许服务在无需显式连接的情况下进行通信。这有助于降低管理系统的复杂性，因为服务可以发布和订阅事件，而无需了解系统中其他任何服务。
大数据分析
大数据分析是一个处理无法使用传统方法处理的大量数据的领域。
发布和订阅消息传递可以通过允许数据从多个来源实时流式传输来帮助进行大数据分析。这对于快速分析大量数据非常重要的场景非常有用，例如欺诈检测或预测分析。Pub/Sub 也可用于管理多步骤数据处理工作流程和并行处理大量数据。
为什么要使用 Google Cloud PubSub Push Telegraf 插件？
Google Cloud PubSub Push 输入插件侦听通过 HTTP POST 从 Google Cloud PubSub 发送的消息。Telegraf 充当 Google Pub/Sub“推送”服务的端点。Google 的 PubSub 服务通过 HTTPS/TLS 发送，因此此插件必须位于有效代理之后或配置为使用 TLS。
使用此 Telegraf 插件收集消息，您可以将消息与所有其他指标和事件数据（例如消息属性和订阅Topic）一起存储在 InfluxDB 中。
如何使用 Google Cloud PubSub Push Telegraf 插件
Google Cloud PubSub Push Telegraf 插件易于使用。首先，您需要为 PubSub Topic 创建一个 PUSH 订阅。然后，您可以选择适合您环境的配置选项（例如服务地址、令牌、超时和正文大小）。此外，您可以通过指定服务 TLS 证书和密钥的文件名来启用 TLS。您还可以通过在 tls_allowed_cacerts 中包含允许的 CA 证书文件名列表来启用相互身份验证的 TLS 并授权客户端连接。</p>
重要的是要注意，此插件仅期望使用 Google 的 Pub/Sub JSON 格式的消息。
要监控的关键 Google Cloud PubSub Push 指标
借助 Google Cloud PubSub Push，您可以在不同应用程序、应用程序监控、欺诈检测和实时排行榜之间流式传输数据。数据类型 Message 定义了 Google Pub/Sub 消息的结构，数据类型 Payload 是收到的 Google Pub/Sub 数据。
Pub/Sub 工具
Redis
Redis 是一种内存数据库，可用于 pub/sub 用例，例如实时消息传递、流式数据和地理位置跟踪。
Redis 快速、可靠且可扩展，并且具有广泛的功能来管理消息，例如消息确认、消息排序和消息传递保证。
Google Cloud Pubsub
Google Cloud Pubsub 是一项用于构建 pub/sub 消息传递系统的托管服务。它专注于事件流，用于执行以下任务：将数据移入数据仓库以进行分析、实时警报或通知，以及将数据流式传输到操作数据库。
Kafka
Apache Kafka 是一种开源分布式消息传递系统，专为高吞吐量和可扩展性而设计。这使得 Kafka 非常适合 pub/sub 应用程序，它通常用于事件驱动架构和流式数据应用程序。
Kafka 具有广泛的功能，例如消息确认、传递保证和可扩展性。它还支持推送和拉取消息传递模式，这使其成为 pub/sub 用例的多功能工具。
Pulsar
Apache Pulsar 是一种开源分布式 pub-sub 消息传递系统，最初由 Yahoo 创建，现在是 Apache 软件基金会的一部分。它专为高性能而设计，具有简单的 API、可扩展性、灵活性和可操作性。
Pulsar 提供两种类型的消息传递：排队（消息排序）和发布-订阅（消息广播给多个消费者）。它还支持数据流、消息重放和其他功能。该系统具有容错能力，能够检测节点故障并从中恢复。
MQTT
MQTT 是 IBM 为 IoT 用例设计的协议。该协议基于许多 pub/sub 概念，并依赖 MQTT 代理来处理设备之间传递消息。MQTT 非常重视持久性和传递保证，因为它专为在边缘计算环境中工作而设计，在边缘计算环境中，网络连接无法得到保证。
常见问题解答
Pub/Sub 与消息队列
尽管术语“发布/订阅”和“消息队列”经常被互换使用，但它们实际上指的是不同的技术。“发布/订阅”系统提供了一种应用程序通过主题进行通信的方式，多个服务可以订阅这些主题，而消息队列提供了一种应用程序通过发送到单个服务的单独消息进行通信的方式。
发布/订阅 vs 事件 Broker
发布/订阅是一种消息传递模式，其中发布者向订阅者发送消息。另一方面，事件 Broker 是一种软件应用程序，它充当两个或多个应用程序之间的中间人，通过接收、转换和路由来自一个系统到另一个系统的数据。
