Google Cloud Well-Architected Framework：金融服务行业视角中的本文档概述了在Google Cloud中设计、部署和运行可靠的金融服务行业 (FSI) 工作负载的原则和建议。本文档探讨了如何将高级可靠性实践和可观测性集成到您的架构蓝图中。本文档中的建议与架构完善框架的可靠性支柱保持一致。
对于金融机构而言，可靠且富有弹性的基础架构既是业务需求，也是监管要求。为确保Google Cloud 中的 FSI 工作负载可靠，您必须了解并缓解潜在的故障点、以冗余方式部署资源，并规划恢复方案。运营弹性是可靠性的结果。是指吸收、适应和从中断中恢复的能力。运营弹性有助于 FSI 组织满足严格的监管要求。还有助于避免对客户造成无法容忍的伤害。
Google Cloud 中的关键可靠性构建块是区域、可用区以及云资源的各种位置范围：可用区级、区域级、多区域级、全球级。您可以通过使用托管服务、分配资源、实现高可用性模式和自动执行流程来提高可用性。
法规要求
FSI 组织在监管机构（例如美国的联邦储备系统、欧盟的欧洲银行管理局和英国的审慎监管局）的严格可靠性要求下运营。在全球范围内，监管机构都强调运营韧性，这对于金融稳定和消费者保护至关重要。运营弹性是指能够承受中断、有效恢复并维持关键服务的能力。这需要采取统一的方法来管理技术风险和对第三方的依赖。
大多数司法管辖区的监管要求都具有以下共同主题：
- 网络安全和技术弹性：加强对网络威胁的防御，确保 IT 系统的弹性。
- 第三方风险管理：管理与将服务外包给信息和通信技术 (ICT) 提供商相关的风险。
- 业务连续性和突发事件响应：制定周密的计划，以在中断期间维持关键运营并有效恢复。
- 维护金融稳定：确保整个金融体系的稳健性和稳定性。
本文档中的可靠性建议与以下核心原则相对应：
优先考虑多可用区和多区域部署
对于关键的金融服务应用，我们建议您使用多区域拓扑，该拓扑分布在至少两个区域以及每个区域内的三个可用区中。此方法对于提高可用区和区域服务中断的应对能力至关重要。法规通常会规定这种方法，因为如果一个可用区或区域发生故障，大多数司法管辖区都会认为第二个可用区严重中断是可能的结果。原因是，当一个位置发生故障时，另一个位置可能会收到异常高的额外流量。
请考虑以下建议，以提高应对可用区和区域中断的弹性：
- 优先选择位置范围更广的资源。尽可能使用区域级资源（而不是可用区级资源），并使用多区域级或全球资源（而不是区域级资源）。此方法有助于避免需要使用备份来恢复操作。
- 在每个区域中，利用三个可用区而不是两个。为处理故障切换，请将容量预配量比估计值多三分之一。
- 通过实施主动-主动部署（如以下示例所示）来最大限度地减少手动恢复步骤：
- Spanner 等分布式数据库可提供跨区域的内置冗余和同步功能。
- Cloud SQL 的高可用性功能提供了一种近乎主动-主动的拓扑，其中包含跨可用区的只读副本。它可实现接近于 0 的区域间恢复点目标 (RPO)。
- 使用 Cloud DNS 在各个区域之间分配用户流量，并在每个区域中部署区域级负载均衡器。根据您的需求和关键程度，您还可以考虑使用全球负载均衡器。如需了解详情，请参阅多区域部署的全球负载均衡的优势和风险。
- 如需存储数据，请使用 Spanner 和 Cloud Storage 等多区域服务。
消除单点故障
跨不同位置分配资源并使用冗余资源，以防止任何单点故障 (SPOF) 影响整个应用堆栈。
请考虑以下建议，以避免出现 SPOF：
- 避免仅部署单个应用服务器或数据库。
- 使用托管式实例组 (MIG) 确保自动重新创建失败的虚拟机。
- 通过实现负载均衡，在可用资源之间均匀分配流量。
- 为 Cloud SQL 等数据库使用高可用性配置。
- 使用区域级永久性磁盘（支持同步复制）提高数据可用性。
如需了解详情，请参阅在 Google Cloud中为工作负载设计可靠的基础设施。
了解和管理汇总的空闲情况
请注意，系统的总体或汇总可用性会受到系统每个层级或组件的可用性的影响。应用堆栈中的层级数与堆栈的总体可用性具有反向关系。请考虑以下有关管理汇总可用性的建议：
使用公式层级 1 的可用性 × 层级 2 的可用性 × 层级 N 的可用性计算多层式堆栈的总体可用性。
下图展示了由四项服务组成的多层级系统的汇总可用性计算：
在上图中，每个层级的服务都提供 99.9% 的可用性，但系统的总体可用性较低，为 99.6% (0.999 × 0.999 × 0.999 × 0.999)。一般来说，多层式堆栈的总体可用性低于提供最低可用性的层级的可用性。
在可行的情况下，选择并行化而非链式调用。借助并行化服务，端到端可用性高于每个单独服务的可用性。
下图展示了通过链接和并行化方法部署的两个服务 A 和 B：
在上述示例中，两项服务的 SLA 均为 99%，因此根据实现方法的不同，总可用性如下：
- 链式服务的总体可用性仅为 98%（0.99 × 0.99）。
- 并行化服务可实现 99.99% 的更高总体可用性，因为每个服务都是独立运行的，单个服务不会受到其他服务的可用性影响。并行化服务的汇总公式为 1 − (1 − A) × (1 − B)。
选择 Google Cloud 具有正常运行时间 SLA 的服务，以帮助满足应用堆栈所需的总体正常运行时间级别。
在设计架构时，请考虑可用性、运营复杂性、延迟时间和费用之间的权衡取舍。提高可用性（以“9”的数量表示）通常会增加费用，但有助于您满足监管要求。
例如，99.9% 的可用性（三个 9）意味着 24 小时内可能会有 86 秒的停机时间。相比之下，99%（两个 9）意味着在同一时间段内停机 864 秒，这比可用性为三个 9 的停机时间多 10 倍。
对于关键金融服务，架构选项可能有限。不过，务必要确定可用性要求并准确计算可用性。进行此类评估有助于您评估设计决策对架构和预算的影响。
实施稳健的灾难恢复策略
针对不同的灾难场景（包括地区级和区域级服务中断）制定明确的计划。借助明确的灾难恢复 (DR) 策略，您可以从中断中恢复过来，并以最小的影响恢复正常运营。
灾难恢复 (DR) 和高可用性 (HA) 是不同的概念。对于云部署，一般来说，DR 适用于多区域部署，而 HA 适用于区域部署。这些部署原型支持不同的复制机制。
- HA：许多受管服务默认在单个区域内的可用区之间提供同步复制。此类服务支持零或接近零的恢复时间目标 (RTO) 和恢复点目标 (RPO)。借助此支持，您可以创建没有任何 SPOF 的主动-主动部署拓扑。
- 灾难恢复：对于部署在两个或更多区域中的工作负载，如果您不使用多区域或全球服务，则必须定义复制策略。复制策略通常是异步的。请仔细评估此类复制对关键应用的 RTO 和 RPO 有何影响。确定故障切换所需的手动或半自动化操作。
对于金融机构，您选择的故障切换区域可能会受到有关数据主权和数据驻留的法规限制。如果您需要在两个区域中实现主动-主动拓扑，我们建议您选择托管式多区域服务，例如 Spanner 和 Cloud Storage，尤其是在数据复制至关重要的情况下。
请考虑以下建议：
- 使用托管式多区域存储服务来存储数据。
- 为永久性磁盘中的数据拍摄快照，并将快照存储在多区域位置。
- 使用区域级或可用区级资源时，请设置数据复制到其他区域。
- 通过定期测试灾难恢复计划，验证其有效性。
- 请注意 RTO 和 RPO，以及它们与您所在管辖区金融法规规定的影响容忍度的相关性。
如需了解详情，请参阅针对云基础架构服务中断设计灾难恢复架构。
利用代管式服务
尽可能使用托管式服务，以利用内置的备份、高可用性和可伸缩性功能。请考虑以下有关使用托管式服务的建议：
- 在 Google Cloud中使用托管式服务。它们提供由 SLA 支持的 HA。它们还提供内置备份机制和弹性功能。
- 对于数据管理，请考虑使用 Cloud SQL、Cloud Storage 和 Spanner 等服务。
- 对于计算和应用托管，请考虑 Compute Engine 托管实例组 (MIG) 和 Google Kubernetes Engine (GKE) 集群。区域 MIG 和 GKE 区域级集群能够灵活应对可用区服务中断。
- 如需提高应对区域级服务中断的弹性，请使用托管式多区域服务。
- 确定具有独特特征的服务是否需要退出计划，并定义所需的计划。FCA、PRA 和 EBA 等金融监管机构要求公司制定数据检索和运营连续性策略及应急计划，以应对与云提供商的关系终止的情况。公司必须在签订云合同之前评估退出可行性，并且必须保持在不中断运营的情况下更换提供商的能力。
- 验证您选择的服务是否支持将数据导出为 CSV、Parquet 和 Avro 等开放格式。验证服务是否基于开放技术，例如 GKE 支持 Open Container Initiative (OCI) 格式或 Cloud Composer 基于 Apache Airflow 构建。
自动执行基础架构预配和恢复流程
Automation 有助于最大限度地减少人为错误，并有助于减少响应突发事件所需的时间和资源。使用自动化有助于确保更快地从故障中恢复，并获得更一致的结果。 不妨考虑以下建议，以自动执行资源预配和恢复操作：
- 使用 Terraform 等基础架构即代码 (IaC) 工具，最大限度地减少人为错误。
- 通过自动化故障切换流程来减少人工干预。自动回复还有助于减少故障的影响。例如，您可以使用 Eventarc 或 Workflows 自动触发补救措施，以响应通过审核日志发现的问题。
- 在故障切换期间，使用自动扩缩功能来增加云资源的容量。
- 通过采用平台工程，在服务部署期间自动应用政策和安全措施，以满足整个云拓扑中的监管要求。