本文档可帮助您在 Google Cloud 上设计弹性的单区域环境。如果您计划迁移单区域环境，或者正在评估未来迁移机会并希望了解潜在的情况，则本文档非常有用。
本文档是以下系列文章中的一篇：
- 开始
- 在 Google Cloud 上构建单区域环境（本文档）
- 准备数据和批量工作负载，以便跨区域进行迁移
本文档旨在提供有关如何在 Google Cloud 上设计弹性单区域环境的指导，并重点介绍以下架构组件：
- 网络服务，例如 Cloud Load Balancing。
- 计算服务，例如 Compute Engine、Google Kubernetes Engine (GKE)、Google Cloud VMware Engine 和 Cloud Run。
- 数据存储服务，例如 Cloud Storage、Filestore、Bigtable、Firestore、Memorystore 和 Spanner。
- 数据分析服务，例如 BigQuery、Pub/Sub、Dataproc 和 Dataflow。
- 您在环境中部署的工作负载。
本文档中的指导假设您设计和实现单区域环境。如果您现在使用单区域环境，将来可以迁移到多区域环境。如果您正考虑在未来迁移可用区和单区域环境并演变为多区域环境，请参阅跨 Google Cloud 区域迁移：使用入门。
不同部署原型的属性
Google Cloud 提供来自全球不同区域的服务。 每个区域都是物理上独立的地理区域，由多个称为“可用区”的部署区域组成。如需详细了解 Google Cloud 区域和可用区，请参阅地理位置和地点。
在设计 Google Cloud 环境时，您可以在以下部署原型之间进行选择，这些原型按增加可靠性和运营开销的顺序显示：
- 可用区级原型：在区域内的单个可用区中预配 Google Cloud 资源，并在可用的情况下使用可用区服务。如果可用区级服务不可用，则您可以使用区域级服务。
- 单区域原型：您可以在一个区域内的多个可用区中预配 Google Cloud 资源，并尽可能使用区域级服务。
- 多区域原型：您可以在不同区域的多个可用区中预配 Google Cloud 资源。可用区级资源在每个区域内的一个或多个可用区中预配。
上述部署原型具有不同的可靠性属性，您可以使用它们来提供您的环境所需的可靠性保证。例如，与单区域或可用区环境相比，多区域环境更有可能在单区域服务中断后继续存在。如需详细了解每个架构原型的可靠性属性，请参阅如何利用可用区和区域实现可靠性以及 Google Cloud 基础架构可靠性指南。
由于每个原型的成本和复杂性属性，基于这些部署原型设计、实现和操作环境需要不同的工作量。例如，与单区域或多区域环境相比，可用区环境可能更便宜，更易于设计、实现和操作。区域环境可能会降低工作量和成本，因为您必须尽力协调位于不同区域的工作负载、数据和流程的额外开销。
下表总结了每种架构原型的资源分布、可靠性属性和复杂性。表中还介绍了根据每种原型设计和实现环境所需的工作量。
| 架构原型名称 | 资源分布 | 帮助抵御 | 设计复杂性 |
|---|---|---|---|
| 可用区级环境 | 在单个可用区中 | 资源故障 | 需要在单个可用区内进行协调 |
| 单区域环境 | 单个区域中的多个可用区 | 资源故障、可用区服务中断 | 需要在单个区域内的多个可用区之间协调 |
| 多区域环境 | 跨多个区域，跨多个可用区 | 资源故障、可用区服务中断、区域服务中断、多区域服务中断 | 需要跨跨多个区域的多个可用区进行协调 |
为您的环境选择部署原型
如需选择最符合您需求的架构原型，请执行以下操作：
- 定义您要防范的故障模型。
- 评估部署原型以确定哪种需求最适合您的需求。
定义故障模型
如需定义故障模型，请考虑以下问题：
- 您的环境的哪些组件需要故障模型？故障模型可以应用于您在 Google Cloud 上预配或部署的任何内容。故障模型可以应用于个人，也可以将故障模型应用于整个可用区或区域中的所有资源。我们建议您将故障模型应用于为您提供价值的任何对象，例如工作负载、数据、流程和任何 Google Cloud 资源。
- 这些组件的高可用性、业务连续性和灾难恢复要求有哪些？您的环境的每个组件可能都有自己的服务等级目标 (SLO)，用于定义该组件可接受的服务级别及其自己的灾难恢复要求。例如，Compute Engine SLA 表明，如果您需要实现超过 99.5% 的每月正常运行时间，则需要在单个区域的多个可用区中预配实例。 如需了解更多信息，请参阅灾难恢复计划指南。
- 您需要定义多少个故障模型？在典型环境中，并非所有组件都必须提供相同的可靠性保证。如果您提供更高的正常运行时间和更强的弹性，您通常需要投入更多精力和资源。定义故障模型时，我们建议您考虑一种方法，为每个组件定义多个故障模型，而不仅仅是为所有组件定义一个。例如，业务关键型工作负载通常需要提供更高的可靠性，但可以为其他不太重要的工作负载提供较低的可靠性保证。
- 故障模型需要多少个资源来防范故障？为了防止您定义的故障模型，您可以消耗资源（例如人员设计、预配并配置保护机制和自动化流程所需的时间和费用）。我们建议您评估需要保护定义的每个故障模型的资源数量。
- 如何检测是否发生了故障？能够检测到故障正在发生或即将发生至关重要，因此您可以开始缓解、恢复和协调流程。例如，您可以配置 Google Cloud Observability，以提醒您性能下降的情况。
- 如何测试您定义的故障模型？定义故障模型时，我们建议您考虑如何持续测试每个模型，以验证各个模型是否能够有效防范模型预期的故障。例如，您可以在环境中注入故障，或评估环境的容忍能力，可以采用混沌工程。
- 如果发生特定的故障模型，预计会产生多大影响？ 如需了解故障可能对业务的影响，我们建议您针对每个故障模型估算模型设计的每个故障的后果。这种理解对于建立优先级和恢复顺序很有用，以便您和您的流程先处理最重要的组件。
- 您预计故障在您所定义的故障模型中会持续多长时间？故障的时长会极大地影响缓解和恢复计划。因此，在定义故障模型时，我们建议您考虑故障可能持续的时长。在考虑故障可能持续的时间时，还要考虑故障需要多长时间：确定故障、协调故障，以及恢复失败的资源。
如需详细了解故障模型以及如何设计可靠的灾难恢复计划，请参阅针对云基础架构服务中断设计灾难恢复架构。
评估部署原型
定义要防范的故障模型后，您可以评估部署原型以确定最符合您需求的模型。评估部署原型时，请考虑以下问题：
- 您需要多少个部署原型？您不必只选择一种架构原型来适应所有环境。 您可以改为实现混合方法，即根据所需的可靠性保证选择多个部署原型，以防范您定义的故障模型。例如，如果您定义了两个故障模型（一个需要可用区环境，另一个需要区域环境），则您可能需要选择单独的部署原型来防范每个故障模型。如果您选择多个部署原型，我们建议您评估设计、实现和操作多个环境的潜在复杂性。
- 根据部署原型，您需要设计和部署多少个资源？设计和实现任何类型的环境都需要资源和精力。我们建议您评估您认为需要多少资源，以便根据您选择的原型设计和实现每个环境。当您充分了解需要的资源数量时，则可以在每个架构原型提供的可靠性保证与基于这些原型的设计、实施和操作环境的成本和复杂性之间进行权衡。
- 您是否希望将基于一个架构原型的环境迁移到基于其他原型的环境？将来，您可以将工作负载、数据和流程从一个 Google Cloud 环境迁移到其他 Google Cloud 环境。例如，您可以从可用区环境迁移到区域环境。
- 您设计和实现的环境的业务关键程度如何？业务关键型环境可能需要更多的可靠性保证。例如，您可以选择为业务关键型工作负载、数据和流程设计和实现多区域环境，而为不太重要的工作负载、数据和流程设计可用区或区域环境。
- 您是否需要特定架构原型为特定环境提供的功能？除了每个架构原型提供的可靠性保证之外，原型还提供不同的可伸缩性、地理邻近性、延迟时间和数据存放区域保证。我们建议您在为环境选择部署原型时考虑这些保证。
除了根据上述指南定义的故障模式的技术方面，我们建议您考虑任何非功能性要求，例如监管、位置和主权要求。这些要求可能会限制您可以使用的选项。例如，如果您需要满足强制要求使用特定区域的监管要求，则必须设计和实现单区域环境或该区域中的可用区环境。
为您的环境选择 Google Cloud 区域
开始设计单区域环境时，您必须确定最适合每个环境要求的区域。以下部分介绍了这两种类别的选择标准：
- 功能标准。这些标准适用于特定区域提供的 Google Cloud 产品，以及特定区域是否符合您的延迟时间以及与 Google Cloud 外部的用户和其他环境的地理距离。例如，如果您的工作负载和数据对用户或 Google Cloud 外的其他环境的延迟时间有要求，您可能需要选择距离用户或其他环境最近的区域，以尽量减少相应的延迟时间。
- 非功能性标准。这些标准涉及与特定区域相关的产品价格、碳足迹要求，以及您的企业制定的强制性要求和法规。例如，银行和公共部门等严格监管的市场在数据和工作负载局部性以及它们如何与其他客户共享云提供商基础架构方面有着非常严格和具体的要求。
如果您现在选择的特定 Google Cloud 区域，将来可以迁移到不同的区域或多区域环境。如果您正在考虑将来迁移到其他区域，请参阅跨 Google Cloud 区域迁移：使用入门。
评估功能标准
如需评估功能标准，请考虑以下问题：
- 您的地理邻近度要求是什么？选择 Google Cloud 区域时，您可能需要将工作负载、数据和进程放置在用户或 Google Cloud 外部的环境（例如本地环境）附近。例如，如果您定位的是位于特定地理区域的用户群，我们建议您选择最靠近该地理区域的 Google Cloud 区域。选择最适合您的地理邻近度要求的 Google Cloud 区域，可让您的环境保证来自用户的请求以及来自 Google Cloud 外部的环境的请求具有更低的延迟时间和响应时间。Google Cloud 延迟时间信息中心以及非官方工具等，例如 GCP 和 Google Cloud 区域选择器可以让您大致了解 Google Cloud 区域的延迟时间特征。但是，我们建议您执行全面评估，以评估延迟时间属性是否符合您的要求、工作负载、数据和流程。
- 您要使用的哪个区域提供了所需的产品？我们建议您评估每个 Google Cloud 区域中可用的产品，以及哪些区域提供设计和实现环境所需的服务。如需详细了解每个区域中可用的产品及其可用性时间表，请参阅 Cloud 位置。 此外，某些产品可能无法在其可用的每个区域提供其所有功能。例如，Compute Engine 的可用区域和可用区在特定 Google Cloud 区域中提供特定机器类型。如需详细了解每种产品在每个区域中提供的功能，请参阅产品文档。
- 您所需的每个 Google Cloud 区域中的资源是否处于单区域配额上限内？Google Cloud 使用配额来限制您可以使用的共享 Google Cloud 资源的数量。 有些配额是全球性的，适用于您在 Google Cloud 中的任何位置使用资源的情况，而其他配额为区域级或可用区级，适用于在特定 Google Cloud 区域中使用资源的情况。例如，大多数 Compute Engine 资源用量配额（例如您可以创建的虚拟机数量）都是区域级的。 如需详细了解配额以及如何增加配额，请参阅使用配额。
评估非功能标准
如需评估非功能标准，请考虑以下问题：
- 是否想要低碳足迹？Google Cloud 持续投资于 Google Cloud 区域的可持续发展和无碳能源，并致力于为所有云区域提供无碳能源。Google Cloud 区域具有不同的碳足迹。如需了解每个 Google Cloud 区域的碳足迹，以及如何在位置策略中纳入无碳能源，请参阅 Google Cloud 区域的无碳能源。
- 您的环境是否需要满足特定的法规？ 政府以及国家和超国家实体通常严格监管某些市场和业务领域，例如银行和公共部门。 这些法规可能会要求工作负载、数据和流程仅位于特定的地理区域。例如，您的环境可能需要符合数据、运营和软件主权要求，以保证云中运行的敏感数据和工作负载具有特定程度的控制和透明度。我们建议您在为环境选择 Google Cloud 区域时评估当前和即将推出的监管要求，并选择最适合您的监管要求的 Google Cloud 区域。
设计和构建单区域环境
如需设计单区域环境，请执行以下操作：
- 在 Google Cloud 上构建您的基础。
- 预配和配置计算资源。
- 预配和配置数据存储资源。
- 预配和配置数据分析资源。
设计环境时，请考虑以下一般设计原则：
- 预配区域级资源。许多 Google Cloud 产品都支持在一个区域中的多个可用区预配资源。我们建议您尽可能预配区域级资源，而不是可用区级资源。理论上，您可以在一个区域中的多个可用区中预配可用区级资源，并自行管理这些资源以实现更高的可靠性。但是，该配置无法完全从支撑 Google Cloud 服务的 Google 基础设施的所有可靠性功能中获益。
- 使用失败模型假设验证环境是否按预期工作。在设计和实现单区域环境时，我们建议您在提升这些环境提升为生产环境的一部分之前，先验证这些环境是否满足您正在考虑的故障模型的要求。例如，您可以模拟可用区性服务中断，验证您的单区域环境可以在最小中断的情况下继续运行。
如需了解设计可靠的单区域和多区域环境的一般设计原则，以及了解 Google 如何使用单区域和多区域服务实现更高的可靠性，请参阅针对云基础架构服务中断设计灾难恢复架构：常见主题。
在 Google Cloud 上构建您的基础
如需构建单区域环境的基础，请参阅迁移到 Google Cloud：构建您的基础。 该文档中的指导旨在为将工作负载、数据和流程迁移到 Google Cloud 构建基础，但也适用于为单区域环境构建基础。阅读该文档后，请继续阅读本文档。
在 Google Cloud 上构建基础后，您可以设计和实现安全控制和边界。这些安全措施有助于确保您的工作负载、数据和流程保持在其各自的区域内。这些安全措施还有助于确保您的资源不会因错误、配置错误或恶意攻击而向其他区域泄露任何内容。
预配和配置计算资源
构建单区域环境的基础后，您可以预配和配置计算资源。以下部分介绍了支持区域部署的 Google Cloud 计算产品。
Compute Engine
Compute Engine 是 Google Cloud 的基础架构即服务 (IaaS)。它使用 Google 的全球性基础设施为客户提供虚拟机及相关服务。
Compute Engine 资源是可用区级的，例如虚拟机或可用区级永久性磁盘；或者是区域级的，例如静态外部 IP 地址；或者是全球性的，例如永久性磁盘快照。 如需详细了解 Compute Engine 支持的可用区级、区域级和全球性资源，请参阅全球性资源、区域级资源和可用区级资源。
为了更好地灵活地管理物理资源，Compute Engine 会将可用区与物理资源分离开来。如需详细了解此抽象及其可能的含义，请参阅可用区和集群。
为了提高使用 Compute Engine 的环境的可靠性，请考虑以下事项：
- 区域级托管式实例组 (MIG)。Compute Engine 虚拟机是可用区级资源，因此在发生可用区服务中断时，它们不可用。为了缓解此问题，Compute Engine 支持您创建区域级 MIG，这些实例组根据需求和区域可用性自动跨区域内的多个可用区预配虚拟机。如果您的工作负载是有状态工作负载，您还可以创建区域级有状态 MIG 以保留有状态数据和配置。区域级 MIG 支持模拟可用区故障。如需了解如何在使用区域级 MIG 时模拟可用区故障，请参阅模拟区域级 MIG 的可用区服务中断情况。如需了解区域级 MIG 与其他部署选项的比较情况，请参阅为工作负载选择 Compute Engine 部署策略。
- 目标分布形状。区域级 MIG 会根据目标分布形状分配虚拟机。为了确保一个区域中任意两个可用区之间的虚拟机分布差异不超过一个单位，我们建议您在创建区域级 MIG 时选择
EVEN分布形状。如需了解目标分布形状之间的差异，请参阅形状比较。 - 实例模板。MIG 使用名为实例模板的全球性资源类型来定义要预配的虚拟机。 虽然实例模板是全球性资源，但它们可能引用可用区级资源或区域级资源。在创建实例模板时，我们建议您尽可能引用区域级资源而非可用区级资源。 如果您使用可用区级资源，我们建议您评估使用这些资源的影响。例如，如果您创建了一个实例模板，其中会引用仅在给定可用区可用的永久性磁盘卷，则无法在任何其他可用区使用该模板，因为永久性磁盘卷不可在其他可用区使用。
- 配置负载均衡和扩缩功能。Compute Engine 支持 Compute Engine 实例之间的负载均衡流量，并且支持根据需要自动扩缩以在 MIG 中自动添加或移除虚拟机。为提高环境的可靠性和灵活性，并避免自行管理的解决方案的管理负担，我们建议您配置负载均衡和自动扩缩。如需详细了解如何为 Compute Engine 配置负载均衡和扩缩功能，请参阅负载均衡和扩缩功能。
- 配置资源预留。为确保您的环境在需要时具备必要的资源，我们建议您配置资源预留，以确保为可用区级 Compute Engine 资源获取容量。例如，如果发生可用区服务中断，您可能需要在另一个可用区中预配虚拟机，以提供必要的容量，以应对因服务中断而不可用的容量。资源预留可确保您有足够的资源来预配其他虚拟机。
- 使用可用区 DNS 名称。为了缓解跨区域服务中断的风险，我们建议您使用可用区 DNS 名称来唯一标识您的环境中使用 DNS 名称的虚拟机。默认情况下，Google Cloud 为 Compute Engine 虚拟机使用可用区 DNS 名称。如需详细了解 Compute Engine 内部 DNS 的工作原理，请参阅内部 DNS。 为方便跨区域进行未来迁移并使您的配置更易于维护，我们建议您考虑将可用区 DNS 名称作为配置参数，以备将来更改。
- 选择适当的存储选项。Compute Engine 支持为虚拟机提供多种存储选项，例如永久性磁盘卷和本地固态硬盘 (SSD)：
- 永久性磁盘卷分布在多个物理磁盘中，与虚拟机无关。永久性磁盘可以是可用区级磁盘，也可以是区域级磁盘。可用区级永久性磁盘将数据存储在单个可用区中，而区域级永久性磁盘会将数据复制到两个不同的可用区。为单区域环境选择存储选项时，我们建议您选择区域级永久性磁盘，因为它们会在发生可用区故障时为您提供故障切换选项。如需详细了解如何在使用区域级永久性磁盘时对可用区故障作出反应，请参阅使用区域级永久性磁盘的高可用性选项和区域级永久性磁盘磁盘故障切换。
- 本地 SSD 具有高吞吐量，但它们仅在实例停止或删除之前存储数据。因此，本地 SSd 非常适合存储临时数据、缓存以及您可以通过其他方式重建的数据。永久性磁盘是持久性存储设备，虚拟机可以像访问物理磁盘一样访问它们。
- 设计和实施数据保护机制。在设计单区域环境时，我们建议您实施自动机制，以便在出现不利事件（例如可用区、区域或多区域故障或者恶意第三方的攻击）时保护数据。Compute Engine 提供了多种保护数据的选项。 您可以使用这些数据选项功能作为设计和实施数据保护流程的基础组件。
GKE
GKE 可帮助您在 Kubernetes 上部署、管理和扩缩容器化工作负载。GKE 在 Compute Engine 的基础上构建，因此上一部分中有关 Compute Engine 的建议部分适用于 GKE。
为提高使用 GKE 的环境的可靠性，请考虑以下设计点和 GKE 功能：
- 使用区域级 GKE 集群提高可用性。GKE 支持集群的不同可用性类型，具体取决于您需要的集群类型。GKE 集群可以具有可用区或区域控制平面，并且可以具有在单个可用区或同一区域内的多个可用区中运行的节点。不同的集群类型还提供不同的服务等级协议 (SLA)。为提高环境的可靠性，我们建议您选择区域级集群。如果使用 GKE Autopilot 功能，则您只能预配区域级集群。
- 考虑使用多集群环境。部署多个 GKE 集群可以提高环境的灵活性和可用性属性，但代价是会增加复杂性。例如，如果您需要使用仅在创建 GKE 集群时启用的新 GKE 功能，则可以通过向多集群环境添加新的 GKE 集群、在新集群中部署工作负载并销毁旧集群来避免停机时间和降低迁移的复杂性。如需详细了解多集群 GKE 环境的优势，请参阅将容器迁移到 Google Cloud：迁移到多集群 GKE 环境。为了帮助您管理迁移的复杂性，Google Cloud 提供了舰队管理，这是一组功能，用于管理一组 GKE 集群及其基础架构，以及这些集群中部署的工作负载。
- 设置 Backup for GKE。Backup for GKE 是一项区域性服务，用于备份源 GKE 集群中的工作负载配置和卷，并将其恢复到目标 GKE 集群中。为了保护工作负载配置和数据免遭可能丢失，我们建议您启用并配置 Backup for GKE。如需了解详情，请参阅 Backup for GKE 概览。
Cloud Run
Cloud Run 是一个代管式计算平台，用于运行容器化工作负载。 Cloud Run 使用服务为您提供运行工作负载的基础架构。Cloud Run 服务是区域级资源，并且服务跨其所在区域中的多个可用区复制。 部署 Cloud Run 服务时，您可以选择一个区域。然后，Cloud Run 会自动选择该区域内的可用区来部署服务实例。Cloud Run 会自动在服务实例之间平衡流量，旨在大大减轻可用区服务中断的影响。
VMware Engine
VMware Engine 是一项全代管式服务，可让您在 Google Cloud 中运行 VMware 平台。为了提高使用 VMware Engine 的环境的可靠性，我们建议您执行以下操作：
- 预配多节点 VMware Engine 私有云。 VMware Engine 支持预配称为私有云的独立 VMware 堆栈，并且构成私有云的所有节点都位于同一区域。 私有云节点在专用、独立的裸机硬件节点上运行，并且配置为消除单点故障。VMware Engine 支持单节点私有云，但我们建议将单节点私有云用于概念验证和测试目的。对于生产环境，我们建议您使用默认的多节点私有云。
- 预配 VMware Engine 扩展私有云。扩展私有云是一种多节点私有云，其节点分布在一个区域内的多个可用区中。扩展的私有云保护您的环境免受可用区服务中断的影响。
如需详细了解 VMware Engine 的高可用性和冗余功能，请参阅可用性和冗余。
预配和配置数据存储资源
为单区域环境预配和配置计算资源后，您需要预配和配置资源以存储和管理数据。 以下部分介绍了支持单区域和多区域配置的 Google Cloud 数据存储和管理产品。
Cloud Storage
Cloud Storage 是一种将对象（这些是不可变的数据段）存储在存储桶中的服务，存储桶是保存数据的基本容器。创建存储桶时，您可以选择最符合可用性、监管和其他要求的存储桶位置类型。位置类型具有不同的可用性保证。 为了保护您的数据免受故障和中断的影响，Cloud Storage 使您的数据在至少两个可用区（对于具有区域位置类型的存储桶）、跨两个区域（对于具有双区域位置类型的存储桶）以及跨两个或多个区域（对于具有多区域位置类型的存储桶）实现冗余。例如，如果您需要在发生区域性服务中断时使 Cloud Storage 存储桶可用，则可以为其预配区域位置类型。
如需详细了解如何为存储在 Cloud Storage 中的数据设计灾难恢复机制，以及 Cloud Storage 如何针对可用区和区域服务中断进行响应，请参阅针对云基础架构服务中断设计灾难恢复架构：Cloud Storage。
Filestore
Filestore 在 Google Cloud 上提供全代管式文件服务器，这些服务器可以连接到 Compute Engine 实例、GKE 集群和本地机器。Filestore 提供了多种服务层级。 每个层级都提供独特的可用性、可伸缩性、性能、容量和数据恢复功能。预配 Filestore 实例时，我们建议您选择 Enterprise 层级，因为它支持高可用性和跨区域内多个可用区的数据冗余；其他层级中的实例是可用区级资源。
Bigtable
Bigtable 是一种全代管式高性能和高可伸缩性数据库服务，用于处理大规模分析和运营工作负载。Bigtable 实例是可用区级资源。 为提高实例的可靠性，您可以配置 Bigtable 以在同一区域内的多个可用区或跨多个区域复制数据。启用复制功能时，如果发生服务中断，Bigtable 会自动将请求故障切换到向您复制数据其他可用实例。
如需详细了解 Bigtable 中复制功能的工作原理，请参阅关于复制和针对云基础架构服务中断设计灾难恢复架构：Bigtable。
Firestore
Firestore 是一种灵活且可扩容的数据库，适用于在 Firebase 和 Google Cloud Platform 上进行移动、Web 和服务器开发。预配 Firestore 数据库时，您需要选择其位置。 位置可以是多区域位置，也可以是单区域位置，它们提供不同的可靠性保证。如果数据库具有区域位置，则会跨一个区域内的不同可用区复制数据。多区域数据库会跨多个区域复制数据。
如需了解 Firestore 中复制功能的工作原理，以及 Firestore 如何响应可用区和区域服务中断，请参阅 Firestore 位置和针对云基础架构服务中断设计灾难恢复架构：Firestore。
Memorystore
借助 Memorystore，您可以配置可伸缩、安全且可用性高的内存中数据存储服务。它支持 Redis 和 Memcached 的数据后端。
在预配 Memorystore for Redis 实例时，您可以为该实例选择一个服务层级。Memorystore for Redis 支持多种实例服务层级，而每个层级都提供独特的可用性、节点大小和带宽功能。预配 Memorystore for Redis 实例时，我们建议您选择标准层级或具有读取副本的标准层级。 这两个层级中的 Memorystore 实例会自动跨一个区域中的多个可用区复制数据。如需详细了解 Memorystore for Redis 如何实现高可用性，请参阅 Memorystore for Redis 高可用性。
预配 Memorystore for Memcached 实例时，请考虑以下事项：
- 可用区选择。预配 Memorystore for Memcached 实例时，请选择要在其中部署实例的区域。然后，您可以选择该区域内要部署该实例节点的可用区，也可以让 Memorystore for Memcached 自动在可用区之间分布节点。为了以最佳方式放置实例，并避免预配问题（例如将所有节点置于同一可用区内），我们建议您让 Memorystore for Memcached 自动在一个区域内的各可用区之间分布节点。
- 跨可用区的数据复制。Memorystore for Memcached 实例不会跨可用区或区域复制数据。如需详细了解 Memorystore for Memcached 实例在发生可用区或区域服务中断时的工作原理，请参阅针对云基础架构服务中断设计灾难恢复架构：Memorystore for Memcached。
Spanner
Spanner 是一种全托管式关系型数据库，规模不受限制，具有强一致性，可用性高达 99.999%。如需使用 Spanner，请预配 Spanner 实例。预配 Spanner 实例时，请考虑以下事项：
- 实例配置。实例配置定义了 Spanner 实例中数据库的地理位置和复制方式。创建 Spanner 实例时，您可以将其配置为单区域或多区域。
- 复制。Spanner 支持字节级的自动复制，并且会根据可用性、可靠性和可伸缩性需求支持创建副本。您可以跨区域和环境分发副本。具有单区域配置的 Spanner 实例会为区域内的每个可用区维护一个读写副本。具有多区域配置的实例会在多个区域的多个可用区中复制数据。
- 移动实例。Spanner 可让您将实例从任何实例配置移至任何其他实例配置，而不会在移动期间造成任何停机或事务保证中断。
如需详细了解 Spanner 复制以及 Spanner 如何应对可用区和区域服务中断，请参阅 Spanner 复制和针对云基础设施服务中断设计灾难恢复架构：Spanner。
预配和配置数据分析资源
为单区域环境预配和配置数据存储资源后，您可以预配和配置数据分析资源。以下部分介绍了支持区域配置的 Google Cloud 数据分析产品。
BigQuery
BigQuery 是一种全代管式企业数据仓库，可帮助您使用机器学习、地理空间分析和商业智能等内置功能管理和分析数据。
如需在 BigQuery 中组织和控制对数据的访问权限，您需要预配称为数据集的顶级容器。 预配 BigQuery 数据集时，请考虑以下事项：
- 数据集位置。如需选择用于存储数据的 BigQuery 位置，请配置数据集位置。该位置可以是单区域位置，也可以是多区域位置。对于任一位置类型，BigQuery 都会将您的数据副本存储在选定位置内的两个不同可用区中。创建数据集后，此数据集位置便无法更改。
- 制定灾难恢复计划。BigQuery 是一项区域级服务，它会自动为计算和数据处理可用区故障。 但在某些情况下，您必须自行规划，例如区域服务中断。我们建议您在设计环境时考虑这些情况。
如需详细了解 BigQuery 灾难恢复计划和功能，请参阅 BigQuery 文档中的了解可靠性：制定灾难恢复计划，并参阅针对云基础架构服务中断设计灾难恢复架构：BigQuery。
Dataproc
Dataproc 是一项代管式服务，可让您利用开源数据工具进行批处理、查询、流式传输和机器学习。Dataproc 在 Compute Engine 的基础上构建，因此上一部分有关 Compute Engine 的建议也适用于 Dataproc。
如需使用 Dataproc，请创建 Dataproc 集群。 Dataproc 集群是可用区级资源。 创建 Dataproc 集群时，请考虑以下事项：
- 自动可用区放置。创建集群时，您可以在要在其中预配集群节点的区域中指定可用区，也可以允许 Dataproc 自动选择可用区功能自动选择可用区。除非您需要微调集群内集群节点的可用区位置，否则我们建议您使用自动选择可用区功能。
- 高可用性模式。创建集群时，您可以启用高可用性模式。创建集群后，您无法启用高可用性模式。如果您需要集群能够应对单个协调者节点的故障或部分可用区服务中断，我们建议您启用高可用性模式。高可用性 Dataproc 集群是可用区级资源。
如需详细了解 Dataproc 如何响应可用区和区域服务中断，以及如何在发生故障时提高 Dataproc 集群的可靠性，请参阅针对云基础架构服务中断设计灾难恢复架构：Dataproc。
Dataflow
Dataflow 是一种用于运行流式和批量数据处理流水线的全代管式服务。如需使用 Dataflow，您需要创建 Dataflow 流水线，然后 Dataflow 会在工作器节点上运行作业（这些流水线的实例）。由于作业是可用区级资源，因此在使用 Dataflow 资源时，您应该考虑以下事项：
- 区域性端点。创建作业时，Dataflow 要求您配置区域端点。通过为作业配置区域端点，您可以将计算和数据资源位置限制为特定区域。
- 可用区放置。Dataflow 会根据作业类型自动在一个区域内的所有可用区或区域内的最佳可用区中分布工作器节点。通过 Dataflow 可以替换工作器节点的可用区放置，方法是将所有工作器节点放置在一个区域内的同一个可用区中。为了缓解由可用区服务中断引起的问题，我们建议您让 Dataflow 自动选择最佳可用区放置，除非您需要将工作器节点置于特定可用区。
如需详细了解 Dataproc 如何响应可用区和区域服务中断，以及如何在发生故障时提高 Dataproc 集群的可靠性，请参阅针对云基础架构服务中断设计灾难恢复架构：Dataflow。
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。
将您的工作负载调整为单区域环境
完成环境的预配和配置后，您需要考虑如何使工作负载更灵活地应对可用区和区域故障。每个工作负载都可以有自己的可用性和可靠性要求和属性，但是您可以应用一些设计原则，以在遇到不太可能发生的可用区和区域故障时提高整体弹性。在设计和实现工作负载时，请考虑以下事项：
- 实施站点可靠性工程 (SRE) 做法和原则。自动化和广泛的监控是 SRE 的核心原则的一部分。 Google Cloud 提供用于实现 SRE 的工具和专业服务，以提高环境的弹性和可靠性，并减少无谓的重复劳动。
- 在设计时确保可伸缩性和弹性。在设计面向云环境的工作负载时，我们建议您考虑可伸缩性和弹性是工作负载必须遵守的固有要求。如需详细了解此类设计，请参阅构建可扩缩且弹性佳的应用时应遵循的模式。
- 从云基础架构服务中断中恢复的设计。 Google Cloud 可用性保证由 Google Cloud 服务等级协议定义。 万一发生罕见的可用区或区域故障，我们建议您设计工作负载以适应可用区和区域故障。
- 实现减载和优雅降级。 如果云基础架构发生故障或工作负载的其他依赖项出现故障，我们建议您设计工作负载，使其具有弹性。即使发生故障（优雅降级），您的工作负载仍应保持特定且明确定义的功能，并且应该在接近过载条件（减载）时能够减少一定比例的负载。
- 计划定期维护。在设计部署流程和操作流程时，我们还建议您考虑在环境的常规维护过程中需要执行的所有活动。定期维护应包括将更新和配置更改应用于工作负载及其依赖项等活动，以及这些活动如何影响环境的可用性。例如，您可以为 Compute Engine 实例配置主机维护政策。
- 采用测试驱动开发方法。在设计工作负载时，我们建议您采用测试驱动开发方法，以确保您的工作负载在所有方面都能按预期运行。例如，您可以测试工作负载和云基础架构是否满足所需的功能、非功能和安全要求。
后续步骤
- 了解如何设计可扩缩且弹性佳的应用。
- 了解 Google Cloud 基础架构可靠性。
- 如需提高环境的可靠性和弹性，请参阅站点可靠性工程 (SRE)。
- 了解如何针对云基础架构服务中断设计灾难恢复架构。
- 如需了解其他迁移选项，请参阅迁移资源。
- 如需了解迁移框架，请参阅迁移到 Google Cloud：使用入门。
- 了解何时寻求迁移帮助。
- 如需查看更多参考架构、图表和最佳实践，请浏览云架构中心。
贡献者
作者：
- Marco Ferrari | 云解决方案架构师
其他贡献者：
- Henry Bell | 云解决方案架构师
- Elliot Eaton | 云解决方案架构师
- Grace Mollison | 解决方案负责人
- Ido Flatow | 云解决方案架构师
如需查看非公开的 LinkedIn 个人资料，请登录 LinkedIn。