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