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