SaaS 应用程序在 AWS 上的租户路由策略 网络与内容交付

SaaS 应用程序的租户路由策略

主要要点

A SaaS 提供商面临的一个主要挑战是设计安全且可扩展的租户路由机制，以识别租户并将请求路由到适当的资源。有效的租户路由不仅确保了资源的隔离性，还增强了可扩展性和安全性。本文将探讨在 AWS 上的多租户 SaaS 环境中如何路由 HTTP 请求，讨论策略、最佳实践及示例场景。

对于传输层的路由策略，请参考 SaaS 的传输层租户路由方法

SaaS 中的租户路由概述

租户路由取决于您的 SaaS 架构模型。在 池模型 中，多个租户共享基础设施资源，因此不需要路由，只需一个资源即可处理所有租户的请求。而 硅体模型 则为每个租户专用基础设施资源，这种情况下，租户路由显得尤为重要，用于将进入的请求路由到特定的租户资源。

桥接模型 则将硅体模型与池模型结合，根据您的分层策略或架构中微服务的情况，可能使用多种路由机制进行路由。

租户路由策略

租户路由策略可以分为两大类：

基于域名的路由

在基于域名的路由中，您为每个租户分配一个独特的主机名。常见的方法是为每个租户使用一个子域名例如 tenant1examplecom。基于域名路由的一个主要优势是简单性。通过利用内置的 DNS 基础设施，您可以从主机名获取租户上下文和路由。虽然这种方法在很多场景中有效，但在复杂场景下可能缺乏灵活性和定制化。

考虑事项和最佳实践

个性化域名：为了提供品牌效益，SaaS 提供商通常允许租户选择自定义的个性化子域名。为了加快租户的入驻，您可以最初生成随机的唯一个性化域名，然后再允许后期的自定义。

自带域名BYOD：为了提供额外的品牌效益，SaaS 提供商可以允许租户使用顶级域名。然而，由于管理复杂度高，这种方法并不常见。使用子域名时，SaaS 提供商可以控制域名所有权和 TLS 证书，而使用顶级域名时，租户可能需要管理自己的域名。因此，在品牌效益和额外的域名委派、验证及 TLS 证书管理流程之间需要权衡。

例如，可以使用 AWS Certificate Manager (ACM) 自动化 TLS 证书的续期。这通常在租户入驻时通过电子邮件或 DNS 验证域名所有权。此外，某些企业客户可能需要手动处理，以保持对其域名和 TLS 证书的严格控制。

租户目录：基于域名的路由依赖于用户记住其租户URL。然而，一些用户可能会忘记或在直接访问您的 SaaS 解决方案时需要额外的指导。因此，考虑创建一种体验，允许用户根据其电子邮件地址或用户标识符识别其租户。下图是这类体验的示例。

图 2 您可以为租户提供的用户体验示例。

使用 Amazon Route 53 和应用负载均衡器的示例场景

实施基于域名的路由依赖于您选择的 AWS 服务来路由进入请求。在这个示例中，您使用应用负载均衡器，并根据进入请求的主机头配置条件逻辑，使用 监听器规则。在为每个租户配置时，您设置路由，确保用户被引导到相应的租户资源。

图 3 使用应用负载均衡器中的监听器规则的基于域名的路由示例。

Amazon Route 53 的 DNS：HTTP 请求使用 DNS 作为初始入口。在这个示例中，您可以 配置 Amazon Route 53 的别名 DNS 记录，将所有与 examplecom 子域相关的流量路由到应用负载均衡器。

使用应用负载均衡器的主机基础监听器规则：当流量路由到负载均衡器时，它包含一个 HTTP Host 头。例如 tenant1examplecom。您接着将请求转发到对应租户的 目标，即专门为租户分配的资源。

租户入驻：在考虑租户路由时，需要将其视为 租户入驻的一部分。例如，当新 SaaS 客户注册时，您的租户入驻服务会根据租户的 分级 决定是否需要配置新基础设施。如果需要，您还需在进行基础设施配置的同时配置租户路由。在这一情况下，需要为新租户的基础设施配置对应的主机基础监听器规则。

请注意，这只是基于域名的路由方法的一个示例。虽然它使用应用负载均衡器，但该概念同样适用于其他技术实现。

基于数据的路由

现在，让我们看看基于数据的路由。在 SaaS 应用程序中，一个关键的 设计原则 是将用户身份绑定到租户身份。这生成的 SaaS 身份在系统的每一层中都得到流转，便于访问租户上下文。在基于数据的路由中，您可以将这一身份包含在 HTTP 请求的组成部分中，如头部、cookie、URL路径或URI或请求主体之中。接着，您可以提取这些数据，动态地将进入的请求导向适当的租户资源。

基于数据的路由的一个主要优势是灵活性。然而，由于此方法需要额外计算以决定路由，因此需要谨慎设计，以应对复杂性和运维开销，尤其是在大规模 SaaS 环境中。

考虑事项和最佳实践

租户身份管理：在基于数据的路由中，常见的方法是在用户身份验证后获取租户上下文，例如 API 密钥或 OAuth 客户端 ID。不过，这种方法假设 SaaS 应用程序拥有集中身份服务。在某些情况下，SaaS 应用程序可能为每个租户设有独立身份服务。在这种情况下，您在身份验证之前需要租户上下文，以便确定合适的身份服务。此时，基于域名的路由可能是更合适的选择。

