多租户解决方案中的租户生命周期注意事项

设计多租户体系结构时，必须考虑到租户生命周期中的每个阶段。 本文为技术决策者提供关于每个阶段重要考虑因素的指导。

试用租户

许多客户在承诺购买软件即服务（SaaS）解决方案之前请求或要求试用。

试用版引入了以下唯一注意事项：

• 服务要求： 确定试用版是否应满足与完整客户的数据相同的数据安全性、性能和服务级别要求。

• 基础设施： 确定是否在与完整客户相同的基础结构上托管试用租户，还是使用专用基础结构。

• 迁移： 如果客户在试用后购买服务，请计划如何将数据从试用租户迁移到付费租户。

• 请求过程： 定义谁可以请求试用、如何防止滥用解决方案，以及是自动创建试用还是涉及团队。

• 限制： 为试用客户设置适当的限制，例如时间限制、功能限制或性能上限。

在某些情况下， 具有有限功能的免费定价模型 可以作为提供试用版的替代方法。

加入新租户

引入新租户时，请考虑以下因素：

• 过程： 决定是否将入职流程设置为自助服务、自动化或手动过程。

• 数据驻留： 确定租户是否对数据驻留有任何特定要求，例如符合数据主权法规。

• 合规： 确定租户必须满足的符合性标准。 这些标准可能包括支付卡行业数据安全标准（PCI DSS）或希思保险可移植性和责任法案（HIPAA）。

• 灾难恢复： 确认租户是否有特定的灾难恢复要求，例如恢复时间目标（RTO）还是恢复点目标（RPO）。 确定这些保证是否不同于提供给其他租户的保证。

• 信息：定义完全载入租户所需的信息。 例如，可能需要其组织的法定名称或其公司徽标，包括文件大小和格式。

• 计费： 确定平台是否提供不同的定价选项和计费模型。

• 环境： 确定租户是否需要预生产环境。 阐明环境是必须始终可用还是可以按需预配。

在你将租户加入后，他们将进入日常运营状态。 但是，此状态期间仍可能发生重要的生命周期事件。

更新租户的基础结构

请考虑如何将更新应用到租户的基础结构。 不同的租户可能会在不同的时间接收更新。

有关详细信息，请参阅 更新多租户解决方案的注意事项。

扩大租户的基础设施

确定您的租户是否经历季节性业务模式或其他在您解决方案上的消费波动。

例如，如果您向零售商提供解决方案，您可能会预期在某些地理区域的特定时间出现流量高峰，而在其他时间则相对平静。 请考虑这个季节的变化是否会影响您设计和扩展解决方案的方式。 请注意“嘈杂邻居”问题，即部分租户负载突然增加会降低其他租户的性能。

请考虑应用以下缓解措施：

• 调整单个租户的基础设施。

• 在不同的部署环境之间移动租户。

• 预配足够的容量级别来处理流量高峰和下降。

在基础结构之间移动租户

出于多种原因，可能需要在基础结构之间移动租户。 请考虑下列情形：

• 平衡： 遵循 垂直分区的方法 将租户映射到基础结构，需要将租户移动到其他部署以重新平衡负载。

• 升级： 租户升级其 SKU 或定价层，并且必须移动到与其他租户隔离程度较高的单租户专用部署。

• 迁移： 租户请求将其数据移动到专用数据存储。

• 区域移动： 租户要求其数据驻留在不同的地理区域中。 在公司收购期间或由于法律或地缘政治条件的变化，可能会发生此要求。

请考虑如何移动租户的数据，以及如何将请求重定向到托管其实例的新基础结构集。 另请考虑移动租户是否可能导致停机，并确保租户完全了解风险。

合并和拆分租户

很容易假设租户或客户保持静态，但实际上，他们经常会改变。 请考虑下列情形：

• 在业务方案中，公司可能会被收购或合并，包括位于不同地理区域的公司。

• 在业务方案中，公司可能会拆分或剥离。

• 在消费者场景中，单个用户可能会加入或离开家庭。

考虑是否需要提供功能来管理数据、用户标识和资源的合并和分离。 另请考虑数据所有权如何影响处理合并和拆分作的方式。

例如，在家庭的消费者照片共享应用中，确定照片是属于个人参与者还是整个家庭。 如果用户离开家庭，请考虑是删除其数据还是将其保留在家庭数据集中。 如果用户加入另一个家庭，请确定他们的旧照片是否随他们一起移动。

登出租户

有时需要从解决方案中删除租户。 在多租户解决方案中，卸载引入了重要注意事项：

• 保留期： 确定维护客户数据的时间。 确定在特定时间段后强制数据销毁的任何法律要求。

• 重新载入： 决定是否支持重新载入。 阐明租户的数据是否在保留期内保持可用。

• 重新平衡：如果运行共享基础架构，请评估是否需要在卸载后重新平衡租户资源分配。

停用和重新激活租户

可能需要停用或重新激活客户的帐户。 请考虑以下示例：

• 客户请求停用。 在使用者系统中，客户可以选择取消订阅。

• 客户无法计费，需要停用订阅。

停用不同于卸载，因为它旨在成为临时状态。 但是，在一段时间后，你可以选择登出某个已停用的租户。

供稿人

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

主要作者：

• John Downs |Azure 模式和做法的主要软件工程师

其他参与者：

• 查德·基特尔 |Azure 模式和做法的主要软件工程师
• Paolo Salvatori | FastTrack for Azure 首席客户工程师
• 阿森·弗拉基米尔斯基 | 客户首席工程师，FastTrack for Azure

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

相关资源

• 请考虑计划用于解决方案的 定价模型 。