你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
控制平面是软件即服务(SaaS)和多租户解决方案的重要组成部分,尤其是帮助大规模管理解决方案。 通常,有两个主要组件组成控制平面:
- 租户目录,用于存储有关租户的重要信息,例如:
- 租户配置。
- 为租户资源部署的 SKU。
- 租户分配到的部署标记。
- 管理环境更改的过程,这些更改由 租户生命周期事件触发。 例如,租户入驻、租户迁出和任何所需的定期维护。
控制平面本身是一个应用程序。 你需要仔细考虑你的控制平面,并像对待解决方案的任何其他部分一样,严格认真地进行设计。 有关控制平面是什么、为何应使用它以及设计控制平面的注意事项的详细信息,请参阅 多租户控制平面的注意事项。
本文介绍一些可用于设计和创建控制平面的方法。 此处介绍的方法列表并不全面。 尽管这些方法都是有效的,但还有其他有效的体系结构。
要考虑的方法和模式
下表总结了一些可用于控制平面的方法之间的差异。 比较手动、低代码和自定义方法。
注意事项 | 手动 | 低代码 | 习惯 |
---|---|---|---|
运营开销 | 高 | 低到中等 | 低 |
该方法适用于的生命周期事件频率 | 罕见 | 偶尔-经常 | 经常 |
实现的时间和复杂性 | 低 | 中等 | 高 |
控制面板维护责任 | 低 | 中等 | 高 |
可测试性 | 低 | 中等 | 高 |
不一致的风险 | 高 | 中低 | 低 |
手动进程
构建完全自动化的控制平面并不总是必要的,尤其是在刚开始时只有少量租户的时候。
可以将租户目录保留在中心位置,例如 Excel 工作簿或存储在团队可以访问的位置的 JSON 文件。 无论采用何种格式,最好以结构化方式存储信息,以便以编程方式轻松处理数据。
注释
手动控制平面是开始管理多租户应用程序的一种好方法,但它仅适用于少量租户(小于 5-10)。 每当你手动载入一个租户时,管理费用和不一致性的风险都会增加。 仅在拥有少数租户且无需自动或自助注册时,才应使用此方法。
对于租户入驻和维护活动等流程:
- 尽可能创建脚本或自动化管道,即使手动运行它们也是如此。 通过使用脚本或流水线,可确保每个租户的步骤保持一致地进行。
- 对于最初无法编写脚本的任务,请全面详细地记录该过程。 记录 作方法 以及 原因。 如果某人最终在将来自动执行任务,他们应该对两者都有很好的了解。
下图演示了对初始控制平面使用手动进程的一种方法:
下载此体系结构的 Visio 文件。
手动方法的优点
- 轻型:文档、脚本和管道易于开发和修改。 这使它们非常适合用于确定过程,因为可以快速迭代和发展它们。
- 低成本:维护和运行手动方法的成本较低。
- 验证过程:即使最终打算使用更自动化的方法,从手动方法开始,作为概念证明是验证维护策略的好方法,然后再投入时间开发更可靠的自动化。
手动方法的缺点
- 缺乏控制:此方法依赖于每个参与的人都要操作正确。 有人可能会意外或故意偏离规定的流程。 流程中的每个变体都会增加环境中不一致的风险,这使得正在进行的管理更加困难。
- 访问控制挑战:使用此方法时,通常需要向运行解决方案的任何人员授予范围广泛、高度宽松的访问权限,这使得很难遵循 访问分段的最佳做法。
- 可伸缩性:运行手动进程所需的工作随需要管理的租户数进行缩放。
- 可测试性:手动过程难以验证和测试。
何时考虑离开手动方法
- 当团队无法跟上维护应用程序所需的工作量时。 例如,当租户数超出关键点时,大多数团队的租户数介于 5 到 10 个租户之间。
- 当预计租户增长超过租户的临界数量时,需要为管理该租户数量所涉及的工作做好准备。
- 需要缓解不一致的风险时。 例如,你可能会发现一些错误,因为有人未正确关注这些进程,或者因为进程中存在太多歧义。 随着越来越多的租户手动载入,随着团队的增长,不一致的风险通常会增加。
低代码控制平面
低代码或无代码控制平面建立在旨在自动执行业务流程和跟踪信息的平台上。 有许多平台使你无需编写自定义代码即可执行这些任务。
Microsoft Power Platform 是其中一个平台的示例。 如果使用 Power Platform,则可以将租户目录保留在 Dynamics 365、Dataverse 或 Microsoft 365 中。 如果不想完全承诺自动执行所有操作,还可考虑保留用于手动过程的同一租户目录。
对于租户载入和维护,可以使用 Power Automate 来运行执行租户管理、配置租户、触发管道或 API 调用等的工作流。 可以使用 Power Automate 监视租户目录的更改,前提是数据位于 Power Automate 可访问的位置。 如果使用手动租户目录,也可以手动触发 Power Automate 工作流。 如果需要团队中的某人验证某些内容或执行无法完全自动化的其他步骤,则可以决定在工作流中包含手动审批步骤。
此方法还允许 Web 应用程序直接将记录添加到租户目录中,而无需人工干预,从而为客户提供自助注册。
下图演示了如何使用 Microsoft Power Platform 创建具有自助注册的控制平面:
下载此体系结构的 Visio 文件。
低代码方法的优点
- 轻型:创建一组低代码工作流并将其连接到周围的系统通常很快速且便宜。
- 使用平台工具:可以使用本机平台功能来存储数据、创建管理门户供团队使用,并在工作流运行时监视工作流。 通过使用本机平台功能,可以避免自己生成大量组件。
- 可自定义:如果需要更多自定义,通常可以使用自定义代码和流程来扩充工作流。 例如,可以使用 Power Automate 在 GitHub Actions 中触发部署工作流,或者可以调用 Azure Functions 来运行自己的代码。 这也有助于促进逐步实现。
- 低开销:低代码服务通常完全托管,因此无需管理基础结构。
低代码方法的缺点
- 所需专业知识:若要使用低代码平台创建流程,并有效地使用这些平台,通常需要专有知识。 许多组织已经使用这些工具,因此你的团队可能已经有所需的专业知识,但它可能没有。 应考虑是否需要训练团队才能有效地使用这些平台。
- 管理:处理大量低代码配置管理可能很困难。
- 可测试性:考虑如何测试和实施对控制平面的更改。 在托管平台中,创建用于测试和提升更改的典型 DevOps 过程更为困难,因为通常通过配置而不是代码进行更改。
- 设计:仔细考虑如何满足安全性和可靠性等非功能性要求。 这些要求通常在低代码平台上进行管理。
何时考虑退出低代码方法
- 最终,你的要求可能变得如此复杂,以至于你无法明智地将它们合并到低代码解决方案中。 当需要解决工具限制以满足需求时,从托管解决方案转向自定义控制平面可能很有意义。
自定义控制平面
还可以考虑创建自己的完全自定义的控制平面。 此选项提供最大的灵活性和能力,但它也需要最多的工作量。 租户目录通常存储在数据库中。 在这种情况下,你不能直接使用目录,而是通过管理界面对其进行管理,这可能是自定义应用程序或组织的客户关系管理(CRM)应用程序等系统。
通常创建一组控制平面组件,这些组件围绕所有租户管理功能设计。 这些组件可能包括管理门户或其他用户界面、API 和后台处理组件。 如果你需要在租户生命周期事件发生时执行诸如部署代码或基础设施的任务,部署管道也可能构成你的控制平面。
确保任何长期运行的处理都使用合适的工具。 例如,可以将 Durable Functions 或 Azure 逻辑应用 用于协调租户载入或部署的组件,或用于需要与外部系统通信的组件。
与低代码方法一样,此方法允许 Web 应用程序在不人工干预的情况下直接将记录添加到租户目录中,从而为客户提供自助注册。
下图显示了创建提供自助注册的基本自定义控制平面的一种方法:
下载此体系结构的 Visio 文件。
自定义方法的优点
- 完全的灵活性和可自定义性:你可以完全控制控制平面的作用,并在需求发生变化时更改它。
- 可测试性:可以将标准软件开发生命周期(SDLC)用于控制平面应用程序,并实现用于测试和部署的正常方法,就像对主要应用程序一样。
自定义方法的缺点
- 维护责任:此方法需要更多的维护开销,因为你需要自己创建所有内容。 控制平面与应用程序的任何其他部分一样重要。 在开发、测试和运行控制平面时,需要非常小心,以确保其可靠且安全。
混合方法
还可以考虑使用混合方法。 可以使用手动和自动化系统的组合,也可以使用 Microsoft Power Platform 等托管平台,并使用自定义应用程序对其进行扩充。 如果需要自定义控制平面的可自定义性,但不一定想要生成和维护完全自定义的系统,请考虑实现混合方法。 请记住,在某些时候,对手动流程或托管平台的自动自定义可能像完全自定义的系统一样复杂。 每个组织的临界点都不尽相同,但如果混合方法难以维护,您应该考虑迁移到一个完全自定义的系统。
逐步实现
即使你知道希望最终实现控制平面的自动化,也不一定需要从这种方法开始。 创建应用程序的初始阶段的常见方法是从手动控制平面开始。 随着您的应用程序进展并引入更多租户,您应该开始识别瓶颈环节,并根据需要自动化这些环节,然后转向混合方法。 随着自动化程度的提高,您最终可能会拥有一个完全自动化的控制平面。
要避免的反模式
- 依赖于手动进程太久。 虽然在启动时或拥有少量租户且需要相当轻量级的管理时使用手动流程是合理的,但你需要规划如何在增长时缩放到自动化解决方案。 如果您需要聘请额外的团队成员来应对手动流程的需求,这是一个很好的信号,表明您应该开始自动化控制平面的某些部分。
- 对长时间运行的工作流使用不适当的工具。 例如,避免使用标准 Azure 函数、同步 API 调用或其他具有执行时间限制的工具来执行长时间运行的作,例如 Azure 资源管理器部署或多步骤业务流程。 而是使用 Azure 逻辑应用、Durable Functions 和其他可执行长时间运行工作流或者操作序列的工具。 有关详细信息,请参阅 Azure Functions 性能和可靠性和异步 Request-Reply 模式。
供稿人
本文由Microsoft维护。 它最初是由以下贡献者撰写的。
主要作者:
- John Downs | 首席软件工程师
- Landon Pierce | 客户工程师
其他参与者:
- 米克·阿尔伯特 |技术编写器
- Bohdan Cherchyk | 高级客户服务工程师
- Arsen Vladimirskiy | 首席客户工程师