通配符子域名：自动化对于 SaaS 解决方案至关重要，因此，流行的方法是为每个租户提供子域名。使用通配符子域名时，您只需配置一次 DNS，而无需在每次新增租户时再次进行 DNS 操作。例如，您可以 配置 Amazon CloudFront 使用通配符替代域名 examplecom，该服务将把任何符合该模式的流量路由到应用所在的源上。然后，您可以在应用中提取租户上下文，并将请求路由到相应的租户。通配符子域名受到 Amazon API Gateway、应用负载均衡器 和 AWS Amplify 等服务的支持。

成本与性能优化与缓存：执行路由逻辑会产生计算成本和性能开销。因此，请考虑最小化执行频率。例如，您可以仅在初始身份验证过程中执行路由逻辑，随后来自同一用户或租户的请求则可以利用缓存的路由决策。

高级上下文：在某些用例中，您可能需要额外的租户上下文，例如后端资源、应用程序版本或从 CloudFront 头部 提取的地理位置数据，这在多区域架构中尤其有用。在这种情况下，考虑将这些详细的租户信息存储在低延迟的键值存储中，如 Amazon CloudFront KeyValueStore 和 Amazon DynamoDB。 这样，您可以有效地获取这些详细信息以进行路由。

使用 Amazon Route 53 和 CloudFront 的示例场景

与基于域名的路由类似，基于数据的路由的实现取决于您选择的租户路由服务来处理输入请求。在这个示例中，您使用 CloudFront 作为应用程序的第一个入口点。您通过在 Lambda@Edge 中配置路由逻辑，通过获取租户上下文如 tenantid来选择源，从而有条件地转发请求。

图 4 使用 Lambda@Edge 在 CloudFront 上进行数据驱动路由的示例。

与 Amazon Cognito 的身份验证：为获取租户上下文，您首先使用身份提供者如 Amazon Cognito对用户进行身份验证。身份验证后，身份提供者会发出一个 JSON Web Token (JWT)，该令牌包含用户所属的租户信息。接下来，您将在后续的 HTTP 请求中以授权 HTTP 头的形式发送该令牌。

Amazon Route 53 的 DNS：在数据驱动的路由中，您可以使用一个单一域名，例如 wwwexamplecom，以允许所有租户访问应用程序，并在 HTTP 头中嵌入租户上下文。在这个示例中，您可以 配置 Amazon Route 53 的别名 DNS 记录，将与 wwwexamplecom 相关的所有流量路由到 CloudFront 分发。

基于身份验证的 Lambda@Edge 路由：当流量路由到 CloudFront 分发时，它包含一个 HTTP 授权头，其中包含先前从身份提供者获取的编码 JWT。JWT 包含用户的租户上下文，例如 tenantidtenant1。然后您可以配置 Lambda@Edge 来解码 JWT 并提取租户上下文。为了验证 JWT，您需要从身份提供者获取公钥。验证完成后，您将请求转发到属于该租户的源。有关此过程的更多详细信息，请参阅 Lambda@Edge 和 JWT 的授权。

租户入驻：在考虑租户路由时，需将其视为 租户入驻的一部分。例如，当您为新租户配置基础设施时，可以更新 Lambda@Edge 路由逻辑以适应新租户。更加可扩展的方法是将租户与源的映射保存在低延迟的键值存储中。在 Lambda@Edge 逻辑中引用此映射，以做出路由决策。当新增租户入驻时，只需增加新条目以适应新的路由。

租户路由的实施

租户路由的实施因您的 SaaS 架构而异，特别是用于处理 SaaS 应用程序入口的服务。当选择服务时，请考虑其路由能力，以及性能、安全和成本等更普遍的需求。

例如，您可以不仅使用 CloudFront 和 Lambda@Edge 来执行基于数据的路由，还可以降低延迟并 防范 DDoS 攻击。

另一个示例是使用 HTTP 反向代理。其轻量级特性使得您能够高效地执行基于数据的路由。这在 Kubernetes 架构中很常见，您还可以使用服务网格来管理经过身份验证的请求及路由。要了解更多信息，请参见 在 Amazon EKS 上使用 SaaS 身份和路由。

另一种实现方式是使用 API 网关，它提供 通配符自定义域名 和 Lambda 授权者，支持基于域名和基于数据的路由方法。此外，API 网关因其支持流行的 SaaS 应用而受到欢迎，它可按租户请求进行 流量限制，以最大程度减少 噪声邻居 对性能的影响。

可扩展性与分片考虑

无论租户路由采用何种方法，可扩展性都是您在增长和增加更多租户时的重要考虑因素。

请注意， 服务配额 可能会限制路由逻辑中的最大路由数量。例如，在应用负载均衡器的场景中，您依赖租户的监听器规则。在 CloudFront 的场景中，您依赖于 Lambda@Edge，并且针对每个分发和每秒请求的函数都有配额。此外，CloudFront 对每个分发的域名和 SSL 证书也有所配额。这些限制可能导致不同的 架构决策。

一种高阶方法来克服这些规模限制是采用 [基于单元的架构](https//docsawsamazoncom/wellarchitected/latest/reducingscopeofimpactwithcellbased