多租户解决方案中计算的体系结构方法

大多数基于云的解决方案由计算资源组成。 这些资源可以包括 Web 层和应用程序层、批处理处理器、计划作业或专用资源，例如 GPU 和高性能计算。 多租户解决方案通常受益于共享计算资源，因为每个基础结构的租户密度越高，可降低运营成本并简化管理。 应考虑隔离要求和共享基础结构的影响。

本文提供有关解决方案架构师在规划多租户计算层时要考虑的关键注意事项和要求的指导。 本指南包括将多租户应用于计算服务的常见的应用模式，以及需避免的反模式。

关键考虑因素和要求

多租户和隔离模型都会影响计算资源的扩展性、性能、状态管理和安全性。 以下部分查看在规划多租户计算解决方案时必须做出的关键决策。

规模

随着需求的变化，系统必须能够充分执行。 随着租户数量和流量的增加，可能需要缩放资源以满足不断增长的需求并维持可接受的性能。 同样，当活动用户数或流量减少时，应自动降低计算容量以降低成本。 但是，调整容量时，应最大程度地减少用户的任何中断。

如果为每个租户部署专用资源，则可以灵活地独立缩放每个租户的资源。 在计算资源在多个租户之间共享的解决方案中，缩放这些资源允许所有租户从增加的容量中获益。 但是，当规模不足以处理其总体负载时，所有租户都会遭受影响。 有关详细信息，请参阅 Noisy Neighbor antipattern。

生成云解决方案时，可以选择是 水平缩放还是垂直缩放。 在拥有越来越多的租户的多租户解决方案中，水平缩放通常提供更大的灵活性和更高的整体缩放上限。

通常在应用程序处于负载状态时才会发现性能问题。 可以使用完全托管的服务（如 Azure 负载测试）来了解应用程序在压力下如何运行。

缩放触发器

无论使用哪种方法来缩放，通常需要规划导致组件缩放的触发器。 共享组件时，请考虑每个租户的工作负荷模式，以确保预配的容量满足所需的总需求。 此方法有助于防止资源争用，并减少租户遇到 干扰邻居问题的可能性。 您还可以通过考虑租户数量来规划扩展容量。 例如，如果衡量为 100 个租户服务所使用的资源，那么随着更多租户的加入，可以计划资源扩展，这样每增加 100 个租户，资源就翻倍。

国家

计算资源可以是 无状态的，也可以是 有状态的。 无状态组件不会在请求之间维护任何数据。 从可伸缩性的角度来看，无状态组件通常易于横向扩展，因为可以快速添加新的辅助角色、实例或节点。 无状态组件还可以立即开始处理请求。 如果体系结构支持实例重新用途，还可以将实例从一个租户重新分配给另一个租户。

可以根据状态类型进一步细分有状态资源。 持久状态 是需要永久存储的数据。 在云解决方案中，请避免在计算层中存储持久性状态。 请改用数据库或存储帐户等存储服务。 暂时状态 是临时存储的数据。 它包括只读内存中缓存和本地磁盘上的临时文件的存储。

暂时性状态通常有助于通过减少对后端存储服务的请求数来提高应用程序层的性能。 例如，当你使用内存中缓存时，你可能能够在不连接到数据库的情况下提供读取请求，而无需执行最近在为另一个请求提供服务时执行的密集型查询。

在延迟敏感的应用程序中，缓存解除冻结的成本可能会变得很大。 如果每个租户需要缓存不同的数据，多租户解决方案可能会恶化此问题。 为了缓解此问题，某些解决方案应用 会话相关性。 此方法可确保同一计算工作器节点处理特定用户或租户的所有请求。 会话相关性可以提高应用程序层有效使用其缓存的能力。 但是，会话相关性也使跨工作节点的缩放和流量负载均衡更加复杂。 请仔细考虑这一权衡。 对于许多应用程序，不需要会话关联。

还可以将数据存储在外部缓存中，例如 Azure Redis 缓存。 外部缓存针对低延迟数据检索进行优化，同时将状态与计算资源隔离，以便可以单独缩放和管理它们。 在许多解决方案中，外部缓存使你能够提高应用程序性能，同时保持计算层无状态。

