如平台可用性中所述，Google Cloud 基础架构旨在支持部署到单个可用区的工作负载达到 99.9% 的目标可用性。多可用区部署的目标可用性为 99.99% 1，多区域部署的目标可用性为 99.999%。Google Cloud 基础架构可靠性指南的这一部分提供了部署指南、示例架构和设计技术，可帮助保护您的工作负载免受资源级、可用区级和区域级故障的影响。
避免单点故障
应用通常由多个相互依赖的组件组成，每个组件都执行特定的功能。这些组件通常根据其执行的功能及其与其他组件的关系分组到层级中。例如，一个内容传送应用可能有三个层级：包含负载均衡器和 Web 服务器的 Web 层级；具有应用服务器集群的应用层级；持久性数据层级。如果此应用堆栈的任何组件依赖于单个基础架构资源，则该资源的故障可能会影响整个堆栈的可用性。例如，如果应用层级在单个虚拟机上运行，并且虚拟机崩溃，则整个堆栈将不可用。此类组件属于单点故障 (SPOF)。
一个应用堆栈可能有多个 SPOF。假设有下图所示的多层应用堆栈：
如上图所示，此示例架构包含一个负载均衡器、两个 Web 服务器、一个应用服务器和一个数据库。此示例中的负载均衡器、应用服务器和数据库是 SPOF。这些组件中的任何一个发生故障都可能导致用户对应用的请求失败。
如需移除应用堆栈中的 SPOF，请跨位置分配资源并部署冗余资源。
分配资源并创建冗余
根据应用的可靠性要求，您可以从以下部署架构中进行选择：
| 架构 | 工作负载建议 |
|---|---|
| 多区域 | 业务关键型工作负载以及高可用性至关重要的工作负载，例如零售和社交媒体应用。 |
| 多区域 | 需要应对可用区服务中断但可以承受因区域服务中断而导致的停机时间的工作负载。 |
| 单区域 | 可以承受停机时间或在必要时能够轻松部署到其他位置的工作负载。 |
费用、延迟时间和运营注意事项
在设计具有冗余资源的分布式架构时，除了应用的可用性要求之外，您还必须考虑对运营复杂性、延迟时间和费用的影响。
在分布式架构中，您会预配和管理更多资源。跨位置的网络流量较高。您还会存储和复制更多数据。因此，分布式架构中的云资源费用较高，此类部署的操作更加复杂。对于业务关键型应用，分布式架构的可用性优势可能超过增加的费用和运营复杂性。
对于非业务关键型的应用，分布式架构提供的高可用性可能不是必要的。某些应用具有比可用性更重要的其他要求。例如，批处理计算应用需要虚拟机之间的短延时和高带宽网络连接。单可用区架构可能非常适合此类应用，它还可以帮助您降低数据传输费用。
部署架构
本部分介绍了在 Google Cloud 中为工作负载构建基础架构的以下架构选项：
单可用区部署
下图显示了在每一层都具有冗余的单可用区应用架构，以实现每个组件执行的功能的更高可用性：
如上图所示，此示例架构包含以下组件：
- 用于接收和响应用户请求的区域外部 HTTP/S 负载均衡器。
- 可用区托管式实例组 (MIG) 作为 HTTP/S 负载均衡器的后端。该 MIG 有两个 Compute Engine 虚拟机。每个虚拟机都托管一个 Web 服务器实例。
- 内部负载均衡器，用于处理 Web 服务器与应用服务器实例之间的通信。
- 第二个可用区级 MIG 作为内部负载均衡器的后端。此 MIG 包含两个 Compute Engine 虚拟机。每个虚拟机托管一个应用服务器实例。
- 应用向其写入数据和从中读取数据的 Cloud SQL 数据库实例（企业版）。该数据库会手动复制到同一可用区中的第二个 Cloud SQL 数据库实例。
总体可用性：单可用区部署
下表展示了上述单可用区架构图中每个层级的可用性：
| 资源 | 服务等级协议 (SLA) |
|---|---|
| 外部负载均衡器 | 99.99% |
| Web 层级：单个可用区中的 Compute Engine 虚拟机 | 99.9% |
| 内部负载均衡器 | 99.99% |
| 应用层级：单个可用区中的 Compute Engine 虚拟机 | 99.9% |
| Cloud SQL 实例（企业版） | 99.95% |
上表中列出的 Google Cloud 基础架构资源可提供以下总体可用性和预计的每月最长停机时间：
- 总体可用性：0.9999 x 0.999 x 0.9999 x 0.999 x 0.9995 = 99.73%
- 预计的每月最长停机时间：大约 1 小时 57 分钟
此计算结果仅基于上文架构图中显示的基础架构资源。如需评估 Google Cloud 中的应用的可用性，您还必须考虑其他因素，例如：
- 应用的内部设计
- 用于构建、部署、维护应用及其依赖项和 Google Cloud 基础架构的 DevOps 流程和工具
如需了解详情，请参阅影响应用可靠性的因素。
服务中断的影响和恢复指导
在单可用区部署架构中，如果任何组件发生故障，则当每个层级至少包含一个具有足够容量并且正常运行的组件时，应用即可处理请求。例如，如果 Web 服务器实例失败，则负载均衡器会将用户请求转发到其他 Web 服务器实例。如果托管 Web 服务器或应用服务器实例的虚拟机崩溃，MIG 可确保自动创建新虚拟机。如果数据库崩溃，您必须手动激活第二个数据库，并更新应用服务器实例以连接到数据库。
可用区服务中断或区域服务中断会影响单可用区部署中的 Compute Engine 虚拟机和 Cloud SQL 数据库实例。可用区服务中断不会影响此架构中的负载均衡器，因为它是区域级资源。但是，负载均衡器无法分配流量，因为没有可用的后端。如果可用区服务中断，您必须等待 Google 解决服务中断故障，然后验证应用是否按预期工作。
下一部分介绍了可用于跨多个可用区分发资源的架构方法，这有助于提高应用针对可用区服务中断的弹性。
多可用区部署
在单可用区部署中，如果可用区服务中断，则应用可能无法处理请求，直到问题得到解决。为了帮助提高应用针对可用区服务中断的恢复能力，您可以在两个或更多可用区预配多个可用区级资源实例（例如 Compute Engine 虚拟机）。对于支持区域级资源（例如 Cloud Storage 存储桶）的服务，您可以部署区域级资源。
下图展示了一个高可用性的跨可用区架构，其中应用堆栈的每一层的组件分布在两个可用区中：
如上图所示，此示例架构包含以下组件：
- 区域外部 HTTP/S 负载均衡器接收并响应用户请求。
- 区域 MIG 是 HTTP/S 负载均衡器的后端。该 MIG 包含两个位于不同可用区的 Compute Engine 虚拟机。每个虚拟机托管一个 Web 服务器实例。
- 内部负载均衡器处理 Web 服务器与应用服务器实例之间的通信。
- 第二个区域 MIG 是 TCP 负载均衡器的后端。此 MIG 有两个位于不同可用区的 Compute Engine 虚拟机。每个虚拟机托管一个应用服务器实例。
- 采用高可用性配置的 Cloud SQL 实例（企业版）是应用的数据库。主数据库实例会同步复制到备用数据库实例。
总体可用性：多可用区部署
下表展示了上述双可用区架构图中每个层级的可用性：
| 资源 | 服务等级协议 (SLA) |
|---|---|
| 外部负载均衡器 | 99.99% |
| Web 层级：不同可用区中的 Compute Engine 虚拟机 | 99.99% |
| 内部负载均衡器 | 99.99% |
| 应用层级：不同可用区中的 Compute Engine 虚拟机 | 99.99% |
| Cloud SQL 实例（企业版） | 99.95% |
上表中列出的 Google Cloud 基础架构资源可提供以下总体可用性和预计的每月最长停机时间：
- 总体可用性：0.9999 x 0.9999 x 0.9999 x 0.9999 x 0.9995 = 99.91%
- 预计的每月最长停机时间：大约 39 分钟
此计算结果仅基于上文架构图中显示的基础架构资源。如需评估 Google Cloud 中的应用的可用性，您还必须考虑其他因素，例如：
- 应用的内部设计
- 用于构建、部署、维护应用及其依赖项和 Google Cloud 基础架构的 DevOps 流程和工具
如需了解详情，请参阅影响应用可靠性的因素。
服务中断的影响和恢复指导
在双可用区部署中，如果任何组件出现故障，应用可在每个层中至少有一个具有足够容量的正常运行组件时处理请求。例如，如果 Web 服务器实例失败，则负载均衡器会将用户请求转发到其他可用区中的 Web 服务器实例。如果托管 Web 服务器或应用服务器实例的虚拟机崩溃，MIG 可确保自动创建新虚拟机。如果主 Cloud SQL 数据库崩溃，则 Cloud SQL 会通过故障切换机制自动切换到备用数据库实例。
下图展示了与上图相同的架构，以及可用区服务中断对应用可用性的影响：
如上图所示，如果其中一个区域服务中断，此架构中的负载均衡器不受影响，因为它是区域级资源。可用区服务中断可能会影响各个 Compute Engine 虚拟机和一个 Cloud SQL 数据库实例。但是，应用会保持可用状态且响应迅速，因为虚拟机位于区域 MIG 中，并且 Cloud SQL 数据库配置为具有高可用性。MIG 可确保自动创建新虚拟机以维持配置的虚拟机数下限。如果主 Cloud SQL 数据库实例受可用区服务中断影响，则 Cloud SQL 会通过故障切换机制自动切换到另一个可用区中的备用实例。Google 解决服务中断问题后，您必须验证应用是否在部署的所有可用区中按预期运行。
注意：墨西哥、蒙特利尔和大阪区域有三个可用区，位于一个或两个物理数据中心内。这些区域目前正在扩展到至少三个物理数据中心。如需了解详情，请参阅 Cloud 位置和 Google Cloud Platform SLA。为了提高工作负载的可靠性，不妨考虑进行多区域部署。如果此架构中的两个可用区服务中断，则应用不可用。除非区域服务中断，否则负载均衡器将继续可用。但是，负载均衡器无法分配流量，因为没有可用的后端。如果多可用区服务中断或区域服务中断，您必须等待 Google 解决服务中断故障，然后验证应用是否按预期工作。
接下来的部分介绍可保护您的应用免受多可用区服务中断和区域服务中断影响的架构选项。
使用区域负载均衡进行多区域部署
在单可用区或多可用区部署中，如果区域服务中断，则应用在问题得到解决之前无法处理请求。为了保护您的应用免受区域服务中断的影响，您可以在两个或更多区域之间分发 Google Cloud 资源。
下图展示了一个高可用性的跨区域架构，其中应用堆栈每一层的组件分布在多个区域中：
如上图所示，此示例架构包含以下组件：
- 具有将流量路由到两个 Google Cloud 区域的路由政策的公共 Cloud DNS 区域。
- 在每个区域中接收和响应用户请求的区域外部 HTTP/S 负载均衡器。
- 每个区域 HTTP/S 负载均衡器的后端都是区域级 MIG。每个 MIG 都包含位于不同可用区的两个 Compute Engine 虚拟机。每个虚拟机都托管一个 Web 服务器实例。
- 每个区域中的内部负载均衡器会处理 Web 服务器实例与应用服务器实例之间的通信。
- 第二对区域 MIG 是内部负载均衡器的后端。每个 MIG 都包含位于不同可用区的两个 Compute Engine 虚拟机。每个虚拟机托管一个应用服务器实例。
- 应用对多区域 Spanner 实例执行数据读写操作。此架构 (
eur5) 中使用的多区域配置包含四个读写副本。读写副本在两个区域和不同可用区中均匀预配。多区域 Spanner 配置还包括第三个区域中的见证者副本。
总体可用性：使用区域负载均衡的多区域部署
在上图所示的多区域部署中，负载均衡器和虚拟机以冗余方式在两个区域中预配。DNS 区域是一种全球性资源，Spanner 实例是一种多区域资源。
如需计算此架构中显示的 Google Cloud 基础架构的总体可用性，我们必须先计算每个区域中的资源的总体可用性，然后考虑跨多个区域的资源。请按照以下过程操作：
- 计算每个区域的基础架构资源的总体可用性；也就是说，不包括 DNS 和数据库资源：
资源和服务等级协议 (SLA) 服务等级协议 (SLA) 外部负载均衡器 99.99% Web 层级：不同可用区中的 Compute Engine 虚拟机 99.99% 内部负载均衡器 99.99% 应用层级：不同可用区中的 Compute Engine 虚拟机 99.99% 每个区域的总体可用性：0.9999 x 0.9999 x 0.9999 x 0.9999 = 99.96%
根据负载均衡器和 Compute Engine 虚拟机的双区域冗余计算基础架构资源的总体可用性。
理论上的可用性为 1-(1-0.9996)(1-0.9996) = 99.999984%。但是，您可以预计的实际可用性仅限于多区域部署的目标可用性，即 99.999%。
计算所有基础架构资源的总体可用性，包括 Cloud DNS 和 Spanner 资源：
- 总体可用性：0.99999 x 1 x 0.99999 = 99.998%
- 预计的每月最长停机时间：大约 52 秒
此计算结果仅基于上文架构图中显示的基础架构资源。如需评估 Google Cloud 中的应用的可用性，您还必须考虑其他因素，例如：
- 应用的内部设计
- 用于构建、部署、维护应用及其依赖项和 Google Cloud 基础架构的 DevOps 流程和工具
如需了解详情，请参阅影响应用可靠性的因素。
服务中断的影响和恢复指导
如果此多区域部署中的任何组件发生故障，但每个层级中至少有一个具有足够容量的正常运行组件，则应用将继续运行。例如，如果 Web 服务器实例失败，则区域外部 HTTP/S 负载均衡器会将用户请求转发到该区域中的其他 Web 服务器实例。同样，如果其中一个应用服务器实例崩溃，则内部负载均衡器会向其他应用服务器实例发送请求。如果任何虚拟机崩溃，MIG 可确保自动创建新虚拟机以维持配置的虚拟机数下限。
单个可用区的服务中断不会影响负载均衡器，因为它们是区域级资源并且能够应对可用区服务中断。可用区服务中断可能会影响各个 Compute Engine 虚拟机。但是，Web 服务器和应用服务器实例仍然可用，因为虚拟机是区域级 MIG 的一部分。MIG 可确保自动创建新虚拟机以维持配置的虚拟机数下限。此架构中的 Spanner 实例使用多区域配置，可应对可用区服务中断。
如需了解多区域复制在 Spanner 中的工作原理，请参阅区域配置和多区域配置以及 Spanner 多区域配置解密。
下图展示了与上图相同的多区域架构，以及单区域服务中断对应用可用性的影响：
如上图所示，即使任何区域的两个可用区服务中断，应用也仍然可用，因为每个区域部署了独立的应用堆栈。DNS 区域将用户请求定向到不受服务中断影响的区域。多区域 Spanner 实例可以应对区域服务中断。在 Google 解决服务中断问题后，您必须验证应用是否在服务中断区域按预期运行。
如果此架构中任意两个区域服务中断，则应用将不可用。请等待 Google 解决服务中断问题。然后，验证应用在部署的所有区域中按预期运行。
对于多区域部署，您可以考虑使用全球负载均衡器，而不是使用区域负载均衡器。下一部分介绍了使用全球负载均衡器的多区域部署架构，并介绍了这种方法的优势和风险。
使用全球负载均衡进行多区域部署
下图显示了使用全球负载均衡器而不是区域负载均衡器的替代多区域部署：
如上图所示，此架构使用全球外部 HTTP/S 负载均衡器（已启用 Cloud CDN）来接收和响应用户请求。负载均衡器的每条转发规则使用单个外部 IP 地址；您无需为每个区域配置单独的 DNS 记录。全球外部 HTTP/S 负载均衡器的后端是两个区域 MIG。负载均衡器将请求路由到离用户最近的区域。
此架构中的所有其他组件都与使用区域负载均衡进行多区域部署中显示的架构相同。
多区域部署的全球负载均衡的优势和风险
如需对分布在多个区域的应用进行外部流量负载均衡，您可以使用全球负载均衡器或多个区域负载均衡器。
以下是使用全球负载均衡器的架构的优势：
- 您只需管理单个负载均衡器。
- 全球负载均衡器使用单个任播 IP 地址跨 Google Cloud 区域提供负载均衡。
- 全球负载均衡器可以灵活应对区域服务中断，并提供自动跨区域故障切换功能。
- 全球负载均衡器支持以下功能，这有助于提高部署的可靠性：
以下是使用全球负载均衡器的架构的风险：
- 对全球负载均衡器的配置进行错误更改可能会导致用户无法使用应用。例如，在更新全球负载均衡器的前端时，如果您意外删除了转发规则，则负载均衡器会停止接收用户请求。对于使用区域负载均衡器的多区域架构，此风险的影响较低，因为即使其中一个区域的区域负载均衡器受配置错误的影响，其他区域内的负载均衡器仍然会正常运行。
- 影响全球性资源的基础架构服务中断可能会导致全球负载均衡器不可用。
为降低这些风险，您必须谨慎管理对全球负载均衡器的更改，并考虑尽可能使用深度防御回退。如需了解详情，请参阅 管理全球性资源服务中断的风险的建议。
总体可用性：使用全球负载均衡的多区域部署
在上图所示的多区域部署中，虚拟机和内部负载均衡器以冗余方式分布在两个区域中。外部负载均衡器是一种全球性资源，Spanner 实例是一种多区域资源。
如需计算此部署的总体可用性，我们首先计算每个区域中的资源的总体可用性，然后考虑跨多个区域的资源。
- 计算每个区域的基础架构资源的总体可用性，不包括外部负载均衡器和数据库：
资源 服务等级协议 (SLA) Web 层级：不同可用区中的 Compute Engine 虚拟机 99.99% 内部负载均衡器 99.99% 应用层级：不同可用区中的 Compute Engine 虚拟机 99.99% 每个区域的总体可用性：0.9999 x 0.9999 x 0.9999 = 99.97%
根据内部负载均衡器和 Compute Engine 虚拟机的双区域冗余计算基础架构资源的总体可用性。
理论上的可用性为 1-(1-0.9997)(1-0.9997) = 99.999991%。但是，您可以预计的实际可用性仅限于多区域部署的目标可用性，即 99.999%。
计算所有基础架构资源的总体可用性，包括全球负载均衡器和 Spanner 资源：
- 总体可用性：0.99999 x 0.9999 x 0.99999 = 99.988%
- 预计的每月最长停机时间：大约 5 分钟 11 秒
此计算结果仅基于上文架构图中显示的基础架构资源。如需评估 Google Cloud 中的应用的可用性，您还必须考虑其他因素，例如：
- 应用的内部设计
- 用于构建、部署、维护应用及其依赖项和 Google Cloud 基础架构的 DevOps 流程和工具
如需了解详情，请参阅影响应用可靠性的因素。
服务中断的影响和恢复指导
如果此架构中的任何组件发生故障，则当每个层级中至少有一个具有足够容量的正常运行组件时，应用将继续运行。例如，如果 Web 服务器实例发生故障，则全球外部 HTTP/S 负载均衡器会将用户请求转发到其他 Web 服务器实例。如果应用服务器实例崩溃，则内部负载均衡器会向其他应用服务器实例发送请求。如果任何虚拟机崩溃，MIG 可确保自动创建新虚拟机以维持配置的虚拟机数下限。
如果任何区域的某个可用区服务中断，则负载均衡器不受影响。全球外部 HTTP/S 负载均衡器能够应对可用区和区域服务中断。内部负载均衡器是区域级资源，它们可以灵活应对可用区服务中断。可用区服务中断可能会影响各个 Compute Engine 虚拟机。但是，Web 服务器和应用服务器实例仍然可用，因为虚拟机属于区域 MIG。MIG 可确保自动创建新虚拟机以维持配置的虚拟机数下限。此架构中的 Spanner 实例使用多区域配置，可应对可用区服务中断。
下图展示了与上图相同的多区域架构，以及单区域服务中断对应用可用性的影响：
如上图所示，即使任何区域的两个可用区服务中断，应用也仍然可用，因为每个区域部署了独立的应用堆栈。全球外部 HTTP/S 负载均衡器将用户请求路由到不受服务中断影响的区域中的应用。多区域 Spanner 实例可以应对区域服务中断。在 Google 解决服务中断问题后，您必须验证应用是否在服务中断区域按预期运行。
如需了解多区域复制在 Spanner 中的工作原理，请参阅区域配置和多区域配置以及 Spanner 多区域配置解密。
如果此架构中任意两个区域服务中断，则应用将不可用。全球外部 HTTP/S 负载均衡器可用，但由于没有可用的后端，它无法分配流量。请等待 Google 解决服务中断问题。然后，验证应用在部署的所有区域中按预期运行。
多区域部署有助于确保最重要的业务应用的高可用性。为确保故障事件期间的业务连续性，除了跨多个区域部署应用之外，您还必须执行某些额外步骤。例如，您必须执行 容量规划，以确保在所有区域中预留足够的容量，或者与紧急自动扩缩相关的风险在可接受的范围内。您还必须实现灾难恢复测试的运营做法，管理突发事件，在突发事件验证后验证应用状态，以及执行回顾。
-
墨西哥、蒙特利尔和大阪区域有三个可用区，每个区域的可用区位于一个或两个物理数据中心内。 这些区域目前正在扩展到至少三个物理数据中心。如需了解详情，请参阅 Cloud 位置和 Google Cloud Platform SLA。为了提高工作负载的可靠性，请考虑进行多区域部署。 ↩