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

Posted 2021-04-28 AWS云计算

软件即服务（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 或一般数据主权要求的区域，这通常是您唯一的选择。

在接下来的内容里，我们将介绍：

多区域身份

管理和监控

部署自动化

计费功能的思路

等相关内容

请感兴趣的同学

扫描/长按识别下方二维码

继续阅读学习！

马上点击“阅读原文”

申请并获得 AWS 中国区域账户的用户

将会获赠价值 500RMB 的 AWS 服务抵扣券！