隔离

设计多租户计算层时，有多个租户隔离选项。 可以为所有租户部署 共享计算资源 、单个租户 的专用计算资源 ，或位于这些极端之间 半隔离的方法 。 每个选项都有权衡。 为了帮助你确定最适合解决方案的选项，请考虑隔离要求。

你可能会担心租户的逻辑隔离，以及如何将适用于每个租户的管理责任或策略进行区分。 或者，可能需要为特定租户部署不同的资源配置，例如部署特定的虚拟机 （VM） SKU 以满足租户的工作负荷。

根据所选的隔离模型，确保租户数据保持正确隔离，即使组件故障或中断发生。 请考虑在常规自动化测试过程中使用 Azure Chaos Studio 来引入模拟实际中断的故障。 此测试有助于验证您的解决方案是否保持适当的租户隔离，并在压力下继续正常运行。

要考虑的方法和模式

自动缩放

Azure 计算服务提供缩放工作负荷的各种功能。 许多计算服务支持自动缩放，这要求确定何时进行缩放以及设置最小和最大缩放级别。 特定的缩放选项取决于所使用的计算服务。 请参阅以下示例服务或组件：

• Azure 应用服务：指定自动缩放规则以根据您的要求调整基础设施的规模。

• Azure Functions： 从 多个缩放选项中进行选择，包括一种事件驱动的缩放模型，该模型根据函数执行的工作自动进行缩放。

• Azure 容器应用： 使用 事件驱动的自动缩放 根据应用程序执行的工作及其当前负载缩放应用程序。

• Azure Kubernetes 服务（AKS）： 若要跟上应用程序的需求，可能需要 调整运行工作负荷的节点数。 若要快速缩放 AKS 群集中的应用程序工作负荷，可以使用 虚拟节点。

• VM： 虚拟机规模集可以 自动增加或减少运行应用程序的 VM 实例数 。

部署戳模式

有关如何使用 部署标记模式 支持多租户解决方案的详细信息，请参阅 多租户解决方案的体系结构方法。

计算资源合并模式

计算资源整合模式通过共享基础计算资源，帮助实现更高的租户密度，从而优化计算基础设施的利用率。 通过共享计算资源，可以降低这些资源的直接成本。 此外，管理成本通常较低，因为要管理的组件较少。

但是，计算资源合并会增加 干扰邻居问题的可能性。 任何租户的工作负荷可能会消耗过多的可用计算容量。 通常可以通过确保适当地缩放解决方案，并应用配额和 API 限制等控制措施，以避免占用超过其容量公平份额的租户来缓解此风险。

此模式以不同的方式实现，具体取决于所使用的计算服务。 请参阅以下示例服务或组件：

• 应用服务和 Azure Functions： 部署共享应用服务计划，这些计划代表托管服务器的基础设施。

• 容器应用： 部署 共享环境。

• AKS： 使用多租户感知应用程序部署共享 Pod。

• VM： 部署一套供所有租户使用的 VM。

每个租户的专用计算资源

还可以为每个租户部署专用计算资源。 专用资源通过确保每个租户的计算资源与其他租户隔离来缓解 干扰邻居问题 的风险。 它还使你能够根据每个租户的要求为每个租户的资源部署不同的配置。 但是，专用资源通常会产生更高的成本，因为你对资源的租户密度较低。

根据所使用的 Azure 计算服务，可能需要部署不同的专用资源：

• 应用服务和 Azure Functions： 为每个租户部署单独的应用服务计划。

• 容器应用： 为每个租户部署单独的环境。

• AKS： 为每个租户部署专用群集。

• VM： 为每个租户部署专用 VM。

还可以通过在 Azure 专用主机上运行租户 VM 来提供物理主机级隔离，后者为单个客户保留整个物理服务器。 但是，这种方法通常比使用共享主机更昂贵。

半隔离计算资源

在共享其他组件时，半隔离方法要求在独立配置中部署解决方案的各个方面。

使用应用服务和 Azure Functions 时，可以为每个租户部署不同的应用程序，并在共享应用服务计划上托管应用程序。 此方法可降低计算层的成本，因为应用服务计划表示计费单位。 它还使你能够将不同的配置和策略应用到每个应用程序。 但是，此方法引入了 干扰邻居问题的风险。

