在多租户解决方案中使用 Azure Front Door

Azure Front Door 是一个现代云内容分发网络（CDN），可在用户与应用程序的静态和动态 Web 内容之间提供快速、可靠的访问。 本文介绍在多租户系统中工作时有用的 Azure Front Door 的一些功能。 它还提供其他相关指南和示例。

使用 Azure Front Door 作为多租户解决方案的一部分时，需要根据解决方案的设计和要求做出一些决策。 请考虑下列因素：

• 请考虑你当前拥有的租户数以及你希望将来拥有的租户数。

• 确定是否在多个租户之间共享应用程序层、部署多个单租户应用程序实例，还是部署多个租户共享的单独部署标记。

• 确定租户是否要自带域名。

• 确定是否要使用通配符域。

• 评估是否需要使用自己的传输层安全性（TLS）证书，或者Microsoft是否会管理 TLS 证书。

• 请考虑适用于 Azure Front Door 的配额和限制。 确定随着解决方案的扩展可能会遇到的限制。 如果预计接近这些限制值，请考虑使用多个 Azure Front Door 配置文件或调整使用 Azure Front Door 的方式以保持在可接受的范围内。 高级 SKU 的限制高于标准 SKU。

• 确定你或租户对 IP 地址筛选、异地阻止还是自定义 Web 应用程序防火墙规则有要求。

• 验证所有租户的应用程序服务器是否都面向 Internet。

支持多租户的 Azure Front Door 功能

本部分介绍适用于多租户解决方案的 Azure Front Door 的几个主要功能。 其中介绍了 Azure Front Door 如何帮助你配置自定义域，包括通配符域和 TLS 证书的相关信息。 它还总结了如何使用 Azure Front Door 路由功能来支持多租户。

自定义域

Azure Front Door 为创建的每个终结点提供默认主机名，例如 contoso.z01.azurefd.net。 但对于大多数解决方案，会将自己的域名与 Azure Front Door 终结点相关联。 自定义域名使你能够使用自己的品牌，并根据客户端请求中包含的主机名配置路由。

在多租户解决方案中，可以使用特定于租户的域名或子域，并将 Azure Front Door 配置为将租户的流量路由到该租户工作负荷的正确源组。 例如，可以配置自定义域名，例如 tenant1.app.contoso.com。 可以在单个 Azure Front Door 配置文件上配置多个自定义域。

有关详细信息，请参阅 将自定义域添加到 Azure Front Door。

通配符域

使用共享主干域和特定于租户的子域时，通配符域可简化域名系统 (DNS) 记录配置及 Azure Front Door 流量路由配置。 例如，假设您的租户通过使用类似tenant1.app.contoso.com和tenant2.app.contoso.com的子域来访问他们的应用程序。 可以配置通配符域*.app.contoso.com，而无需单独配置每个租户的特定域。

Azure Front Door 支持创建自定义域，这些域使用通配符。 然后，可以为到达通配符域的请求配置路由。 载入新租户时，无需重新配置 DNS 服务器、颁发新的 TLS 证书或更新 Azure Front Door 配置文件的配置。

如果将所有流量发送到单个源组，通配符域正常发挥作用。 但是，如果解决方案具有单独的标记，则单级通配符域是不够的。 要么需要使用多级词干域，要么提供额外的配置。 例如，您可以重写每个租户子域的路由。 有关详细信息，请参阅 在多租户解决方案中使用域名时的注意事项。

Azure Front Door 不会为 通配符域颁发托管 TLS 证书，因此需要购买并提供自己的证书。

托管 TLS 证书

获取和安装 TLS 证书可能是一个复杂且容易出错的过程。 TLS 证书在一段时间后过期，通常是一年，需要重新发出并重新安装，以避免应用程序流量中断。 使用 Azure Front Door 管理的 TLS 证书时，Microsoft负责为自定义域颁发、安装和续订证书。

源应用程序可能托管在另一个 Azure 服务上，该服务还提供托管 TLS 证书，例如 Azure 应用服务。 Azure Front Door 以透明方式与其他服务配合使用，以同步 TLS 证书。

如果租户可以提供自己的自定义域，并且你希望 Azure Front Door 为这些域名颁发证书，则租户不应在其 DNS 服务器上配置证书颁发机构授权（CAA）记录。 这些记录可能会阻止 Azure Front Door 代表租户颁发证书。 有关多租户的详细信息，请参阅 多租户解决方案中的 TLS 和 SSL 证书。 有关 Azure Front Door 的详细信息，请参阅 使用 Azure Front Door 进行 TLS 加密。

路线规划

