从 Kafka 迁移到 Pub/Sub

如果您正在考虑从自行管理的 Apache Kafka 迁移到 Pub/Sub，那么本文档非常有用，因为它可以帮助您查看并考虑功能、价格和用例。每个部分都标识了一个常见的 Kafka 使用场景，并提供了有关如何在 Pub/Sub 中实现相同功能的实用指南。

Pub/Sub 概览

Pub/Sub 是一种异步消息传递服务。Pub/Sub 可将产生事件的服务与处理事件的服务分离开。您可以将 Pub/Sub 用作面向消息传递的中间件或流式分析流水线的事件提取和传送。在这两种场景中，发布者应用都会创建消息并将消息发送到主题。订阅者应用创建对主题的订阅以便从其接收消息。订阅是一个代表有兴趣接收特定主题的消息的命名实体。

Pub/Sub 在所有 Google Cloud 区域中运行。Pub/Sub 将发布者流量定向到允许存储数据的最近 Google Cloud 数据中心，如资源位置限制政策中定义。

Pub/Sub 可与多种 Google Cloud 服务集成，例如 Dataflow、Cloud Storage 和 Cloud Run。您可以将这些服务配置为可以将消息发布到 Pub/Sub 的数据源，或者作为可以从 Pub/Sub 接收消息的数据接收器。

Kafka 概览

Apache Kafka 是一个开源的分布式事件流处理平台，支持应用发布、订阅、存储和处理事件流。Kafka 服务器以机器集群的形式运行，客户端应用会与之进行交互以读取、写入和处理事件。您可以使用 Kafka 分离应用、发送和接收消息、跟踪活动、聚合日志数据和进程流。

在 Kafka 集群中，系统会将某些节点指定为代理。代理从生产方接收消息并将其存储在磁盘上。存储消息按主题进行整理，并对集群中的多个不同代理进行分区。发布到主题的新事件将附加到该主题的分区的末尾。然后，消费者可以从代理获取消息，这些消息可从磁盘读取并发送至消费者。

了解 Kafka 与 Pub/Sub 之间的区别

下图展示了 Kafka 和 Pub/Sub 扩缩策略之间的差异：

扩缩策略，具有 Kafka 的分区，没有 Pub/Sub 分区。

在上图中，每个 M 代表一条消息。Kafka 代理管理着多个有序消息分区，由消息的水平行表示。消费者从特定分区读取消息，该分区的容量取决于托管该分区的机器。Pub/Sub 没有分区，而是由消费者从根据需求自动扩缩的主题中读取。您可以为每个 Kafka 主题配置处理预期消费者负载所需的分区数。Pub/Sub 会根据需求自动扩缩。

特性比较

下表比较了 Apache Kafka 功能和 Pub/Sub 功能：

Apache Kafka Pub/Sub
消息排序 是，在分区内 是，在主题内
消息去重 是 是，使用 Dataflow
推送订阅 否 是
死信队列
（无法处理的消息队列）		 从 2.0 版开始 是
事务 是 否
消息存储容量 仅受可用机器存储空间限制 31 天。
一个主题最多可以将已发布的消息（包括已确认的消息）保留 31 天。这可以通过主题的 `message_retention_duration` 属性进行配置。
重放消息 是 是
市行政区 本地集群可以使用 MirrorMaker 进行复制 具有可配置的消息存储位置的全球分布式服务
日志记录和监控 自行管理 使用 Cloud Logging 和 Cloud Monitoring 自动执行
流处理 是，使用 KSQL 是，使用 Dataflow

了解 Pub/Sub 消息存储和重放

默认情况下，Pub/Sub 会将未确认的消息保留最多 7 天，但您可以配置 Pub/Sub 订阅以保留已确认的消息最长 7 天，具体取决于订阅中最早的消息（已确认或未确认）的存在时间。通过保留已确认的消息，您可以基于时间戳重放其中部分或全部消息。当您根据时间戳重放消息时，时间戳之后收到的所有消息都将标记为未确认。未确认的消息将被重新提交。

您可以根据需要为个别订阅创建快照，而无需提前配置订阅。例如，您可以在部署新订阅者代码时创建快照，因为您可能需要从意外或错误的确认中恢复。

采用死信主题的内置故障安全机制

Pub/Sub 提供类似于 Kafka 2.0 错误处理以及 Kafka Connect 如何处理死信主题的功能。如要通知 Pub/Sub 消息已成功传递，Pub/Sub 主题的订阅者可以确认其接收和处理的消息。如果订阅者在一段时间内无法处理消息，Pub/Sub 可以自动将消息转发到死信主题，并存储起来以供日后访问。您可以配置 Pub/Sub 传送消息的尝试次数，然后再将消息发送到死信主题。

使用 Dataflow 在 Pub/Sub 中删除重复消息。

Pub/Sub 会为每个订阅将发布的每条消息至少传送一次。一般来说，如果要实施多次传送，订阅者需要在处理消息时遵循幂等原则。如果现有订阅者无法以幂等的方式运行，您可以添加 Dataflow 来删除重复的消息。 如果订阅者看到大量重复消息，这可能表明他们没有正确确认消息，或您的确认时限过短。

Pub/Sub 中的消息排序

如果您的 Kafka 订阅者应用依赖于消息排序，您可以在使用排序键时在 Pub/Sub 中支持此要求。目前，对于在指定区域中发布的消息，排序得到保证。为了充分利用消息排序功能，请确保您的发布者和订阅者使用位置端点将您的消息路由到正确的区域。

