“近邻干扰”反模式
多租户系统在租户之间共享两个或更多资源。 由于租户使用相同的共享资源，因此一个租户的活动可能会对另一个租户的系统使用产生负面影响。
上下文和问题
生成多个客户或 租户 共享的服务时，可以将其生成为 多租户。 多租户系统的优点是，可以在租户之间共用和共享资源。 这种资源共享通常会产生更低的成本和提高效率。 但是，如果单个租户使用的资源量与系统中可用的资源量不相称，系统的整体性能可能会降低。 当一个租户的性能由于另一个租户的活动而下降时，会出现“近邻干扰”问题。
假设有两个租户的示例多租户系统。 租户 A 的使用模式与租户 B 的使用模式一致。 在高峰时段，租户 A 使用系统的所有资源，这意味着租户 B 发出的任何请求都会失败。 换句话说，总资源需求高于系统的容量：
请求首先到达的租户很可能优先。 然后，另一个租户可能会遇到干扰邻居问题。 或者，这两个租户的性能可能会下降。
当每个单独的租户只消耗系统容量的一小部分时，也会发生干扰邻居问题。 但是，许多租户的组合资源使用率可能会导致总体使用量达到峰值：
如果有多个租户具有相同的使用模式，或者尚未为系统上的集体负载预配足够的容量，则可能会出现这种情况。
解决方案
共享单个资源本身就会带来无法完全避免的干扰邻居问题的风险。 但是，客户端和服务提供商都可以采取一些步骤来降低干扰邻居问题的可能性或减轻其影响。
客户端可以执行的操作
确保应用程序处理 服务限制 ，以减少向服务发出不必要的请求。 确保应用程序遵循最佳做法重试 接收暂时性故障响应的请求。
购买预留容量（如果可用）。 例如，使用 Azure Cosmos DB 时，购买 预留吞吐量。
迁移到具有更强隔离保证的服务层（如果可用）。 例如，使用 Azure 服务总线时， 请迁移到高级层。 使用 Azure Redis 缓存时， 请预配标准层或高级层缓存。
迁移到服务的单租户实例。 例如，使用 Azure ExpressRoute 时， 为对性能敏感的环境预配单独的线路。
服务提供商可以执行的操作
监视系统的资源使用情况。 监视总体资源使用情况和每个租户使用的资源。 配置警报以检测资源使用率峰值。 如果可能，请将自动化配置为通过 纵向扩展或横向扩展来自动缓解已知问题。
应用资源治理。 请考虑应用策略来防止单个租户压倒系统，并减少其他租户可用的容量。 此步骤可能采用通过 限制模式 或 速率限制模式强制实施配额的形式。
预配更多基础结构。 此过程可能包括通过升级某些解决方案组件来纵向扩展。 或者，如果遵循 分片模式，则可以通过预配额外的分片来扩大，或者如果遵循 部署标记模式，则包括横向扩展。
使租户能够购买预配或预留容量。 此方法使租户更有信心解决方案能够可靠地处理其工作负荷。
平衡租户资源使用情况。 例如，可以尝试以下方法之一：
如果托管解决方案的多个实例，请考虑在实例或缩放单元之间重新平衡租户。 例如，考虑在多个模具中放置具有可预测和互补使用模式的租户，以平展其使用高峰。
考虑是否具有对时间不敏感的后台进程或资源密集型工作负载。 在非高峰时间异步运行这些工作负荷，以保留对时间敏感工作负荷的资源容量。
检查下游服务是否提供可缓解近邻干扰问题的控件。 例如，使用 Kubernetes 时，请考虑使用 Pod 限制。 使用 Azure Service Fabric 时，请考虑使用 内置治理功能。
限制租户可执行的操作。 例如，通过指定查询的最大可返回记录计数或时间限制，限制租户执行运行非常大的数据库查询的作。 或者将这些作更改为异步作，并计划这些作在非高峰时间运行。 此作可缓解租户采取可能对其他租户产生负面影响的作的风险。
提供服务质量（QoS）系统。 应用 QoS 时，优先处理某些进程或工作负载，然后再设置其他进程或工作负荷的优先级。 通过将 QoS 纳入设计和体系结构，可以确保在资源面临压力时优先处理高优先级操作。
注意事项
在大多数情况下，单个租户不打算造成干扰邻居问题。 单个租户可能不知道其工作负荷会导致其他租户的干扰邻居问题。 但是，某些租户可能会利用共享组件中的漏洞单独攻击服务，或者通过执行分布式拒绝服务攻击来攻击服务。
无论原因如何，请务必将这些问题视为资源治理问题，并应用使用配额、限制和治理控制来缓解问题。
注意
对于客户端而言，对强制实施的任何限制机制或使用配额保持透明。 重要的是，他们妥善处理失败的请求，并且不受限制的防护。
如何检测问题
从客户端的角度来看，干扰性邻居问题通常表现为对服务的失败请求或需要很长时间才能完成的请求。 具体而言，如果同一请求在其他时间成功并且似乎随机失败，则可能存在干扰邻居问题。 客户端应用程序应记录遥测数据，以跟踪对服务的请求的成功率和性能。 出于比较目的，应用程序还应记录基线性能指标。
对于基于 Azure 的服务，请查看 Azure 订阅和服务限制、配额和约束， 以了解适用于解决方案中每个 Azure 组件的限制和配额。
从服务的角度来看，干扰性邻居问题可能以以下方式出现。
资源使用量峰值： 请务必清楚地了解正常的基线资源使用情况，并配置监视和警报以检测峰值。 请考虑可能影响服务性能或可用性的所有资源。 这些资源包括服务器 CPU 和内存使用率、磁盘输入和输出、数据库使用情况和网络流量等指标。 还应监视托管服务公开的指标，包括请求量和综合性能指标或抽象性能指标，例如 Azure Cosmos DB 请求单位。
为租户执行作时失败： 查找租户未占用大量系统资源份额时发生的故障。 此模式可能表示租户遇到干扰邻居问题。 按租户跟踪资源消耗。 例如，使用 Azure Cosmos DB 时，请记录每个请求的请求单位，并将租户的标识符包含在遥测中，以便聚合每个租户的请求单位使用情况。
作者
Microsoft维护本文。 以下参与者撰写了本文。
主要作者：
- John Downs | 首席软件工程师
其他参与者：
- 查德·基特尔 |Azure 模式和做法的主要软件工程师
- Paolo Salvatori | FastTrack for Azure 首席客户工程师
- 丹尼尔·斯科特-伦斯福德|高级合作伙伴技术解决方案顾问
- 阿森·弗拉基米尔斯基|首席工程师，FastTrack for Azure
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。