更新多租户解决方案的注意事项

云技术的优势之一是持续改进和演变。 作为服务提供商，需要对解决方案应用更新：可能需要更改应用程序代码、Azure 基础结构、数据库架构或任何其他组件。 规划如何更新环境非常重要。 在多租户解决方案中，明确更新策略非常重要，因为一些租户可能不愿意允许更改其环境，或者他们可能有限制可更新其服务的条件的要求。

规划更新解决方案的策略时，需要：

• 确定租户的要求。
• 阐明自己的服务运行要求。
• 找到你和租户都可以接受的平衡。
• 将策略清楚地传达给租户和其他利益干系人。

在本文中，我们为技术决策者提供有关可考虑更新租户软件的方法以及相关权衡的指导。

你的客户要求

客户通常具有可影响系统更新方式的显式或隐式要求。 请考虑以下几个方面，以便形成对客户可能提出的任何关注点的理解：

• 期望和要求： 发现客户何时可以更新其解决方案的预期或要求。 这些内容可能会在合同或服务级别协议中正式传达给你，也可能是非正式的。
• 维护时段： 了解客户是需要服务定义的，还是需要自行定义的维护时段。 他们可能需要与用户沟通任何潜在的服务中断，或者可能需要在更新完成后测试服务的重要方面。
• 法规： 阐明客户是否有任何需要额外批准才能应用更新的法规问题。 例如，如果你提供包含 IoT 组件的健康解决方案，则可能需要在应用更新之前从美国食品和药物管理局（FDA）获得批准。
• 敏感性： 了解你的任何客户是特别敏感还是抵制应用更新。 如果是，请尝试了解原因。 例如，如果他们经营实体商店或零售网站，他们可能想要避免在黑色星期五周围更新，因为风险高于潜在利益。
• 历史记录：查看在不影响客户的情况下成功完成更新的跟踪记录。 应遵循良好的 DevOps、测试、部署和监视做法，以减少中断的可能性，并确保快速识别更新引入的任何问题。 如果你的客户知道你能够顺利更新其环境，他们就不太可能提出异议。
• 回滚：考虑客户是否希望在出现重大更改时回滚更新，以及由谁来触发这样的回滚请求。

你的要求

你还需要从自己的角度考虑以下问题：

• 您愿意给予的控制： 是否合理让客户控制何时应用更新？ 如果要构建大型企业客户使用的解决方案，答案可能是是的。 但是，如果你正在构建一个以消费者为中心的解决方案，则你不太可能会让客户来控制解决方案的升级或操作方式。
• 版本： 一次可以合理维护多少个解决方案版本？ 请记住，如果发现 bug 并需要对其进行修补程序修复，则可能需要将修补程序应用到正在使用的所有版本。
• 旧版本的后果： 让客户落后于当前版本的影响是什么？ 如果定期发布新功能，旧版本是否会很快过时？ 此外，根据升级策略和更改类型，可能需要为每个解决方案版本维护单独的基础结构。 因此，在维护对较旧版本的支持时，可能会同时产生运营和财务成本。
• 回滚： 您的部署策略是否支持回滚到以前的版本？ 这是你想要启用的功能吗？

查找余额

如果将服务更新的节奏完全留给租户的任意裁量，他们可能会选择从不更新。 在考虑客户可能有的任何合理问题或限制情况下，重要的是要允许自己更新解决方案。 例如，如果客户对星期五的更新特别敏感，因为这是一周中最繁忙的一天，那么你能否同样轻松地将更新推迟到星期一，而不会影响解决方案？

一种效果良好的方法是使用 下面所述的方法之一，逐租户推出更新。 向客户通知计划内更新。 允许客户暂时选择退出，但不能永远选择退出;在需要应用更新时施加合理的限制。

此外，考虑允许你自己部署安全修补程序或其他关键修补程序，只发出极少量的提前通知甚至不发出通知。 确保租户了解这种做法及其在保护数据方面的重要性。

另一种方法是允许租户在选择时启动自己的更新。 同样，你应该提供最后期限，此时你代表他们应用更新。

