你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
在多租户解决方案中使用 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 地址筛选、异地阻止或自定义 WAF 规则有要求？
- 所有租户的应用程序服务器是否都面向 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 配置文件上配置多个自定义域。
有关详细信息，请参阅将自定义域添加到 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 证书。
有关 TLS 证书的详细信息，请参阅 Azure Front Door 的端到端 TLS。
路由
多租户应用程序可能具有一个或多个为租户提供服务的应用程序标记。 标记通常用于启用多区域部署，并支持将解决方案缩放到大量租户。
Azure Front Door 具有一组强大的路由功能，可支持多种多租户体系结构。 可以使用路由在标记内的源之间分配流量，或将流量发送到特定租户的正确标记。 可以基于单个域名、通配符域名和 URL 路径配置路由。 可以使用规则引擎进一步自定义路由行为。
有关详细信息，请参阅路由体系结构概述。
规则引擎
可以使用 Azure Front Door 规则引擎自定义 Azure Front Door 在网络边缘处理请求的方式。 规则引擎使你能够在 Azure Front Door 请求处理管道中运行小型逻辑块。 可以将规则引擎用于各种任务，包括：
- 检索有关 HTTP 请求的信息，包括 URL 和路径的段，并将信息传播到请求的另一部分。
- 在发送到源之前修改 HTTP 请求的元素。
- 在返回到客户端之前修改 HTTP 响应的某些部分。
- 通过更改请求应发送到的源组来替代请求的路由配置。
下面是在多租户解决方案中使用 Azure Front Door 规则引擎的一些示例方法：
- 假设部署了一个多租户应用程序层，其中还使用了特定于租户的通配符子域，如以下示例方案中所述。 可以使用规则引擎从请求子域中提取租户标识符并将其添加到请求标头。 此规则可帮助应用程序层确定请求来自哪个租户。
- 假设你部署了一个多租户应用程序层，并使用基于路径的路由（例如，分别对租户 1 和 租户 2 使用
https://application.contoso.com/tenant1/welcome和https://application.contoso.com/tenant2/welcome）。 可以使用规则引擎从 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 指定的值。 - 一条别名为 Adventure Works Azure Front Door 终结点的 CNAME 记录。 例如，租户 1 需要配置名为
tenant1app.tenant1.com的 CNAME 记录，并将其映射到adventureworks.z01.azurefd.net。
TLS 配置
Adventure Works 及其租户需要确定颁发 TLS 证书的人员：
- 最简单的选择是使用 Azure Front Door 来颁发和管理证书，但租户不应在其 DNS 服务器上配置 CCA 记录。 如果这样做，记录可能会阻止 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 Front Door 资源限制。 例如，如果需要支持大量自定义域，则可以将域划分到多个 Azure Front Door 配置文件中，并保持在每个配置文件的限制范围内。
- 使用此方法可以限定 Azure Front Door 资源管理权限的范围。 可以使用 Azure 基于角色的访问控制 (RBAC) 授予管理员对单个标记配置文件的访问权限。
缺点
- 此方法通常会产生较高的成本，因为部署了更多配置文件。 有关详细信息，请参阅了解 Front Door 计费。
- 可以部署到单个 Azure 订阅中的 Azure Front Door 配置文件的数量是有限制的。 有关详细信息，请参阅 Front Door 配额和限制。
- 需要单独配置每个标记的 Azure Front Door 配置文件，并且需要管理每个标记的 DNS 配置、TLS 证书和 TLS 配置。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Raj Nemani | 主管、合作伙伴技术策略师
- John Downs | 首席软件工程师
其他参与者：
- Mick Alberts | 技术文档撰写人
- Fernando Antivero | 全栈开发人员及云平台工程师
- Duong Au | 高级内容开发人员、C+E 技能内容研发
- Harikrishnan M B (HARI) | Azure 网络产品经理 2
- 阿森·弗拉基米尔斯基|首席工程师，FastTrack for Azure
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。