在如何处理解决方案中的租户方面，有很多可以考虑的方式。 你选择的方法在很大程度上取决于是否要在租户之间共享资源，以及如何共享资源。 直观地说，你可能希望避免共享任何资源，但随着业务规模拓展和越来越多的租户加入，这样的做法会迅速产生高昂的费用。
考虑多租户的各种模型时，首先考虑如何为组织定义租户、业务驱动因素有哪些以及如何规划解决方案缩放会很有帮助。 本文提供可帮助技术决策者评估租赁模型并进行相关权衡的指导。
定义租户
首先，需要为组织定义租户。 考虑客户是谁。 换言之，你向谁提供服务？ 有两种常见模型：
- 企业对企业 (B2B)。 如果你的客户是其他组织，你很可能要将你的租户与这些客户对应起来。 然而，需要考虑你的客户是否有分支（团队或部门），或者他们是否在多个国家/地区有分支机构。 如果这些子分组有不同的要求，你可能需要将单个客户映射到多个租户。 同样，客户可能需要维护服务的两个实例，这样他们就可以将自己的开发和生产环境分开。 一个租户通常会有多个用户。 例如，客户的所有员工都是单个租户中的用户。
- 企业对消费者 (B2C)。 如果你的客户是消费者，那么将客户、租户和用户联系起来往往会更复杂。 在部分情况下，每位消费者可能都使用单独的租户。 但是，请考虑你的解决方案是否可供家庭、朋友团体、俱乐部、协会或其他可能需要共同访问和管理其数据的团体使用。 例如，一个音乐流媒体服务可能同时支持个人用户和家庭，当涉及到将每个帐户类型分离成租户时，可能会以不同的方式进行处理。
对租户的定义会影响构建解决方案时需要考虑或强调的某些事项。 例如，请考虑以下类型的租户：
- 如果租户是个人或家庭，则可能尤其需要关注如何处理个人数据，并考虑到服务所涉及的每个司法管辖区中的数据主权法律。
- 如果租户是企业，则可能需要注意客户在法规合规性以及数据隔离方面的要求，并确保满足指定的服务级别目标 (SLO)，例如运行时间或服务可用性。
如何决定使用哪一种模型？
选择租赁模型不仅仅是一项技术决策。 这也是一项商业决策。 你需要考虑很多问题，例如：
- 你的业务目标是什么？
- 你的客户是否会接受所有形式的多租户？ 每个多租户模型将如何影响你的合规性要求或你的客户的合规性要求？
- 单租户解决方案是否能扩展以满足你未来的增长愿景？
- 你的运营团队有多大，以及你能够在多大程度上将基础结构管理工作自动化？
- 你的客户是否期望你满足服务级别协议 (SLA)，或者你是否有打算实现的 SLA？
如果预计自己的业务将扩展至拥有大量客户，请务必部署共享的基础结构。 否则，你必须维护大量且不断增加的资源实例。 为每个客户部署单独的 Azure 资源可能不是长久之计，除非为每个租户预配和使用专用订阅。 在多个租户之间共享同一 Azure 订阅时，随着每个新客户的增加，Azure 资源配额和限制可能会开始应用，部署和重新配置这些资源的运营成本会变得更高。
相反，如果你预计自己的业务只会有少许客户，那么可以考虑采用专用于每个客户的单租户资源。 同样，如果客户的隔离要求很高，则即使成本更高，单租户基础结构方法可能也比较合适。
租户和部署
接下来，需要确定租户在特定解决方案中的含义，以及是否应区分逻辑租户和部署。
例如，请考虑音乐流式处理服务。 最初，你可以生成一个能轻松处理数千（甚至数万）位用户的解决方案。 不过，随着持续增长，你可能会发现需要复制解决方案或其某些组件，以便拓展到新的客户需求。 这意味着需要确定如何将特定客户分配给解决方案的特定实例。 可以随机或按地理位置来分配客户，或者填充单个实例，然后开始填充另一个实例（装箱）。 但是，你可能需要保留自己的客户及其数据和应用程序可用的基础结构的记录，以便能够将其流量路由到正确的基础结构。 在此示例中，可将每个客户表示为单独的租户，然后将用户映射到包含其数据的部署。 租户和部署之间存在一对多映射，并且你可以自行决定是否在部署间移动租户。
作为对照，我们以为律师事务所创建云软件的公司为例。 客户可能坚持使用自己的专用基础结构来维护其合规性标准。 因此，需要从一开始就准备好部署和管理解决方案的许多不同实例。 在此示例中，部署始终包含单个租户，而租户映射到其自己的专用部署。
租户和部署之间的一个重要差别是如何强制实施隔离。 当多个租户共享单个部署（一组基础结构）时，你通常依赖于应用程序代码和数据库中的租户标识符来使每个租户的数据保持独立。 如果租户具有自己的专用部署，它们就有自己的基础结构，因此，让你的代码意识到它是在多租户环境中运行可能就不那么重要了。
有时会看到被称为超级租户或缩放单元的部署。
收到对特定租户的请求时，你需要将其映射到保存该租户的数据的部署，如下所示：
若要了解详细信息，请参阅将请求映射到租户。
租户隔离
在设计多租户体系结构时，最重大的注意事项之一是每个租户所需的隔离级别。 隔离可能意味着不同的事项：
- 采用单个共享基础结构，每个租户都有单独的应用程序实例和单独的数据库。
- 共享一些常见资源，又为每个租户保持其他资源的独立性。
- 将数据保留在独立的物理基础结构上。 在云中，此配置可能需要为每个租户使用单独的 Azure 资源。 在极端情况下，这甚至可能意味着要使用专用主机部署单独的物理基础结构。
应该将隔离视为一个连续体，而不是将其视为一个离散的属性。 可以根据要求，在你的体系结构中部署比同一体系结构中的其他组件更多或更少隔离的组件。 下图展示了隔离的连续体：
隔离级别会影响体系结构的许多方面，包括下列各项：
- 安全性。 如果在多个租户间共享基础结构，则需要特别小心，不要在向一个租户返回响应时访问来自另一个租户的数据。 你需要为标识策略提供坚实的基础，并且在授权过程中需要同时考虑租户和用户标识。
- 成本。 共享基础结构可由多个租户使用，因此更实惠。
- 性能。 如果要共享基础结构，则系统的性能可能会随着使用者的增加而受到影响，因为资源可能消耗得更快。 租户使用模式异常可能会加剧性能问题。
- 可靠性。 如果使用的是单个共享基础结构集，则一个组件出现问题可能会导致所有租户中断。
- 响应各个租户的需求。 部署专用于一个租户的基础结构时，可针对该特定租户的要求调整资源配置。 甚至可以在定价模型中考虑该功能，让客户能够为独立部署支付更多费用。
解决方案体系结构可能会影响可用的隔离选项。 以三层式解决方案体系结构为例：
- 用户界面层可能是共享多租户 Web 应用，所有租户都访问单个主机名。
- 中间层可以是共享应用程序层，具有共享消息队列。
- 数据层可以是独立的数据库、表或 blob 容器。
可以考虑在每一层采用不同级别的隔离。 应根据许多考虑因素来确定共享内容和隔离内容，包括成本、复杂性、客户需求以及在达到 Azure 配额和限制之前可以部署的资源数量。
常见租户模型
确定要求后，请根据一些常见租户模型和相应部署模式对其进行评估。
自动单租户部署
在自动化单租户部署模型中，为每位租户部署一组专用基础结构，如以下示例所示：
应用程序负责启动和协调各租户资源的部署。 通常，使用此模型生成的解决方案广泛使用基础结构即代码 (IaC) 或 Azure 资源管理器 API。 需要为每位客户预配完全独立的基础结构时，可使用此方法。 规划部署时，请考虑使用部署缩放单元模式。
优势：此方法的主要优势在于，各租户的数据都是独立的，这可降低意外泄漏的风险。 对于一些在法规合规性方面开销较高的客户来说，这种保护措施可能会很重要。 此外，租户不太可能影响彼此的系统性能，这种问题有时被称为近邻干扰。 可以逐步在租户之间推出更新和更改，从而减少系统范围服务中断的可能性。
风险：如果使用此方法，则成本效率较低，因为不会在租户之间共享基础结构。 如果单个租户需要特定的基础结构成本，则 100 个租户可能需要 100 倍的成本。 此外，持续维护（如应用新配置或软件更新）可能会很耗时。 请考虑自动执行操作过程，并考虑逐步通过环境应用更改。 还应考虑其他跨部署操作，例如整个实例集的报告和分析。 同样，请务必规划好如何跨多个部署查询和操作数据。
完全多租户部署
相反的情况下，可以考虑完全多租户部署，其中所有组件都共享。 你只需部署和维护一套基础架构，就能让所有租户都使用它，如下图所示：
优势：此模型很有吸引力，因为操作具有共享组件的解决方案比为每个租户使用单个资源的成本更低。 即使需要部署较高层级或资源 SKU 来应对增加的负载，总体部署成本往往仍低于一组单租户资源。 此外，如果用户或租户需要将其数据移动到另一个租户，你可能能够更新租户标识符和密钥，并且可能不必在两个单独的部署之间迁移数据。
风险：
请务必分隔每个租户的数据，并且不要在租户之间泄露数据。 可能需要对数据分区已经管理。 此外，还可能需要关注单个租户对整个系统的影响。 例如，如果一个大型租户尝试执行繁重的查询或操作，可能影响其他租户。
确定跟踪 Azure 成本并将其与租户关联的方式（如果这对你很重要）。
对于单个部署，维护更简单，因为只需更新一组资源。 但这样也存在更高的风险，因为任何更改都可能会影响整个客户群。
可能还需要考虑缩放。 如果拥有一组共享基础结构，则更有可能达到 Azure 资源规模限制。 例如，如果使用存储帐户作为解决方案的一部分，则随着规模增长，对该存储帐户的请求数可能会达到存储帐户可处理的限制。 要避免达到资源配额限制，可以考虑部署一个由多个资源实例（例如，多个 AKS 群集或存储帐户）组成的池。 甚至可以考虑将租户分布至部署到多个 Azure 订阅的资源中。
在缩放单个部署的程度上可能会存在限制，并且这样做的成本可能会以非线性方式增加。 例如，如果采用单个共享数据库，那么在以非常高的规模运行时，可能会耗尽其吞吐量，并且必须为增加的吞吐量支付更多费用，以满足需求变化。
垂直分区部署
你并非只能选择其中一种极端的规模。 而是可以考虑通过采用此方法对租户进行垂直分区：
- 使用单租户部署和多租户部署的组合。 例如，你可能在多租户基础结构上有大多数客户的数据和应用层，但为需要更高性能或数据隔离的客户部署单租户基础结构。
- 按地理位置部署解决方案的多个实例，并将每个租户映射到特定部署。 有位于不同地理位置的租户时，该方法尤其有效。
以下示例演示了某些租户的共享部署，以及另一租户的单租户部署：
优势：因为仍在共享部分基础结构，所以仍可获得共享多租户部署的一些成本优势。 可以为某些客户部署更便宜的共享资源，例如要通过试用来评估你的服务客户。 甚至可以向客户收取更高的单租户部署费用，这有助于收回部分成本。
风险：需要对代码库进行设计，以同时支持多租户部署和单租户部署。 如果计划允许在部署之间进行迁移，则需要考虑如何将客户从多租户部署迁移到其自己的单租户部署。 你还需要了解哪些租户在哪些部署上，以便能够向相关客户传达有关系统问题或升级的信息。
水平分区部署
还可以考虑水平分区部署。 在水平部署中，你有一些共享组件，又使用单租户部署维护其他组件。 例如，可以生成单个应用层，然后为每位租户部署单个数据库，如下图所示：
优势：水平分区部署有助于缓解近邻干扰问题：如果已确定系统上的大部分负载是由特定组件引起的，那么可为每位租户部署单独的组件。 例如，数据库可能会吸收系统的大部分负载，因为查询负载很高。 如果单个租户向解决方案发送大量请求，则数据库的性能可能会受到负面影响，但其他租户的数据库（和共享组件，如应用层）仍不受影响。
风险：使用水平分区的部署，仍需考虑组件自动部署和管理，尤其是单个租户使用的组件。
测试隔离模型
无论选择哪种隔离模型，请确保测试解决方案，以验证一位租户的数据是否不会意外泄露到另一租户，并且任何近邻干扰的影响都是可接受的。 请考虑使用 Azure Chaos Studio 以故意引入模拟实际中断的故障，并验证解决方案的复原能力，即使组件发生故障也是如此。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- John Downs | 首席软件工程师
其他参与者：
- Chad Kittel | 首席软件工程师
- Paolo Salvatori | FastTrack for Azure 首席客户工程师
- 阿森·弗拉基米尔斯基|首席工程师，FastTrack for Azure
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。
后续步骤
考虑租户的生命周期