可以使用容器应用将多个应用程序部署到共享环境，然后使用 Dapr 和其他工具单独配置每个应用程序。

AKS 和 Kubernetes 更广泛地为多租户提供了各种选项：

• 租户特定的命名空间，可提供特定于租户的资源的逻辑隔离，这些资源部署到共享群集和节点池。

• 共享群集上特定于租户的节点或节点池。

• 可能使用同一节点池的特定于租户的 pod。

还可以使用 AKS 应用 Pod 级治理来缓解 邻居干扰问题。 有关详细信息，请参阅 应用程序开发人员在 AKS 中管理资源的最佳做法。

还需要注意 Kubernetes 群集中的共享组件，以及多租户如何影响这些组件的情况。 例如，Kubernetes API 服务器是在整个群集中使用的共享服务。 即使提供租户专属节点池来隔离租户的应用程序工作负载，API 服务器也可能会遇到来自多个租户的大量请求引发的争用问题。

要避免的反模式

“近邻干扰”反模式

当你部署租户共享的组件时，干扰性邻居问题是一个潜在的风险。 为降低其他租户活动可能影响某个租户计算工作负荷的风险，确保实施资源治理和监控措施。

跨租户数据泄漏

如果计算层未正确处理，可能会导致跨租户数据泄漏。 在 Azure 上使用多租户服务时，通常不需要考虑此风险，因为Microsoft在平台层提供保护。 但是，当你开发自己的多租户应用程序时，请考虑是否有任何共享资源（如本地磁盘缓存、RAM 和外部缓存）可能包含另一个租户意外查看或修改的数据。

繁忙前端反模式

若要避免 忙碌的前端反模式，请确保前端层不会执行体系结构的其他组件或层可以处理的大部分工作。 为多租户解决方案创建共享前端时，此反模式尤其重要，因为忙碌的前端会降低所有租户的体验。

相反，请考虑使用队列或其他消息传送服务来使用异步处理。 此方法还使你可以根据不同的租户的要求为不同的租户应用 服务质量 控制。 例如，所有租户可能共享一个常见的前端层，但为 更高服务级别付费 的租户可能具有较高的专用资源集来处理队列消息中的工作。

非弹性缩放或缩放不足

多租户解决方案往往受到突发缩放模式的影响。 共享组件很容易遇到此问题，因为突发范围更高，并且当你有更多的租户具有不同的使用模式时，效果会更大。

确保利用云的弹性和规模。 请考虑是应使用 水平缩放还是垂直缩放，并使用自动缩放自动处理负载峰值。 测试解决方案，以了解它在不同负载级别下如何运行。 确保包括生产中预期的负载量和预期增长。 可以使用完全托管的服务（如 负载测试）来了解应用程序在压力下如何运行。

无缓存反模式

无缓存反模式是解决方案的性能受到影响时，应用程序层会重复请求或重新计算可跨请求重复使用的信息。 如果有可以在租户之间或在单个租户中的用户之间共享的数据，则可能需要缓存数据以减少后端或数据库层上的负载。

不必要的有状态性

无缓存反模式的含义是，还应避免在计算层中存储不必要的状态。 明确说明保留状态的位置和原因。 有状态前端或应用层可能会降低缩放能力。 有状态计算层通常还需要会话亲和性，这可能会减少您在工作线程或节点之间有效地对流量进行负载均衡的能力。

考虑计算层中维护的每个状态的权衡，以及它是否影响在租户的工作负荷模式发生变化时缩放或增长的能力。 还可以将状态存储在外部缓存中，例如 Azure Redis 缓存。

供稿人

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

主要作者：

• Dixit Arora | 适用于 Azure 的 FastTrack 高级客户工程师
• John Downs | 首席软件工程师

其他参与者：

• 阿森·弗拉基米尔斯基 | 客户首席工程师，FastTrack for Azure

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

后续步骤

查看针对计算服务的特定服务指南：

• 多租户环境下的 App Service 和 Azure Functions 注意事项
• 在多租户解决方案中使用容器应用的注意事项
• 多租户的 AKS 注意事项