无论执行什么作业时，请确保有一个机制来监控租户的健康状态，特别是在应用更新之前和之后。 通常，关键生产事件（也称为 实时站点事件）在更新代码或配置后发生。 因此，请务必主动监视和响应任何问题，以保持客户信心。 有关监视的详细信息，请参阅 有关设计和创建监视系统的建议。

与客户沟通

明确的沟通是构建客户信心的关键。 请务必解释常规更新的优点，包括新功能、bug 修复、解决安全漏洞和性能改进。 现代云托管解决方案的优点之一是持续交付功能和更新。

考虑以下问题：

• 你会通知客户即将进行的更新吗？
• 如果这样做，是否通过提供选择退出过程来隐式请求权限，以及选择退出的限制是什么？
• 是否安排了一个在应用更新时使用的计划性维护时段？
• 如果有紧急更新（如关键安全修补程序）会发生什么情况？ 是否可以在这些情况下强制更新？
• 如果无法主动通知客户即将进行的更新，是否可以提供追溯通知？ 例如，您能否在您网站上的页面中更新您已应用的更新列表？
• 将在生产环境中维护多少个单独的系统版本？

与客户支持团队沟通

重要的是，你自己的支持团队能够充分了解已应用于每个租户基础结构的更新。 客户支持代表应能够轻松回答以下问题：

• 最近是否已将更新应用到租户的基础结构或共享组件？
• 这些更新的性质是什么？
• 以前的版本是什么？
• 更新应用于此租户的频率如何？

如果某个客户因更新而出现问题，则需要确保客户支持团队具有了解所更改内容所需的信息。

用于支持更新的部署策略

请考虑如何将更新部署到基础结构。 这在很大程度上受你使用的 租赁模型 的影响。 部署更新的三种常见方法是部署标记、功能标志和部署圈。 可以独立使用这些方法，也可以将它们组合在一起以满足更复杂的要求。

在所有情况下，请确保有足够的报告和可见性，以便了解每个租户的基础结构、软件或功能版本、他们有资格迁移到哪些内容以及与这些状态关联的任何时间相关数据。

部署戳模式

许多多租户应用程序非常适合 部署标记模式，在其中部署应用程序的多个副本和其他组件。 根据隔离要求，可以为每个租户部署一个戳记，或部署运行多个租户工作负荷的共享戳章。

邮票是在租户之间提供隔离的好方法。 它们还提供更新过程的灵活性，因为你可以逐步跨戳记推出更新，而不会影响其他人。

功能标志

通过功能标志 ，可以将功能添加到解决方案，同时仅向部分客户或租户公开该功能。

如果以下任一情况适用于你，请考虑使用功能标志：

• 你定期部署更新，但希望避免显示新功能，直到它完全实现。
• 希望避免在客户选择加入之前应用行为更改。

可以通过自行编写代码或使用 Azure 应用配置等服务将功能标志支持嵌入应用程序。

部署圈

使用部署环可以在一组租户或部署缩放单元中逐步推出更新。 可将一部分租户分配到每个环。

可以确定要创建多少个环以及每个环对你自己的解决方案意味着什么。 通常，组织会使用以下通道：

• Canary：canary 通道包括你自己的测试租户以及希望在更新可用时立即应用更新的客户，他们知道可能会收到更频繁的更新，并且更新可能没有通过像其他地方一样全面的验证过程。
• 早期采用者：早期采用者通道包含风险厌恶程度略高，但仍已准备好接收定期更新的租户。
• 用户： 大多数租户将属于 用户 圈，该圈接收频率较低且测试程度更高的更新。

API 版本

如果服务公开外部 API，请考虑应用的任何更新可能会影响客户或合作伙伴与平台集成的方式。 具体而言，需要注意 API 的中断性变更。 请考虑使用 API 版本控制策略 来降低 API 更新的风险。

供稿人

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

主要作者：

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

其他参与者：

• 查德·基特尔 |Azure 模式和做法的主要软件工程师
• 丹尼尔·斯科特-伦斯福德|高级合作伙伴技术解决方案顾问
• 阿森·弗拉基米尔斯基 | 客户首席工程师，FastTrack for Azure

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

后续步骤

考虑何时在 多租户解决方案中将请求映射到租户。