了解自行管理服务和托管式服务的责任

下表比较了通过 Kafka 自行托管的功能以及由 Google 使用 Pub/Sub 管理的功能：

Apache Kafka Pub/Sub
可用情况 手动将 Kafka 部署到其他位置 在所有 Google Cloud 区域中部署，以实现高可用性和低延迟
灾难恢复 设计和维护您自己的备份和复制 由 Google 管理
基础架构管理 手动部署和运行虚拟机 (VM) 或机器。您必须保持版本控制和补丁程序的一致。 由 Google 管理
容量规划 提前手动规划存储和计算需求 由 Google 管理
支持 无 全天候客服人员和支持

Pub/Sub 消息大小限制和解决方法

Kafka 和 Pub/Sub 在处理大量小消息时性能都很好。Kafka 对消息大小没有硬性限制，您可以配置允许的消息大小，而 Pub/Sub 限制消息限制为 10 MB。首先，您可以通过将对象存储在 Cloud Storage 来间接发送较大的载荷，如下图所示：

发布者将对象存储在 Cloud Storage 中。

上图显示，当发布者将对象存储在 Cloud Storage 中时，它会发布一条包含该存储对象网址的消息。当订阅者收到包含该网址的消息后，它将从 Cloud Storage 下载此文件，并继续照常处理。

Kafka 和 Pub/Sub 费用比较

Pub/Sub 中的预估和管理费用与 Kafka 中采用的方式不同。本地或云端的 Kafka 集群的费用包括机器、磁盘、网络、入站和出站消息的费用，以及管理和维护这些系统及其相关基础架构的开销费用。管理 Kafka 集群时，通常需要经常升级和修补机器，需经常规划集群容量，并且实施灾难恢复需要大规模规划和测试。您需要推断和汇总所有这些费用，以确定您的真实总拥有成本 (TCO)。

Pub/Sub 价格包括发布者和订阅者的数据转移，以及临时存储的未确认消息的费用。您只需为您消耗的资源付费，根据您的应用和预算的要求自动调整其容量。

可靠性设计架构

Pub/Sub 是一项可在所有 Google Cloud 区域中运行的全球托管式服务。Pub/Sub 主题是全球性的，这意味着可从任何 Google Cloud 位置查看和访问这些主题。但是，任何给定消息都存储在一个距离发布者最近且资源位置存储政策允许的 Google Cloud 地区中。因此，主题可能会将消息存储在整个 Google Cloud 的不同地区中。Pub/Sub 可防范地区服务中断。在区域服务中断期间，在服务恢复之前，可能无法访问存储在该特定区域中的消息。根据您的可用性要求，您可以使用位置信息服务端点在发生地区性服务中断时实施故障切换政策。

安全和身份验证

Apache Kafka 支持多种身份验证机制，包括基于客户端证书的身份验证、Kerberos、LDAP 以及用户名和密码。在授权中，Kafka 支持使用访问控制列表 (ACL) 来确定哪些提供方和消费者可以访问哪些主题。

Pub/Sub 支持对 Google Cloud 用户账号和服务账号进行身份验证。对 Pub/Sub 主题和订阅的精细访问权限控制受 Google Cloud 中的 Identify and Access Management (IAM) 约束。使用用户账号时，Pub/Sub 操作速率受限。如果您需要执行大量事务，则可以使用服务账号与 Pub/Sub 进行交互。

计划迁移到 Pub/Sub

向 Google Cloud 的任何迁移始于评估您的工作负载和构建基础。

使用 Pub/Sub Kafka 连接器分阶段迁移

通过 Pub/Sub Kafka 连接器，您可分阶段将 Kafka 基础架构迁移到 Pub/Sub。

您可以配置 Pub/Sub 连接器，将特定主题的所有消息从 Kafka 转发到 Pub/Sub。然后，您可以更新单个订阅者应用以从 Pub/Sub 接收这些主题的消息，而发布者应用继续将消息发布到 Kafka。此阶段式方法允许您以迭代方式更新、测试和监控订阅者应用，从而最大限度地降低错误和停机时间的风险。

这个部分包括两个图表，它们分两个不同的阶段为您直观呈现这个过程。下图显示了迁移阶段的配置：

迁移的第一阶段。

在上图中，当前订阅者将继续接收来自 Kafka 的消息，并且您可以逐个更新订阅者以从 Pub/Sub 接收消息。

将特定主题的所有订阅者更新为接收来自 Pub/Sub 的消息后，您可以更新该主题的发布者应用以将消息发布到 Pub/Sub。然后，您可以端对端测试和监视消息流，以验证设置。

下图显示了在所有订阅者从 Pub/Sub 接收消息之后的配置：

迁移的第二阶段。

随着时间的推移，您的所有发布者都将更新为直接发布到 Pub/Sub，然后您的迁移即告完成。许多团队使用此方法来并行更新其应用。Kafka 可以根据需要与 Pub/Sub 共存，以确保成功迁移。

监控 Pub/Sub

在从 Kafka 迁移到 Pub/Sub 的过程中和之后，监控应用非常重要。Pub/Sub 使用 Cloud Monitoring 导出指标，从而帮助您了解应用的性能、正常运行时间和整体运行状况。例如，您可以监控未传送消息的数量，确保您的订阅者能够及时了解消息流。如要监控未发送的消息，您可以在最久远的未确认消息的时间戳超过特定阈值时创建提醒。此外，您还可以通过监控发送请求计数指标和检查响应代码来监控 Pub/Sub 服务本身的运行状况。

后续步骤