多租户应用程序可能有一个或多个为租户提供服务的应用程序标记。 标记通常用于启用多区域部署，并支持将解决方案缩放到大量租户。

Azure Front Door 具有一组强大的路由功能，可支持许多多租户体系结构。 可以使用路由在标记内的源之间分配流量，或将流量发送到特定租户的正确标记。 可以根据单个域名、通配符域名和 URL 路径配置路由。 可以使用规则引擎进一步自定义路由行为。

有关详细信息，请参阅路由体系结构概述。

规则引擎

可以使用 Azure Front Door 规则引擎自定义 Azure Front Door 在网络边缘处理请求的方式。 通过规则引擎，可以在 Azure Front Door 请求处理管道中运行少量逻辑块。 可以将规则引擎用于包括但不限于以下列表项的各种任务：

• 检索有关 HTTP 请求的信息，包括 URL 和路径的段，并将信息传播到请求的另一部分。

• 在发送到源之前修改 HTTP 请求的元素。

• 在返回到客户端之前修改 HTTP 响应的元素。

• 通过更改请求应发送到的源组来替代请求的路由配置。

以下示例方法在多租户解决方案中使用 Azure Front Door 规则引擎：

• 假设你部署了一个多租户应用程序层，其中还使用特定于租户的通配符子域，如以下示例方案中所述。 可以使用规则引擎从请求子域中提取租户标识符，并将其添加到请求标头。 此规则可以帮助应用程序层确定请求来自哪个租户。

• 假设您部署了一个多租户应用层，并使用基于路径的路由，例如将https://application.contoso.com/tenant1/welcome用于租户1，将https://application.contoso.com/tenant2/welcome用于租户2。 可以使用规则引擎从 URL 路径段中提取租户标识符段，并重写 URL 以将租户标识符包含在查询字符串参数或请求标头中供应用程序使用。

有关详细信息，请参阅 Azure Front Door 规则引擎。

示例方案

以下示例方案演示了如何在 Azure Front Door 中配置各种多租户体系结构，以及做出的决策如何影响 DNS 和 TLS 配置。

许多多租户解决方案实现部署标记模式。 使用此部署方法时，通常会部署单个共享的 Azure Front Door 配置文件，并使用 Azure Front Door 将传入流量路由到相应的标记。 此部署模型是最常见的部署模型，本文中的方案 1 到 4 介绍了如何使用它来满足一系列要求。

但是，在某些情况下，可能会在解决方案的每个标记中部署 Azure Front Door 配置文件。 方案 5 描述了此部署模型。

方案 1：提供程序管理的通配符域，单个标记

Contoso 正在构建一个小型多租户解决方案。 该公司在单个区域中部署一个标记，该标记为其所有租户提供服务。 所有请求都路由到同一应用程序服务器。 Contoso 决定使用通配符域来管理所有租户，例如 tenant1.contoso.com 和 tenant2.contoso.com。

Contoso 使用以下配置部署 Azure Front Door。

DNS 配置

一次性配置： Contoso 配置两个 DNS 条目。

• *.contoso.com 的通配符 TXT 记录设置为 Azure Front Door 在自定义域载入过程中指定的值。

• 通配符 CNAME 记录 *.contoso.com，它是 Contoso 的 Azure Front Door 终结点的别名：contoso.z01.azurefd.net。

载入新租户时： 不需要额外的配置。

TLS 配置

一次性配置： Contoso 购买通配符 TLS 证书，将其添加到密钥保管库，并授予 Azure Front Door 对保管库的访问权限。

载入新租户时： 不需要额外的配置。

Azure Front Door 配置

一次性配置：Contoso 创建一个 Azure Front Door 配置文件和单个终结点。

• 他们添加一个具有名称 *.contoso.com 的自定义域，并将其通配符 TLS 证书与自定义域资源相关联。

• 他们为其应用程序服务器配置了一个仅包含单个源的源组。

• 配置路由以将自定义域连接到源组。

载入新租户时： 不需要额外的配置。

优点

• 此方案相对容易配置，为客户提供 Contoso 品牌 URL。

• 此方法支持大量租户。

• 载入新租户时，Contoso 无需更改 Azure Front Door、DNS 或 TLS 证书。

缺点

• 此方法不容易扩展到单个应用程序标记或区域之外。

• Contoso 需要购买通配符 TLS 证书，并在证书过期时续订并安装该证书。

方案 2：提供程序管理的通配符域，多个标记

Proseware 正在跨部署到澳大利亚和欧洲的多个标记构建多租户解决方案。 单个区域内的所有请求都由该区域内的标记提供服务。 与 Contoso 一样，Proseware 决定对所有租户使用通配符域，例如 tenant1.proseware.com 和 tenant2.proseware.com。

