软件即服务 (SaaS) 组织不断发展，其全球业务覆盖范围也不断扩大，与此同时，他们必须考虑更广阔的地理覆盖范围会对其系统架构产生怎样的影响。迁移到地理位置分散的 SaaS 模型可能会对运营、部署、敏捷性、安全性和扩展等方面产生影响。

这种朝着多区域模式转变的趋势通常代表着 SaaS 组织的重大转变。系统运营和部署配置文件的复杂程度越高，持续实现常见的 SaaS 交付模式敏捷性目标的难度就越大。

这篇博文重点讲解了如何应对这一难题，即在满足多区域分配需求的同时，灵活满足市场需求。因此，本文将探讨 SaaS 组织采用多区域策略的常见原因。以此为背景，我们可以深入了解在构建、部署和管理多区域 SaaS 环境时常用的架构模式和策略。

确定多区域问题的范围

多区域架构的主题涵盖范围广，包括广泛的架构考虑因素，而这些因素可能会影响系统架构的很多方面。AWS 提供一系列实用资源，可从整体上为使用多区域架构提供实用指导。有许多博文和白皮书都审视了各项服务、联网模型和常规故障转移模式的多区域能力。本文末尾处随附了部分多区域参考资料。

在探讨过程中，更有意义的做法是专注于与多区域 SaaS 环境相关的细节和动机。本指南与更广泛的多区域策略相结合，应该能为您提供一系列基本的考虑因素，供您确定整体的多区域策略。

为什么要迁移到多区域 SaaS？

在我们研究多区域架构之前，首先来了解促使 SaaS 提供商采用多区域模型的动态。在许多情况下，SaaS ISV 都可以通过传统、基于边缘的内容分配策略应对基本的地理位置挑战。例如，Amazon CloudFront 可用于解决与地理位置分配有关的常见延迟问题。

在达到某个特定点后，问题就会脱离静态内容分配，更加专注于可用性、性能和区域考虑事项。在这些情况下，您必须引入新的往往也是定制的机制，从而实现多区域目标。下文列出了促使 SaaS 提供商转而采用多区域模式的常见因素。

故障转移：抵御区域系统故障的能力，使部分或全部系统能够有效地将负载转移到备用区域。
延迟：需要处理和提供非静态数据，同时保证不会产生长网络跳跃的开销。
合规性：区域合规性要求的变化意味着数据和服务必须在区域内托管。

故障转移是一个相当广泛的多区域主题，往往更多地涉及到采用可以承受区域化应用程序问题的灾难恢复模型。在这种模式下，SaaS 提供商往往要设法将其部分或全部环节复制到另一个区域。如果发生故障，他们的系统可以从容将流量重定向到另一个区域。

故障转移可以通过多种不同的模型实现，并且在您的解决方案中具有不同的粒度级别。您在此方面选择的方法将由架构性质和系统的分解情况决定。它也可能受到您在解决方案中使用的各种工具和服务的复制能力的影响。具有稳健的故障转移策略可能对 SaaS 提供商十分有益，此类提供商的所有区域客户都可以托管在一个共享基础设施之中。在此模型中，您可以选择跨区域模型来限制以区域为中心的应用程序问题的影响范围。

另一方面，延迟和合规性是促使 SaaS 提供商采用多区域方法的更常见的因素。对于某些全球化的 SaaS 提供商来说，其应用程序的访问模式和常规使用模式使其很难在一个区域中托管解决方案。虽然基于边缘的内容有所帮助，但内容分发网络 (CDN) 可能无法充分涵盖某些应用程序流程。应用程序的某些功能可能需要交换数据，而这些数据必须直接由一项或多项应用程序服务提供。在这些情况下，您可能很快就会到达临界点，因此将部分或全部应用程序直接部署到一个区域中便是自然而然的选择了。举例来说，如果您正在构建需要在几毫秒内呈现广告的广告投放平台，则可能会发现从单个区域投放内容不足以满足需求。

合规性往往受监管数据隐私的地区性法规影响。数据主权和通用数据保护法规 (GDPR) 的要求往往会施加一定的限制，只能通过某种多区域策略才能成功应对这样的限制。即使在这些情况下，也可以选择应用程序中受区域合规性问题影响的部分。此时，您可能会发现自己需要平衡部署和管理更为复杂的架构范围的复杂性。通常在这些情况下，SaaS 提供商更愿意将其整个解决方案迁移到一个区域。

多区域模型的影响

现在我们已经掌握了一些可以将 SaaS 提供商推向多区域模型的常见主题，接下来，我们来看看采用多区域模型对 SaaS 解决方案的设计、架构、操作和敏捷性有何影响。我们的首要目标是找到一种方法来引入多区域的概念，同时保证不会影响大多数 SaaS 解决方案的基本敏捷性目标。

以下部分强调了转移到多区域 SaaS 模型时需要考虑的一些关键方面。此列表并不完整，但如实反映了 SaaS 组织面临的一些常见挑战。

