通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

在多租户解决方案中使用 Azure API 管理

  • 项目

Azure API 管理是一个全面的 API 网关和 API 的反向代理。 它提供许多功能，包括缓存、响应模拟和开发人员门户，这些功能对以 API 为中心的应用程序非常有用。 本文总结了对多租户解决方案非常有用的 API 管理的一些关键功能。

注意

本文重点介绍当你拥有自己的多租户应用程序来托管内部或外部使用的 API 时，如何使用 API 管理。

多租户的另一种形式是将 API 管理网关作为服务提供给其他团队。 例如，一个组织可能有一个共享的 API 管理实例，多个应用程序团队部署到该实例并使用该实例。 本文不讨论这种形式的多租户。 请考虑使用工作区，这有助于你在可能具有不同访问级别的多个团队之间共享 API 管理实例。

隔离模型

API 管理通常部署为具有单个实例的共享组件，该实例为多个租户提供请求。 然而，基于租赁模型，可以通过多种方式部署 API 管理。 本文假定你使用部署标记部署解决方案。

通常，无论隔离模型如何，使用 API 管理的方式都是类似的。 本节重点介绍隔离模型在成本和复杂性方面的差异，以及每种方法如何将请求路由到后端 API 应用程序。

注意事项 具有单租户后端的共享实例 具有共享多租户后端的共享实例 每个租户的实例
支持的租户数 很多 几乎无限制 每个实例一个
成本 较低 较低 较高
部署复杂性 低：为每个标记管理单个实例 低：为每个标记管理单个实例 高：要管理的多个实例
路由配置复杂性 更高 更低 较低
容易受到近邻干扰问题的影响 是 是 否
租户级网络隔离 否 No 是
示例方案 每个租户的自定义域名 具有共享应用程序层的大型多租户解决方案 特定于租户的部署标记

共享实例隔离模型

在多个租户之间共享 API 管理实例很常见，这有助于降低成本和管理复杂性。 如何共享 API 管理实例的详细信息取决于如何将租户分配给后端 API 应用程序。

单租户后端应用程序

如果为每个租户部署不同的后端应用程序，则可以部署单个 API 管理实例，并为每个请求将流量路由到正确的租户后端。 此方法要求你使用每个租户的后端主机名配置 API 管理，或者使用其他方法将传入请求映射到正确租户的后端。

由于需要额外查找，因此这种方法可能无法扩展到共享单个 API 管理实例的大量租户。 查找租户后端时，可能还会有一些性能开销。 但是，这种性能开销的大小取决于你如何设计这种查找。

共享多租户后端应用程序

在租户共享公共后端应用程序的情况下，API 管理路由过程会得到简化，因为你可以将所有请求路由到单个后端。 如果使用通配符域或提供商颁发的域，则可以使用此方法实现几乎不受限制的缩放。 此外，由于请求不需要映射到租户的后端，因此自定义路由决策不会对性能造成影响。

每个租户的实例

在某些情况下，可以为每个租户部署 API 管理实例。 只有当你的租户数量较少，或者你有严格的合规要求限制你在租户之间共享任何基础结构时，我们才建议你采用这种方法。 例如，如果你为每个租户部署一个专用虚拟网络，那么你可能还需要为每个租户配置一个专用的 API 管理实例。

提示

如果部署多个实例的唯一原因是支持跨不同地理区域的用户，则可能需要考虑 API 管理中的多区域部署功能是否符合要求。

部署 API 管理实例时，需要考虑服务限制，包括可能适用于 Azure 订阅或区域中 API 管理实例数的任何限制。

单租户实例通常具有最少的路由配置，因为可以将所有请求路由到单个后端。 此方案不需要自定义路由决策，因此不会对性能产生额外影响。 但是，与部署共享实例相比，通常会产生更高的资源成本。 如果需要部署单租户实例，请考虑自承载网关是否允许你重用已部署的特定于租户的计算资源。

支持多租户的 API 管理功能

API 管理使用策略来实现灵活性。 可以自定义使用策略时如何验证、路由和处理请求。 当使用 API 管理设计多租户解决方案时，可以使用策略来实现其许多功能。

根据收到的请求识别租户

请考虑如何在每个传入请求中识别合适的租户。 在多租户解决方案中，必须清楚地了解谁正在发出每个请求，以便返回该特定租户的数据，而不是其他任何人的数据。

API 管理提供订阅，你可以使用这些订阅来验证请求。 这些订阅使用唯一的订阅密钥，有助于标识发出请求的订阅者。 如果选择使用订阅，请考虑如何将 API 管理订阅映射到自己的租户或客户标识符。 订阅已紧密集成到开发人员门户中。 对于大多数解决方案，使用订阅来标识租户是一种很好的做法。

或者，可以使用其他方法标识租户。 以下是在你定义的自定义策略中运行的一些方法示例：

  • 使用 URL 的自定义组件，例如子域、路径或查询字符串。 例如，在 URL https://api.contoso.com/tenant1/products 中，可以提取路径的第一部分 tenant1，并将其视为租户标识符。 同样，鉴于传入 URL https://tenant1.contoso.com/products，可以提取子域 tenant1。 若要使用此方法，请考虑从 Context.Request.Url 属性解析路径或查询字符串。

  • 使用请求标头。 例如，客户端应用程序可能会在请求中添加自定义 TenantID 标头。 若要使用此方法，请考虑从 Context.Request.Headers 集合中读取。

  • 从 JSON Web 令牌 (JWT) 中提取声明。 例如，你可能在标识提供者颁发的 JWT 中有一个自定义 tenantId 声明。 若要使用此方法，请使用 validate-jwt 策略并设置 output-token-variable-name 属性，以便策略定义可以从令牌中读取值。

  • 动态查找租户标识符。 处理请求时，可以与外部数据库或服务通信。 通过采用此方法，可以创建自定义租户映射逻辑，将逻辑租户标识符映射到特定 URL，或获取有关租户的其他信息。 若要使用此方法，请使用 send-request 策略。

    此方法可能会增加请求的延迟。 为了减轻这种影响，最好使用缓存来减少对外部 API 的调用次数。 可以使用 cache-store-value 和 cache-lookup-value 策略来实现缓存方法。 确保对影响后端查找的每个添加、删除或移动的租户都使缓存失效。

