Managed Service for Apache Kafka 是一项 Google Cloud 服务，可帮助您运行安全且可伸缩的开放源代码 Apache Kafka 集群。本页面简要介绍了该服务可为您自动执行哪些操作以及简化哪些流程。如需详细了解 Apache Kafka，请参阅 Apache Kafka 网站。
简单的容量调整和伸缩
如需调整 Managed Service for Apache Kafka 集群的大小或扩缩集群，您只需设置集群的总 vCPU 数量和 RAM 大小。代理（包括存储）的管理完全自动化。为了满足客户的需求，您可以监控 vCPU 和其他资源利用率，并根据需要向上或向下调整。
设置 vCPU 数量和 RAM 大小时，该服务会自动调整代理大小并进行预配。如果增加集群规模需要添加新的代理，该服务可以自动在代理之间重新平衡分区。
代理配置
当您为集群配置总 vCPU 和 RAM 大小时，该服务会预配新代理并扩缩现有代理。对于典型的集群配置，vCPU 和 RAM 总大小会在所有代理之间平均分配。这意味着允许每个代理使用部分 vCPU，但每个代理至少需要一个 vCPU。所有集群都分布在三个可用区内。这意味着每个集群至少需要 3 个 vCPU 和 3 GiB 的 RAM。
随着集群规模的扩大，代理会纵向扩缩，每个代理最多可扩缩到 15 个 vCPU。达到此限制后，该服务会创建新的代理。当您减小集群大小时，现有代理会缩减为单个 vCPU，但不会被删除。
最大代理规模可能会随时发生变化。 之所以选择此限制，是为了保持代理吞吐量与 vCPU 数量的线性伸缩。
缩放算法
broker 的数量取决于集群的总 vCPU 或内存容量。伸缩比率为每 15 个 vCPU 或 120 gibibytes (GiB) 的资源对应 1 个代理，以产生更多代理的比率为准。vCPU 与内存的比率（vCPU:GiB）必须介于 1:1 到 1:8 之间。代理均匀分布在 3 个可用区中，最大差值为 1。
例如，如果您配置了一个具有 70 个 vCPU 和 130 GiB RAM 的集群，并将复制因子设置为 3，则可以通过以下计算确定代理的数量：
计算需要多少代理才能满足 vCPU 需求：
ceiling(70 vCPUs / 15 vCPUs)= 5 个代理计算所需的代理数量（考虑内存）：
ceiling(130 GiB / 120 GiB)= 2 个代理
在此方案中，集群有 5 个代理，因为代理的数量由 vCPU 的数量决定。3 个可用区中有 2 个各分配了 2 个代理，最后一个可用区分配了 1 个代理。
存储管理
存储空间管理是自动化的。在大多数情况下，您需要负责设置各个主题的保留时间，以控制费用或满足数据保留政策的要求。您无需预配和管理永久性磁盘。
该服务依赖于分层存储 (KIP-405)。分层存储将附加到代理的预配置永久性磁盘卷与近乎无限的对象存储相结合。
该服务会为每个 vCPU 分配至少 100 GiB 的 SSD 永久性磁盘，以平衡性能、可用性和费用。系统会按每个 vCPU 100 GiB 的标准向您收取费用，不过每个代理的实际磁盘大小可能会超过此值。即使集群缩减，每个代理的磁盘大小也永远不会减少。
每个分区领导者都会在这些持久性磁盘上的段文件中缓冲消息。在滚动某个段后，该段会移至由地区 Cloud Storage 提供支持的永久性对象存储。这些段文件的大小由 log.roll.ms 和 log.segment.bytes 设置决定。
虽然这些详细信息有助于您了解存储空间，但存储空间是由该服务管理的。具体配置（例如每个 vCPU 的永久性磁盘容量）是可能会发生变化的实现细节。您无法直接访问用于持久存储的 Cloud Storage 存储分区。
重新均衡
为了使新配置的代理在维持性能方面发挥作用，必须将现有代理的部分流量转移到这些新机器上。为简化此流程，您可以启用自动重新平衡功能。
启用自动重新平衡后，当预配新代理时，服务会自动重新平衡现有代理中的分区。分层存储模型可验证，只需将相对较少量的数据复制到新代理，即可加快重新平衡速度。
重新平衡算法基于分区数量。 它不会考虑每个分区实际服务的流量。
灵活的网络
该服务可让您安全地从任何 VPC 访问集群。这包括来自多个 VPC、项目和区域的访问。
如需为集群配置网络，您需要提供集群可访问的子网集。该服务会为每个子网中的引导服务器和代理预配专用 IP 地址。它还会为每个 IP 地址设置带有网址的专用 Cloud DNS。引导服务器具有负载平衡器，因此每个集群都有一个引导网址。所有 VPC 中的网址都相同，因此客户端配置在不同环境之间可以保持一致。
这种灵活性得益于 Private Service Connect (PSC)。为集群分配的每个 IP 地址都需要一个 PSC 端点。系统会自动配置端点。
保护集群
该服务提供以下集群安全功能：身份验证、授权、加密、修补和资源隔离。它还禁止未经身份验证和未加密的连接和存储。
身份验证
该服务支持两种身份验证方法：简单身份验证和安全层 (SASL) 以及双向 TLS (mTLS)。mTLS 身份验证适用于 2025 年 6 月 24 日之后创建的集群。与受管集群的所有连接都使用 SASL 或使用 mTLS 的客户端证书通过 IAM 身份进行身份验证。使用 SASL 时，支持将真人账号、服务账号和联合账号作为主账号。
该服务不支持其他协议，包括 SASL/GSSAPI、SASL/SCRAM-SHA-256 和 SASL/SCRAM-SHA-512。该服务也不允许未经身份验证的连接。
授权
该服务采用分层授权方法。IAM 控制集群管理操作，例如创建、更新和删除资源。经过身份验证的主账号的授权取决于所用的方法：
SASL：使用 IAM 的主账号通过Google Cloud IAM 角色绑定或集群上的 Kafka ACL 获得授权。如需了解详情，请参阅配置 SASL 身份验证。
mTLS：通过 mTLS 进行身份验证的正文通过 Kafka ACL 获得授权。如需了解详情，请参阅配置 mTLS 身份验证。
您可以使用 Google Cloud 工具或第三方 Kafka 工具管理 Kafka ACL。 如需详细了解如何配置 IAM 和 Kafka ACL，请参阅使用 IAM 和 Kafka ACL 进行访问权限控制。
加密
必须进行加密。与集群的所有连接都必须使用 TLS。代理提供的 TLS 证书由 Public Certificate Authority 机构签名。存储的数据始终会加密。选择是使用 Google 管理的加密密钥还是客户管理的加密密钥 (CMEK) 来加密静态数据。
修补
服务团队会跟踪在开源代码中发现的安全漏洞。当该服务发现漏洞时，会自动为集群打补丁。
资源隔离
该服务的另一项安全功能是资源隔离。托管服务会在租户项目中部署集群，这些集群位于无法通过公共 IP 地址访问的专用 VPC 中。您的每个项目都有一个专用租户项目，其中包含一个专用服务代理账号。这有助于限制授予服务的访问权限范围。
架构注册表
为了简化提供方和使用方之间的协调，Managed Service for Apache Kafka 包含一个架构注册表 API。由服务提供的注册表充当在应用之间共享的架构的存储库。
该服务实现了 Confluent Schema Registry REST API，有助于与现有 Kafka 应用集成。支持 Apache Avro 和 Protocol Buffer (Protobuf) 架构格式。不支持 JSON。
Managed Service for Apache Kafka 还提供用于管理架构注册表和架构的管理 API 和工具集。该工具集包括Google Cloud 控制台、gcloud CLI 和客户端库。
如需详细了解架构注册表，请参阅架构注册表概览。
使用 Kafka Connect 进行数据集成
Managed Service for Apache Kafka 通过 Kafka Connect 简化了数据集成。Kafka Connect 提供了多个托管在 Connect 集群中的内置连接器插件。这些连接器用于迁移、备份、灾难恢复、高可用性和数据集成。借助这些连接器，您可以将 Managed Service for Apache Kafka 集群连接到各种系统，包括其他 Kafka 部署和 Google Cloud 服务（如 BigQuery、Cloud Storage 和 Pub/Sub）。 Kafka Connect 可提供可伸缩的可靠数据集成，同时降低运营开销并集成监控和日志记录功能。
如需详细了解 Kafka Connect，请参阅 Kafka Connect 概览。
高可用性集群
该服务的目标是为任务关键型应用提供区域级集群。具体而言，该服务可保护您免受单个可用区或代理故障的影响。
为此，所有集群都以支持机架的三可用区配置进行预配。默认主题配置至少需要三个副本。 机架感知功能可确保在不同可用区中创建副本。默认的同步副本数下限为 2。这意味着，您的集群可以容忍可用区或代理完全丢失。
如果 broker 因软件、硬件或网络故障而发生故障，系统会自动替换该 broker。当该服务检测到代理失败时，它会自动重启代理，必要时会在另一台机器上重启。代理可用后，Apache Kafka 会将该代理集成到集群中。如果整个可用区都发生故障，可能无法创建新的代理。 不过，只要其他两个可用区保持可用，集群就会继续运行。
除了这些特定功能之外，越来越多的内部工具和流程会主动维护服务、Apache Kafka 代码和更新的健康状况。数据和元数据备份在多个级别进行维护，使服务能够从许多人为错误和软件故障中恢复。
该服务无法防范区域或双可用区故障。对于需要此级别保护的应用，我们建议运行两个单独的地区级集群。您可以使用 Kafka Connect 中的 MirrorMaker 2.0 等工具在两个集群之间同步数据。
适合您管理风格的工具
该服务旨在提供一套完整的工具，以满足您的集群管理和问题排查需求。这包括用于管理、监控和记录的工具。
Managed Service for Apache Kafka 以 Google Cloud API 的形式公开。这意味着您可以使用 REST 和 gRPC API 管理集群和集群资源。这些 API 提供多个客户端和接口，包括
- 如果您偏好使用基础设施即代码方法，则可以使用 Terraform 提供程序。
- Google Cloud 控制台中的界面，用于在浏览器中进行互动式工作。
- 用于在 shell 中进行交互式工作的 gcloud CLI。
- Java、Python、Go 和其他语言版本的客户端库，用于自定义开发和脚本编写。
为了便于监控和问题排查，该服务会将指标导出到 Cloud Monitoring。部分指标可在服务界面中查看。 Cloud Monitoring 中提供了一套完整的指标，可用于交互式工作、配置提醒以及导出到其他系统。
该服务还会将代理日志导出到 Cloud Logging。这些日志可供搜索，并可用于创建基于日志的指标和提醒。
升级和补丁
Managed Service for Apache Kafka 集群在 Apache Kafka 版本 3.7.1 上运行。 该服务会自动修补严重的安全漏洞。
对底层基础架构（包括操作系统和编排层）的更新是持续且自动的。代理会通过滚动重启进行更新，不会导致集群停机。
该服务不会自动将代理上运行的 Apache Kafka 代码升级到新的次要版本。
透明的费用
Managed Service for Apache Kafka 的价格模式与您在 Compute Engine 上自行运行 Apache Kafka 时看到的费用类似。 您需要为预配的资源（vCPU、RAM 和本地存储）和消耗的资源（永久性存储和数据传输）付费。与自行设置类似系统相比，使用 Managed Service for Apache Kafka 时，永久性存储和 vCPU 的费用更高。相比之下，Managed Service for Apache Kafka 和自行管理的 Kafka 在数据传输和本地存储方面的价格相差不大。如需详细了解价格，请参阅 Managed Service for Apache Kafka 价格。
兼容，因为我们运行的是 Apache Kafka
最后，Managed Service for Apache Kafka 运行的开源软件与您可能已在环境中运行的软件相同。您无需更改应用代码即可将其迁移到该服务。
限制
Managed Service for Apache Kafka 具有以下限制：
每个集群在三个可用区中的资源必须相同。不支持单可用区或双可用区 Managed Service for Apache Kafka 集群。
您无法在创建集群时选择可用区。
您无法配置集群上的本地存储空间大小。
Managed Service for Apache Kafka 以 KRaft 模式运行。不支持 Zookeeper 模式。
不支持用于指标的 JMX API。
不支持使用
zstd进行主题压缩。compression.type支持的值包括lz4、gzip、snappy和uncompressed。虽然您可以随时使用
read-only更新模式更改代理配置，但这些更改只有在代理重新启动时才会生效。重启会定期发生，是 Google 维护和升级流程的一部分，但没有固定的时间表，也无法手动触发。因此，您无法控制这些更改何时生效。read-only配置的示例包括auto.create.topics.enable和background.threads。 使用cluster-wide更新模式（例如message.max.bytes）更新配置不需要重新启动，并且会立即生效。部分代理配置参数由服务管理，无法更新。这包括
broker.id和存储相关设置，例如remote.log.storage.system.enable。
后续步骤
- 创建 Managed Service for Apache Kafka 集群。
- 使用 Managed Service for Apache Kafka 集群发送和接收消息。
- 查看 Managed Service for Apache Kafka 限制。
- 了解 Managed Service for Apache Kafka 定价。