Proseware 使用以下配置部署 Azure Front Door：

DNS 配置

一次性配置： Proseware 配置两个 DNS 条目。

• *.proseware.com 的通配符 TXT 记录设置为 Azure Front Door 在自定义域载入过程中指定的值。

• 通配符 CNAME 记录 *.proseware.com，它是 Proseware 的 Azure Front Door 终结点的别名：proseware.z01.azurefd.net。

载入新租户时： 不需要额外的配置。

TLS 配置

一次性配置： Proseware 购买通配符 TLS 证书，将其添加到密钥保管库，并授予 Azure Front Door 对保管库的访问权限。

载入新租户时： 不需要额外的配置。

Azure Front Door 配置

一次性配置：Proseware 创建一个 Azure Front Door 配置文件和单个终结点。 公司为每个区域中的每个应用程序标记或服务器配置多个源组。

载入新租户时： Proseware 将自定义域资源添加到 Azure Front Door。

• 他们使用该名称 *.proseware.com ，并将其通配符 TLS 证书与自定义域资源相关联。

• 它们创建一个路由来指定租户的请求应被定向到哪个源组或标记。 在上图中， tenant1.proseware.com 路由到澳大利亚区域中的源组，以及 tenant2.proseware.com 路由到欧洲区域中的源组。

优点

• 载入新租户时，不需要 DNS 或 TLS 配置更改。

• Proseware 维护 Azure Front Door 的单个实例，以将流量路由到跨多个区域的多个标记。

缺点

• 每次加入新租户时，Proseware 都需要重新配置 Azure Front Door。

• Proseware 需要注意 Azure Front Door 的配额和限制，特别是在路由数量、自定义域，以及 复合路由限制方面。

• Proseware 需要购买通配符 TLS 证书。

• Proseware 负责在证书过期时续订和安装证书。

方案 3：提供程序管理的基于标记的通配符子域

Fabrikam 正在构建多租户解决方案。 该公司在澳大利亚和美国部署邮票。 单个区域内的所有请求都由该区域内的标记提供服务。 Fabrikam 使用基于邮票的词干域，例如“tenant1.australia.fabrikam.com”、 “tenant2.australia.fabrikam.com” 和 “tenant3.us.fabrikam.com”。

公司使用以下配置部署 Azure Front Door。

DNS 配置

一次性配置： Fabrikam 为每个标记配置以下两个通配符 DNS 条目。

• 对于每个戳，通配符 TXT 记录 *.australia.fabrikam.com 和 *.us.fabrikam.com 设置为 Azure Front Door 在自定义域接入过程中指定的值。

• 对于每个戳，通配符 CNAME 记录 *.australia.fabrikam.com 和 *.us.fabrikam.com，它们都是 Azure Front Door 终结点的别名：fabrikam.z01.azurefd.net。

载入新租户时： 不需要额外的配置。

TLS 配置

一次性配置： Fabrikam 为每个标记购买通配符 TLS 证书，将其添加到密钥保管库，并授予 Azure Front Door 对保管库的访问权限。

载入新租户时： 不需要额外的配置。

Azure Front Door 配置

一次性配置：Fabrikam 创建一个 Azure Front Door 配置文件和单个终结点。

• 他们为每个标记配置一个源组。

• 他们使用通配符为每个基于标记的子域创建自定义域：*.australia.fabrikam.com 和 *.us.fabrikam.com。

• 为每个邮票的自定义域名创建一个路由，以将流量发送到相应的源组。

载入新租户时： 不需要额外的配置。

优点

• 此方法使 Fabrikam 能够跨多个标记扩展到大量租户。

• 载入新租户时，不需要 DNS 或 TLS 配置更改。

• Fabrikam 维护 Azure Front Door 的单个实例，以将流量路由到跨多个区域的多个标记。

缺点

• 由于 URL 使用多部分词干域结构，因此用户可以使用的 URL 可能更为复杂。

• Fabrikam 需要购买多个通配符 TLS 证书。

• Fabrikam 负责在 TLS 证书过期时续订和安装这些证书。

方案 4：虚域

Adventure Works Cycles 正在构建多租户解决方案。 该公司在澳大利亚和美国等多个区域部署邮票。 单个区域内的所有请求都由该区域内的标记提供服务。 Adventure Works 允许其租户自带域名。 例如，租户 1 可能配置自定义域名，例如 tenant1app.tenant1.com。

公司使用以下配置部署 Azure Front Door。

DNS 配置

一次性配置： 没有。