命名值

API 管理支持命名值，这是你可以在整个策略中使用的自定义配置设置。 例如，可以使用命名值来存储租户的后端 URL，然后在策略中的多个位置重用相同的值。 如果需要更新 URL，可以在一个地方更新它。

警告

在多租户解决方案中，设置已命名值的名称时一定要小心。 如果租户之间的设置有所不同，请确保在名称中包含租户标识符。 例如，在确认 tenantId 适合请求后，可以使用类似 tenantId-key:value 的模式。

包括标识符，以减少在处理另一个租户的请求时意外引用或被操纵引用另一个租户值的机会。

对传入请求进行身份验证

对 API 管理网关发出的 API 请求通常需要进行身份验证。 API 管理提供了几种对网关的传入请求进行身份验证的方法，包括 OAuth 2.0 和客户端证书。 考虑应该支持的凭据类型以及应该在哪里进行验证。 例如，考虑验证应该在 API 管理中、后端应用程序中还是在这两个地方进行。

有关详细信息，请参阅 Azure API 管理中 API 的身份验证和授权。

注意

如果使用订阅密钥或 API 密钥，那么最好使用另一种身份验证方法。

订阅密钥本身并不是一种强大的身份验证形式，但对于其他方案（例如，跟踪单个租户的 API 使用情况）非常有用。

路由到特定于租户的后端

使用 API 管理作为共享组件时，可能需要将传入的 API 请求路由到不同的特定于租户的后端。 这些后端可能位于不同的部署标记中，也可能是单个标记中的不同应用程序。 若要在策略定义中自定义路由，请使用 set-backend-service 策略。 需要指定请求应重定向到的新基 URL。

缓存响应或其他数据

API 管理具有强大的缓存功能，可用于缓存整个 HTTP 响应或任何其他数据。 例如，如果使用自定义逻辑或从外部服务查找映射，则可以将缓存用于租户映射。

使用 cache-store-value 和 cache-lookup-value 策略来实现缓存方法。

警告

在多租户解决方案中，设置缓存键时请务必小心。 如果缓存的数据可能因租户而异，请确保在缓存键中包含租户标识符。

包括标识符，以减少在处理另一个租户的请求时意外引用或被操纵引用另一个租户值的机会。

自定义域

使用 API 管理为 API 网关和开发人员门户配置自己的自定义域。 在某些层中，可以配置通配符域或多个完全限定的域名 (FQDN)。

还可以将 API 管理与 Azure Front Door 等服务一起使用。 在此类配置中，Azure Front Door 经常处理自定义域和传输层安全性 (TLS) 证书，并通过使用单个域名与 API 管理进行通信。 如果来自客户端的原始 URL 包含需要发送到 API 管理实例以供稍后处理的租户信息，请考虑使用 X-Forwarded-Host 请求标头，或使用 Azure Front Door 规则将信息作为 HTTP 标头传递。

速率限制

在多租户解决方案中应用配额或速率限制很常见。 速率限制有助于缓解近邻干扰问题。 还可以使用速率限制来强制实施服务质量，并区分不同的定价层。

使用 API 管理强制实施特定于租户的速率限制。 如果使用特定于租户的订阅，请考虑使用配额策略为每个订阅强制实施配额。 或者，请考虑使用 quota-by-key 配额策略，通过使用任何其他速率限制键（例如，从请求 URL 或 JWT 获取的租户标识符）来强制实施配额。

货币化

API 管理文档提供有关实现 API 货币化的广泛指导（包括示例实现）。 货币化方法结合了 API 管理的许多功能，这样开发人员就可以发布 API、管理订阅，并根据不同的使用模式收费。

容量管理

API 管理实例支持一定数量的容量，这表示可用于处理请求的资源。 当使用复杂的策略或向实例部署更多 API 时，会消耗更多的容量。 可以通过多种方式管理实例的容量，例如购买更多单元。 还可以动态缩放实例的容量。

一些多租户实例可能比单租户实例消耗更多的容量，例如，如果使用许多策略将请求路由到不同的租户后端。 仔细考虑容量规划，如果看到使用量增加，请计划缩放实例的容量。 还应测试解决方案的性能，以便提前了解容量需求。

有关缩放 API 管理的详细信息，请参阅升级和缩放 Azure API 管理实例。

多区域部署

API 管理支持多区域部署，这意味着你可以跨多个 Azure 区域部署单个逻辑 API 管理资源，而无需将其配置复制到单独的资源上。 当在全球范围内分发或复制解决方案时，此功能特别有用。 可以有效地跨多个区域部署 API 管理实例群，从而实现低延迟请求处理，并将其作为单个逻辑实例进行管理。

但是，如果需要完全隔离的 API 管理实例，也可以选择将独立的 API 管理资源部署到不同的区域。 这种方法为每个 API 管理实例分离管理平面。

作者

本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。

主要作者：

其他参与者：

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

后续步骤

请参阅多租户解决方案中集成的体系结构方法。