租户注册

提供顺畅无忧的注册体验对 SaaS 组织而言至关重要。我们的目标是简化获取和预置新客户环境的过程。当然，如果您的解决方案托管在多个区域，那么就可能会给您的注册流程增加难度。

图 1 展示了在多区域模型中注册租户时可以采用的一种方法。您会注意到，我们有一些新租户在多个区域注册了 SaaS 解决方案。在此模型中，租户在注册过程中提供数据来区分其目标区域。然后，共享注册服务将负责编排在其指定区域预置新租户的工作。

共享注册

图 1 – 集中化注册模型。

该模型会尝试将注册流程集中在一个区域。这能简化流程，但与此同时，也造成了合规性方面的挑战。由于需要在各区域以外收集用户信息，因此可能会违反某个区域的主权要求。但是，如果您没有遇到合规性问题，那么这种方法会对您极具吸引力。

这种策略的另一种替代方法就是分散处理注册流程的某些方面。 图 2 展示了这个问题的替代方法，即将注册流程分别分配到各区域。

登录路由页面

图 2 – 分散注册模型。

基本区别在于，注册体验现在托管在各个区域，从而确保所收集的关于租户的任何数据都在该区域的范围内进行管理。这种模型的主要挑战在于，确定租户如何重定向到各区域的注册体验。为此，我们引入了登录/路由页面，允许用户选择进入其所选的区域。这只是一种选择，每个解决方案都可以采取不同的方法，保证租户登录到正确的区域。关键要点在于，租户数据的实际注册和收集均在区域本地完成。

在这种更为分布式的模型中，部署模型的复杂程度确实会有所提高，同时也会丧失管理和部署集中化体验的能力。不过，如果您正部署到具有 GDPR 或一般数据主权要求的区域，这通常是您唯一的选择。

多区域身份

成功注册租户之后，您仍然需要确定多区域环境将如何支持身份验证。虽然为所有用户提供集中化模型身份提供商是不错的选择，但这些数据的集中化并不符合监管个人信息管理的任何基本数据主权要求。

鉴于这一点，您的身份识别方法应该专注于租户体验，并引入一种机制，以便有效地将您的身份管理路由到每个区域。就许多方面来说，此处所述的挑战都与上面的注册讨论重叠。但现在，您必须具备一种非侵入式模型，以将用户路由到以区域为中心的身份验证体验。

理想情况下，您希望这能给您的租户带来相对无缝的体验，保证到给定区域的路由大多是透明的。解决此问题的一种常见方法是在您的应用程序的 URL 中嵌入租户上下文。 图 3 提供了这种方法的实际应用示例。

租户路由

图 3 – 使用 URL 路由租户身份验证。

采用这种模型时，系统会为每个租户分配一个唯一 URL，并在注册体验中预置此唯一 URL。在本例中，我们创建了子域，在应用程序 URL 之前加上了租户范围。此子域使用传统 DNS 路由（显示为_图 3_ 中的 Amazon Route 53）将各租户指引到相应的区域。

路由到相应的区域之后，您的 SaaS 解决方案就会依靠区域托管的身份提供商来对系统用户进行管理和身份验证。在本例中，我们将 Amazon Cognito 显示为各区域的身份提供商。

虽然这种模型在租户预置流程中添加了配置元素和更多活动部分，但也为最终用户提供了更加直观的体验。另请务必注意，子域名前面的租户标识符不应直接映射到实际租户标识符的任何内部表示。反之，这应表现为一个唯一的子域，仅用于将用户路由到其所在区域。

在某些情况下，您的应用程序可能需要依靠租户选择目标区域或环境，然后才能进行身份验证。在用户可以选择在多个区域中拥有账户的情况下，会显示这样的选项。在此类情况下，可能不可避免地需要将该区域作为身份验证体验的一部分加以显示。

对于某些解决方案，如果用户想要将其现有身份从一个区域迁移到另一个区域，可能需要支持身份转移。此时也可能需要用户管理系统中的其他工作流程来启用这种性质的传输。还可能会造成违反合规性法规的风险。

管理和监控

即使将客户环境分配到各个区域，您也仍然更希望拥有管理和监控租户整体运行状况的集中化模型。事实上，随着您转向更为分散的多区域模式，对稳健的操作工具的需求将变得更加明显。关键是要制定一种能有效扩展业务覆盖范围的机制，使您能够通过集中化体验来观察 SaaS 环境的区域和全球运行状况。

可以采取多种不同的方法来集中聚合来自各区域的数据。您选择的模型取决于最适合应用程序的堆栈和工具。例如，某些解决方案可以在本地捕获数据，然后将数据复制到不同区域。其他解决方案可能会将日志数据直接传输到某个集中式存储库。

幸运的是，APN 合作伙伴社区提供了管理监控领域的多种不同解决方案，可以帮您简化多区域监控。丰富的合作伙伴解决方案集合中包括 Sumologic、New Relic、Datadog 和 Dynatrace 等，可供您考虑选择。这些产品中的每一款都采用自己的模型来捕获和分析多区域环境。