载入新租户时： 租户需要在自己的 DNS 服务器上创建两条记录。

• TXT 记录用于域验证。 例如，租户 1 需要配置命名 tenant1app.tenant1.com 的 TXT 记录，并将其设置为 Azure Front Door 在自定义域载入过程中指定的值。

• CNAME 记录是 Adventure Works 的 Azure Front Door endpoint 的别名。 例如，租户 1 需要配置命名为 tenant1app.tenant1.com 的 CNAME 记录，并将其映射到 adventureworks.z01.azurefd.net。

TLS 配置

Adventure Works 及其租户需要确定谁颁发 TLS 证书：

• 最简单的选项是使用 Azure Front Door 颁发和管理证书。 但是，租户不应在其 DNS 服务器上配置 CAA 记录。 如果这样做，记录可能会阻止 Azure Front Door 证书颁发机构颁发证书。

• 或者，租户可以提供自己的证书。 他们需要使用 Adventure Works 将证书上传到密钥保管库，并提供对 Azure Front Door 的访问权限。

Azure Front Door 配置

一次性配置：Adventure Works 创建一个 Azure Front Door 配置文件和单个终结点。 他们为每个标记配置一个源组。 它们不会创建自定义域资源或路由。

载入新租户时： Adventure Works 将自定义域资源添加到 Azure Front Door。

• 它们使用租户提供的域名，并将相应的 TLS 证书与自定义域资源相关联。

• 然后，创建路由以指定租户请求应被定向到哪个源组或标签。 在上图中， tenant1app.tenant1.com 路由到澳大利亚区域中的源组，并 tenant2app.tenant3.com 路由到美国区域中的源组。

优点

• 客户可以提供自己的域名。 Azure Front Door 以透明方式将请求路由到多租户解决方案。

• Adventure Works 维护 Azure Front Door 的单个实例，以将流量路由到跨多个区域的多个标记。

缺点

• Adventure Works 每次加入新租户时都需要重新配置 Azure Front Door。

• 租户需要参与载入过程。 他们需要进行 DNS 更改，并可能颁发 TLS 证书。

• 租户控制其 DNS 记录。 对 DNS 记录的更改可能会影响其访问 Adventure Works 解决方案的能力。

• Adventure Works 需要注意 Azure Front Door 配额和限制，尤其是路由和自定义域的数量以及 复合路由限制。

方案 5：每个标记的 Azure Front Door 配置文件

可以为每个标记部署一个 Azure Front Door 配置文件。 如果你有 10 张邮票，就会部署 10 个 Azure Front Door 实例。 如果需要限制每个标记的 Azure Front Door 配置的管理访问权限，此方法非常有用。 如果需要使用多个 Azure Front Door 配置文件来避免超过资源配额或限制，则它还非常有用。

如果你有一个为多个租户提供服务的标记，则需要考虑如何将流量路由到每个租户。 查看前面方案中介绍的方法。 请考虑组合方法以满足你的要求。

优点

• 如果跨多个配置文件扩展配置，则不太可能达到 Azure Front Door 资源限制。 例如，如果需要支持大量自定义域，则可以将域划分为多个 Azure Front Door 配置文件，并保持在每个配置文件的限制范围内。

• 使用此方法可以限定 Azure Front Door 资源管理权限的范围。 可以使用 Azure 基于角色的访问控制授予管理员对单个标记配置文件的访问权限。

缺点

• 此方法通常会产生较高的成本，因为部署了更多配置文件。 有关详细信息，请参阅了解 Azure Front Door 计费。

• 可以部署到单个 Azure 订阅中的 Azure Front Door 配置文件的数量是有限制的。 有关详细信息，请参阅 Azure Front Door 配额和限制。

• 需要单独配置每个标记的 Azure Front Door 配置文件，并且需要管理每个标记的 DNS 配置、TLS 证书和 TLS 配置。

供稿人

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

• John Downs |Azure 模式和做法的主要软件工程师
• Raj Nemani |合作伙伴技术策略师主管

其他参与者：

• 费尔南多·安蒂弗罗 |Fullstack 开发人员和云平台工程师
• Duong Au | 高级内容开发人员、C+E 技能内容研发
• 哈里克里什南 M B （哈里） |产品管理器 2，Azure 网络
• 阿森·弗拉基米尔斯基 | 客户首席工程师，FastTrack for Azure

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤

• 培训：Azure Front Door 简介
• Azure Front Door 简介
• 什么是 Azure Front Door？

相关资源

• 在 Azure 上构建多租户解决方案
• 用于在 Azure 上设计和生成多租户解决方案的清单
• 考虑用于多租户解决方案的租户模型