你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
多租户解决方案具有多个 平面，每个平面都有自己的职责。 数据平面使用户和客户端能够与系统交互。 控制平面是跨所有租户管理更高级别任务的组件，例如访问控制、预配和系统维护，以支持平台管理员的任务。
本文介绍控制平面的责任以及如何设计满足需求的控制平面。
例如，假设有一个用于管理财务记录的簿记系统。 多个租户将其财务记录存储在该系统中。 当用户访问系统以查看并输入其财务记录时，他们使用数据平面。 数据平面可能是解决方案的主要应用程序组件。 租户通常将其视为用于按预期使用系统的主接口。
相比之下，控制平面接入新租户，为每个租户创建数据库，并执行其他管理和维护操作。 如果没有控制平面，管理员必须依赖手动过程。 在某些情况下，数据平面和控制平面任务会纠缠在一起，这会使解决方案复杂化。
许多复杂系统包括控制平面。 例如，Azure 控制平面 Azure 资源管理器是一组用于部署和配置 Azure 资源的 API、工具和后端组件。 同时 Kubernetes 控制平面管理许多任务，例如在工作器节点上放置 Kubernetes Pod。 几乎所有软件即服务 (SaaS) 解决方案都具有一个控制平面来处理跨租户任务。
设计多租户解决方案时，需要考虑控制平面。 以下部分介绍如何限定和设计控制平面。
控制平面的责任
控制平面或其责任没有单一模板。 解决方案的要求和体系结构决定了控制平面需要执行的操作以及工作原理。 在某些多租户解决方案中，控制平面具有广泛的责任，并且其本身就是一个复杂的系统。 在其他多租户解决方案中，控制平面只承担基本责任。
通常，控制平面可能具有以下多个核心责任：
资源管理： 它预配和管理为工作负荷提供服务的系统资源，包括特定于租户的资源。 控制平面可以 调用和协调部署管道 或直接运行部署作。
资源配置： 它 重新配置共享资源 以识别新租户。 例如，控制平面可能会配置网络路由，以确保传入流量 到达正确的租户资源，或者可能需要缩放资源容量。
租户配置： 它存储和管理每个租户的配置。
租户生命周期管理： 它处理 租户生命周期事件，包括载入、重新定位和卸载租户。
遥测： 它会跟踪每个租户对功能和系统性能的使用。
消耗跟踪： 它 度量和聚合每个租户的资源消耗量。 消耗指标可能会通知计费系统或支持资源治理。
如果使用 完全多租户模型 且不部署特定于租户的资源，则基本控制平面只能跟踪租户及其关联的元数据。 例如，当新租户注册服务时，控制平面可以更新数据库中的相应记录，以便系统的其余部分可以处理新租户的请求。
相反，如果您的解决方案使用需要特定租户基础设施的部署模型，例如自动化单租户模型，那么控制平面可能会承担更多责任。 载入新租户时，可能需要部署或重新配置 Azure 基础结构。 在此方案中，控制平面可能与其他工具（如 Resource Manager 或 Kubernetes 控制平面）的控制平面交互。
高级控制架构可能承担更多责任：
自动维护作： 它执行常见的维护作，包括删除或存档旧数据、创建和管理数据库索引以及轮换机密和加密证书。
租户放置： 它根据标准（如标记使用目标、租户需求和 装箱策略）将租户分配给现有的部署或标记。
租户重新均衡：随着部署标记的利用率变化，在部署标记之间重新平衡现有租户。
客户活动跟踪： 它与外部客户管理解决方案（如 Dynamics 365）集成，用于跟踪客户活动。
确定控制平面范围
仔细考虑为解决方案构建控制平面所花费的工作量。 控制平面不直接提供直接的客户价值，这使得在设计和构建高质量控制平面方面难以证明工程工作量的合理性。 但是，随着系统的增长和扩展，你越来越需要自动化管理和操作来跟上系统的增长。
在某些情况下，可能不需要完全控制平面。 如果系统少于 10 个租户，此方法可能有效。 你的团队可以承担起控制平面的责任，并可以使用手动操作和流程来加入和管理租户。 但是，你仍应该有一个进程并维护一个中心位置来跟踪租户及其配置。
小窍门
如果你不创建一个完整的控制平面，你仍然应该对你的管理程序应用一种系统性方法：
- 全面记录流程。
- 尽可能为管理操作创建并重复使用脚本。
如果需要将来自动执行流程，文档和脚本可以形成控制平面的基础。
随着租户逐渐增多，你可以从跟踪每个租户并在资源和租户组中应用监视的方法中受益。 你可能会注意到，你的团队花费了越来越多的时间和精力进行租户管理。 或者，你可能会注意到 bug 或操作问题，因为团队成员执行管理任务的方式不一致。 如果出现这些情况，请考虑构建更全面的控制平面来承担这些责任。
注释
如果提供自助式租户管理，则需要在早期使用控制平面。 可以选择创建一个基本控制平面，并仅自动执行一些最常用的功能。 随着时间的推移，可以逐步添加更多功能。
设计控制平面
确定控制平面的要求和范围后，需要设计和构建它。 控制平面是一个重要组件，它应该与体系结构的任何其他部分相同的规划级别。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅架构良好的框架。
控制平面充当其自己的系统，因此在设计Well-Architected 框架时，应考虑 Well-Architected 框架 的所有五大支柱。 以下部分重点介绍要关注的特定领域。
可靠性
可靠性可帮助确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。
控制平面通常充当关键任务组件。 您必须规划控制平面所需的适当弹性和可靠性级别。
考虑控制平面中断的影响。 在极端情况下，中断可能会导致整个解决方案不可用。 即使控制平面不是单一故障点，中断也可能会导致以下问题：
系统无法载入新租户，这可能会影响销售和业务增长。
系统无法管理现有租户，这会导致支持团队接到更多求助。
无法衡量租户的消耗量或按其使用量计费，这会导致收入损失。
无法在发生安全事件时禁用或重新配置租户。
维护债务不断累积，导致系统长期受损。 例如，如果解决方案需要每晚清理旧数据，则磁盘可能已满，或者性能可能会降低。
为控制平面定义服务级别目标，包括可用性目标、恢复时间目标 (RTO) 和恢复点目标 (RPO)。 你为控制平面制定的目标可能与您为客户提供的目标不同。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅可靠性设计审查检查表。
控制平面通常是高特权系统。 控制平面中的安全问题可能会产生灾难性的后果。 根据它的设计和功能，控制平面可能容易受到许多不同类型的攻击，包括以下类型：
未经授权访问机密： 控制平面可以访问所有租户的密钥和机密。 有权访问控制平面的攻击者可能访问任何租户的数据或资源。
滥用部署功能： 控制平面通常可将新资源部署到 Azure。 攻击者可能利用你的控制平面将其自己的资源部署到你的订阅中，从而可能产生大量费用。
拒绝服务： 如果攻击者成功禁用了你的控制平面，则可能会对你的系统和业务造成即时和长期的损害。 有关控制平面停机的潜在后果，请参阅 可靠性。
在设计和实现控制平面时，必须遵循安全最佳做法并创建全面的威胁模型。 此模型应识别并缓解解决方案中的潜在威胁和安全问题。
卓越运营
卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅设计卓越运营的审查清单。
控制平面是关键组件，因此应仔细考虑如何在生产环境中部署和操作它。
与解决方案的其他部分一样，应部署控制平面的非生产实例，以便可以全面测试其功能。 如果您的控制平面执行部署操作，请考虑非生产控制平面如何与 Azure 环境交互，以及将非生产资源部署到哪个 Azure 订阅中。 规划如何快速清理测试资源，使其不会意外累积费用。
还应计划如何管理团队对控制平面的访问。 仅授予团队成员执行其职责所需的权限。 此方法有助于防止安全事件，并减少意外配置错误的影响。
组件
没有用于生成控制平面的单个模板。 设计和生成的组件取决于你的要求。 大多数控制平面由 API 和后台辅助角色组件组成。 在某些解决方案中，控制平面还包括用户界面，你的团队甚至客户可能使用该用户界面。
将控制平面与租户工作负载隔离
应将控制平面的资源与服务于租户数据平面的资源分开。 例如，使用单独的数据库服务器、应用程序服务器和其他组件。 将控制平面资源保留在专用 Azure 资源组中，与特定于租户的资源分开。
控制平面隔离具有以下优势：
可以单独配置缩放。 例如，控制平面可能具有一致的资源要求，而租户的资源可能会根据其需要进行弹性缩放。
控制平面通常是具有较高访问级别的高特权系统。 控制平面隔离可降低安全漏洞的可能性，使攻击者能够在整个系统中提升其权限。
可以部署单独的网络和防火墙配置。 数据平面和控制平面通常需要不同类型的网络访问。
协调长时间运行的操作的序列
控制平面通常执行长时间运行的操作，这些操作需要在多个系统之间进行协调。 这些操作也可能具有复杂的故障模式，因此你必须选择支持长时间运行的操作或工作流的技术。
例如，在新租户入驻时，您的控制平面可能会按顺序运行以下操作：
部署新数据库。 此 Azure 部署作可能需要几分钟才能完成。
更新租户元数据目录。 此操作可能涉及对 Azure SQL 数据库运行命令。
向新租户发送欢迎电子邮件。 此作调用非Microsoft API 以发送电子邮件。
更新计费系统以准备为新租户开具发票。 此作调用偶尔会失败的非Microsoft API。
更新客户关系管理 (CRM) 系统以跟踪新租户。 此作调用非Microsoft API。
如果序列中的任何步骤失败，请考虑如何响应：
重试失败的操作。 例如，如果步骤 2 中的 Azure SQL 命令失败并出现暂时性错误，则可以重试。
继续执行下一步。 例如，你可能会决定允许账单系统更新失败，因为销售团队以后可以手动添加客户。
放弃工作流并触发手动恢复过程。
另请考虑每种故障方案的用户体验。
管理共享组件
控制平面需要识别共享的任何组件，而不是专用于特定租户。 某些组件可能在缩放单元中的所有租户之间共享。 其他组件可以在一个区域中的所有缩放单元之间共享，甚至可在所有区域和缩放单元之间全球共享。 载入、重新配置或卸载租户时，控制平面需要知道如何处理这些共享组件。
添加或删除租户时，某些共享组件需要重新配置。 例如，假设你有一个全球共享的 Azure Front Door 配置文件。 如果添加具有自定义域名的租户，则控制系统可能需要更新配置文件，以便将该域名的请求路由到正确的应用程序。 同样，当租户卸载时，你的控制平面可能需要从 Azure Front Door 配置文件中删除该自定义域名，以避免子域接管攻击。
共享组件可能有复杂的缩放规则，控制平面需要遵循这些规则。 例如，如果使用装箱方法部署租户的数据库，则控制平面必须将每个新数据库分配给 Azure SQL 弹性池。
你可能会确定需要为每添加的第十个数据库增加分配给资源池的资源。 添加或删除租户时，控制平面需要重新评估池的配置，并决定是否更改池的资源。 达到可以分配给单个弹性池的最大数据库数时，需要创建新池，并将该池用于新租户数据库。 您的控制平面必须管理这些共享组件，包括在发生更改时根据变化进行缩放和重新配置它们。
当你的控制平面管理共享组件时，请务必注意争用条件，它可能会在多个操作并行发生时出现。 例如，如果在加入一个新租户的同时登出了另一个租户，则需要确保你的最终结束状态一致并满足缩放要求。
使用多个控制平面
在复杂的环境中，可能需要使用管理不同区域的多个控制平面。 许多多租户解决方案遵循部署标记模式，并跨多个标记对租户进行分区。 在此模式中，可能会为全局和标记责任创建单独的控制平面。
小窍门
跨多个控制平面进行协调会增加复杂性，因此尽量减少所生成的控制平面数。 大多数解决方案只需要一个控制平面。
全局控制平面
全局控制平面通常处理租户的总体管理和跟踪。 全局控制平面可以承担以下责任：
租户放置：全局控制平面决定租户应使用哪个标记。 它可能会根据租户的地区、每个戳记的容量利用率以及租户的服务质量要求等因素做出此决定。
租户载入和生命周期管理： 这些职责包括跨部署跟踪所有租户。
标记控制平面
每个部署标记都包含其自己的标记控制平面，用于管理分配给该标记的租户和资源。 标记控制平面可以承担以下责任：
租户资源预配： 它在集群内部创建和管理租户专属资源，例如，数据库和存储容器。
共享资源管理： 它监视 共享资源的 消耗，并在它们接近其最大容量时部署新实例。
维护操作： 它处理印章中的任务，例如数据库索引管理和清理操作。
每个标记的控制平面与全局控制平面协调。 例如，如果新租户注册，则全局控制平面最初可能会为租户的资源选择一个标记。 然后，全局控制平面提示标记的控制平面为租户创建必要的资源。
下图显示了两个控制平面如何在单个系统中共存。
该图包含三个带有控制面板的标记。 每个标记都有三个租户数据平面。 全局控制平面跨越所有三个标记。 租户分配是在全局控制平面上执行的。 租户加入发生在标记控制平面中。 应用程序访问发生在租户数据平面中。
租户控制平面
租户可以使用租户级别控制平面来管理其自己的逻辑或物理资源。 租户控制平面可以承担以下职责：
配置管理： 它处理特定于租户的配置，例如用户访问。
租户启动的维护操作： 它支持备份数据或下载以前备份等操作。
更新管理： 如果允许租户 控制其应用程序自己的更新，它将执行更新。
下图显示了一个复杂的系统，该系统具有全局控制平面、标记控制平面和租户控制平面。
供稿人
Microsoft维护本文。 以下参与者撰写了本文。
主要作者：
- John Downs |Azure 模式和做法的主要软件工程师
其他参与者：
- Bohdan Cherchyk | FastTrack for Azure 高级客户工程师
- Landon Pierce | FastTrack for Azure 客户工程师
- 丹尼尔·斯科特-伦斯福德 |合作伙伴技术策略师
- 阿森·弗拉基米尔斯基 | 客户首席工程师，FastTrack for Azure
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。