AWS 还具有联网结构，可用于构建管理环境。例如，某些组织利用跨区域 VPC 对等连接来管理分布式环境。这可以加强整个管理范围内的安全性，并可能简化自动化和部署体验。您或许已经想到了，您需要将 GDPR 纳入健康策略考虑范围。在某些情况下，您可能需要确保所记录的数据已经过完全筛查，符合 GDPR 法规中列出的要求。

部署自动化

敏捷性是促使采用 SaaS 交付模型的原因。但是，随着您转向多区域模型，这可能会增加环境的复杂性，对敏捷性目标造成不利影响。例如，当您开始考虑与在多个区域发布产品相关的自动化和 DevOps 管道影响时，部署将成为一个需要更多方参与的流程。

在多区域模型中保持敏捷性的关键在于限制每次部署引入的变化量。这实际上只是 DevOps 核心原则的延伸，额外强调了打造可通过代码管理配置所有方面的自动化、重复性部署流程。

图 4 提供了多区域管道的概念视图。我们的目标是将每次区域部署视为原本可能在单个区域中托管的环境的克隆。随着您转向多区域模型，管道必须在服务需要针对具体区域做出最小更改的情况下，将各项更改（在本例中为各微服务）部署到目标区域。最终，您对所有区域的覆盖越广泛，就越有可能发布新功能，而不会感到多区域模型妨碍您的敏捷性。

多区域管道

图 4 – 多区域部署身份验证。

尽管我们的目标是尽量减少变化，但某些区域的具体要求也可能会为您的管道添加新元素。例如，在各个区域中，很多情况下都需要向管道添加负责执行合规性验证的下游步骤。根据可能引入区域配置和部署变化的 AWS 服务的变化，可能存在一定的细微差别，但目标仍然是将其视为整体管道的扩展。

计费

与管理和监控类似，计费功能也是一项应该使用集中化模型实施的服务。您的最终目标是希望拥有一种管理 SaaS 客户账户、政策和计费活动的体验。具体思路是，应将各区域中生成 SaaS 账单所需的计量和活动数据发布到一个集中化系统，负责聚合信息并生成账单。相同的系统也会负责向各个区域推送客户状态、策略和配置的最新状态。

当然，虽然这是理想状态，但合规性和法规也会增加其复杂性。在面临主权或 GDPR 要求的情况下，您需要构建一种更为分散化的计费模型，防止客户信息离开某个区域。因此，尽管计费机制在所有区域都是相同的，但您仍然需要让各区域生成账单。这显然会给计费流程增加复杂并导致效率低下，但这种问题可能无法避免。

多区域或多可用区

对于面临区域化延迟和合规性障碍的 SaaS 组织而言，转向多区域模型往往是一种自然而然的发展趋势。但是，当纯粹将多区域作为故障转移策略加以采用时，讨论会变得更加复杂。在某些情况下，您可能会发现多可用区方法将满足解决方案的故障转移需求，而不需要承受多区域模型的额外开销。

最终，这要归结于牢牢掌握推动您采用多区域模型的因素。审视可用选项时，您应该权衡这些选择对解决方案的整体复杂性和敏捷性的影响。

实施迁移

迁移到多区域模型绝非易事。从上面介绍的各项内容中可以看到，在考虑如何在多区域环境中交付 SaaS 解决方案时，需要考虑许多因素。注册、身份、操作 – 所有这些领域都需要特定的架构策略，以满足多区域模型的要求。在着手实施转型时，您必须始终专注于为客户打造无缝体验。

多区域环境也有可能影响组织的敏捷性。您的多区域方法必须要对自动化和管理解决方案的能力提出更高的要求，以确保您可以继续快速推出新功能。

其他资源和后续步骤

多区域多 VPC 连接
视频：如何设计多区域主动-主动架构
使用 Amazon API Gateway 和 AWS Lambda 构建多区域无服务器应用程序
Amazon S3 跨区域复制
全局 DynamoDB 表
Amazon Aurora 跨区域复制

关于 AWS SaaS Factory

AWS SaaS Factory 为 AWS 合作伙伴网络 (APN) 合作伙伴提供资源，帮助加速和指导其对于 SaaS 交付模型的采用。 SaaS Factory 包括用于在 AWS 上构建 SaaS 解决方案的参考架构；自动在 AWS 上部署关键工作负载的 Quick Start；以及在 AWS 上开展 SaaS 业务的独家培训机会。我们鼓励开发 SaaS 解决方案的 APN 技术合作伙伴加入此计划！

详细了解 AWS SaaS Factory >>

作者介绍：
Tod Golding，AWS 合作伙伴解决方案架构师

本文转载自AWS技术博客。

原文链接：https://amazonaws-china.com/cn/blogs/china/architecting-multi-region-saas-solutions-on-aws/

创作场景

在 AWS 上设计多区域 SaaS 解决方案