Azure 应用服务是功能强大的 Web 应用程序托管平台。 Azure Functions 构建在应用服务基础结构之上，使你能够轻松构建无服务器和事件驱动的计算工作负载。 这两个服务经常在多租户解决方案中使用。
支持多租户的 Azure 应用服务和 Azure Functions 功能
Azure 应用服务和 Azure Functions 包括许多支持多租户的功能。
自定义域名
Azure 应用服务允许你使用通配符 DNS 和添加自己的通配符 TLS 证书。 使用特定于租户的子域时，通配符 DNS 和 TLS 证书使你能够轻松地将解决方案扩展到大量租户，而无需为每个新租户手动重新进行配置。
使用特定于租户的自定义域名时，可能需要将大量自定义域名添加到应用。 管理大量自定义域名可能很麻烦，尤其是当它们需要单独的 TLS 证书时。 应用服务提供托管的 TLS 证书，可以减少使用自定义域时所需的工作量。 但是，需要考虑一些限制，例如可将多少个自定义域应用于单个应用。
与 Azure Front Door 集成
应用程序服务和 Azure Functions 可与 Azure Front Door 集成，以充当解决方案的面向 Internet 的组件。 Azure Front Door 允许添加 Web 应用程序防火墙 (WAF) 和边缘缓存，并提供其他性能优化。 你可以根据不断变化的业务或技术要求，轻松重新配置流量流以将流量定向到不同的后端。
将 Azure Front Door 与多租户应用配合使用时，可以使用 Azure Front Door 来管理自定义域名和终止 TLS 连接。 然后为应用服务应用程序配置单个主机名，所有流量将流经该应用程序，这有助于避免在多个位置管理自定义域名。
如以上示例中所示，可以配置 Azure Front Door 以修改请求的 Host 标头。 客户端发送的原始 Host 标头通过 X-Forwarded-Host 标头传播，应用程序代码可以使用此标头将请求映射到正确的租户。
警告
如果应用程序发送 Cookie 或重定向响应，则你需要特别小心。 对请求的 Host 标头进行更改可能会使这些响应失效。 有关详细信息，请参阅主机名保留最佳做法。
可以使用专用终结点或应用服务访问限制来确保流量在到达应用之前流经 Front Door。
有关如何在多租户解决方案中使用 Azure Front Door 的详细信息，请参阅在多租户解决方案中使用 Azure Front Door
身份验证和授权
Azure 应用服务可以代表你的应用验证身份验证令牌。 当应用程序服务收到请求时，它会检查以确认是否满足以下每个条件：
- 请求包含令牌。
- 令牌有效。
- 请求已获授权。
如果不满足任何条件，则应用服务可以阻止请求，也可以将用户重定向到标识提供者，以便他们可以登录。
如果租户使用 Microsoft Entra ID 作为标识系统，你可以将 Azure 应用服务配置为使用 /common 终结点来验证用户令牌。 这可以确保无论用户的 Microsoft Entra 租户是什么，都会验证并接受其令牌。
还可将 Azure 应用服务与 Azure AD B2C 集成，以便对使用者进行身份验证。
详细信息：
访问限制
可以使用访问限制来限制发送到应用的流量。 这些限制可用于指定允许哪些 IP 地址范围或虚拟网络连接到应用。
使用多租户解决方案时，请注意访问限制规则的最大数量。 例如，如果需要针对每个租户创建访问限制规则，可能会超过允许的最大规则数量。 如果需要更多规则，请考虑部署反向代理，例如 Azure Front Door。
隔离模型
在处理使用 Azure 应用服务或 Azure Functions 的多租户系统时，需要在你想要使用的隔离级别方面做出决策。 请参阅可考虑用于多租户解决方案的租户模型以及多租户解决方案中的计算体系结构方法中提供的指导，以帮助为方案选择最佳隔离模型。
使用 Azure 应用服务和 Azure Functions 时，应了解以下关键概念：
- 在 Azure 应用服务中，计划代表托管基础结构。 应用代表该基础结构上运行的单个应用程序。 可将多个应用部署到单个计划。
- 在 Azure Functions 中，托管和应用程序也是分开的，但可以使用其他托管选项来实现弹性托管，即 Azure Functions 为你管理缩放。 为简单起见，我们在整篇文章中将托管基础结构称为计划，因为无论使用哪种托管模型，此处所述的原则都适用于应用服务和 Azure Functions。
下表汇总了 Azure 应用服务和 Azure Functions 的主要租户隔离模型之间的差异：
| 注意事项 | 共享应用 | 为每个租户部署应用并使用共享计划 | 为每个租户部署计划 |
|---|---|---|---|
| 配置隔离 | 低 | 中等。 应用级设置专用于租户，计划级设置是共享的 | 高。 每个租户都可以有自己的配置 |
| 性能隔离 | 低 | 中低。 可能受近邻干扰问题的影响 | 高 |
| 部署复杂性 | 低 | 中 | 高 |
| 操作复杂性 | 低 | 高 | 高 |
| 资源成本 | 低 | 低到高，取决于应用程序 | 高 |
| 示例方案 | 具有共享应用程序层的大型多租户解决方案 | 将无法感知租户的应用程序迁移到 Azure，同时获得一定的成本效益 | 单租户应用层 |
共享应用
可以在单个计划中部署一个共享应用程序，并为所有租户使用该共享应用程序。
这往往是最经济高效的选项，它所需的运营开销最低，因为要管理的资源更少。 可以根据负载或需求缩放整体计划，共享该计划的所有租户将受益于增加的容量。
请务必了解应用服务的配额和限制，例如可添加到单个应用的自定义域的最大数量，以及可预配的计划实例的最大数量。
要使用此模型，应用程序代码必须可以感知多租户。
为每个租户部署应用并使用共享计划
还可以选择在多个租户之间共享计划，但为每个租户部署单独的应用。 这样可以在租户之间提供逻辑隔离，并且此方法提供以下优势：
- 成本效益：通过共享托管基础结构，通常可以降低每个租户的总体成本。
- 配置分离：每个租户的应用可以应用自身的域名、TLS 证书、访问限制和令牌授权策略。
- 升级分离：每个租户的应用程序二进制文件可以独立于同一计划中的其他应用进行升级。
但是，由于计划的计算资源是共享的，因此应用可能会遇到近邻干扰问题。 此外，可部署到单个计划的应用数量是有限制的。
注意
不要为不同的租户使用部署槽。 槽不提供资源隔离。 它们专为需要在短时间内运行多个应用版本的部署方案（例如蓝绿部署和 Canary 推出策略）而设计。
为每个租户部署计划
最强的隔离级别是为租户部署专用计划。 此专用计划可确保租户充分使用分配到该计划的所有服务器资源。
使用这种方法可以缩放解决方案，以便为每个租户提供性能隔离，并避免近邻干扰问题。 但是，它的成本更高，因为资源不与多个租户共享。 此外，需要考虑可部署到单个 Azure 资源组中的最大计划数。
托管 API
可以在 Azure 应用服务和 Azure Functions 上托管 API。 要选择哪个平台取决于所需的特定功能集和缩放选项。
无论使用哪个平台来托管 API，都请考虑在 API 应用程序的前面使用 Azure API 管理。 API 管理提供许多有利于多租户解决方案的功能，包括：
- 所有身份验证的集中点。 这可能包括从令牌声明或其他请求元数据中确定租户标识符。
- 将请求路由到不同的 API 后端，此功能可能基于请求的租户标识符。 托管多个部署缩放单元，而这些缩放单元具有自身独立的 API 应用程序时，此功能可能很有帮助，但你需要为所有请求提供单个 API URL。
网络和多租户
IP 地址
许多多租户应用程序需要连接到租户的本地网络以发送数据。
如果你需要从某个已知静态 IP 地址或一系列已知静态 IP 地址发送出站流量，请考虑使用 NAT 网关。 有关如何在多租户解决方案中使用 NAT 网关的详细信息，请参阅适用于多租户的 Azure NAT 网关注意事项。 应用服务提供了有关如何与 NAT 网关集成的指导。
如果你不需要静态出站 IP 地址，而只是偶尔需要检查应用程序用于出站流量的 IP 地址，则可以查询应用服务部署的当前 IP 地址。
配额
由于应用服务本身是多租户服务，因此你需要考虑如何使用共享资源。 网络是需要特别注意的一个方面，因为有些限制会影响应用程序如何处理入站和出站网络连接，这包括源网络地址转换 (SNAT) 和 TCP 端口限制。
如果应用程序连接到大量数据库或外部服务，则应用可能会面临 SNAT 端口耗尽的风险。 一般情况下，SNAT 端口耗尽表明代码未正确重用 TCP 连接，即使在多租户解决方案中，你也应确保遵循有关重用连接的建议做法。
但是，在某些多租户解决方案中，与不同 IP 地址建立的出站连接数可能导致 SNAT 端口耗尽，即使遵循合理的编码做法，也是如此。 在这些方案中，请考虑使用下列选项之一：
- 部署 NAT 网关以增加可供应用程序使用的 SNAT 端口数。 有关如何在多租户解决方案中使用 NAT 网关的详细信息，请参阅适用于多租户的 Azure NAT 网关注意事项。
- 在连接到 Azure 服务时，请使用服务终结点绕过负载均衡器限制。
即使采取这些控制措施，也可能会因存在大量租户而接近限制，因此应该计划扩展到其他应用服务计划或部署缩放单元。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- John Downs | 首席软件工程师
其他参与者：
- Thiago Almeida | Azure Functions 首席项目经理
- 阿森·弗拉基米尔斯基|首席工程师，FastTrack for Azure
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。