 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 在这个“云”山雾罩的时代，“多租户”是一个重要的概念，无论是公有云还是私有云，多租户的支持是必须的。那么什么是多租户呢？ 多租户是指软件架构支持一个实例服务多个用户（Customer），每一个用户被称之为租户（tenant），软件给予租户可以对系统进行部分 定制的能力，如用户界面颜色或业务规则，但是他们不能定制修改软件的代码。 由于共享开发和维护成本，都某些用户来说，多租户是一种经济的解决方案。从维护角度来说，多租户系统维护更加简单，相比于每个用户 一个实例的单租户系统，多租户系统提供者在系统变更时仅需更新一次，而单租户则需要针对每个用户进行更新，举个例子吧，操作系统可以视为 单租户系统，电子邮件则是典型的多租户系统（这里只说邮件服务系统，不是客户端），操作系统升级时，每个用户都要执行，而电子邮件的升级 无需用户参与。 在云计算领域，由于新的服务模型利用了虚拟化和远程访问，多租户的含义已被扩展。例如，软件即服务（SaaS）提供者，利用运行在一个数据 库实例上的应用系统，向多个用户提供Web访问服务。在这个场景下，租户之间的数据是隔离的，并且保证每个用户的数据对其他租户不可见。 租户租户是 SaaS 环境最基本的组成部分。作为构建应用程序的 SaaS 提供商，您要向客户提供此应用程序。我们将注册并使用您的环境的客户称为系统租户。例如，假设您的组织创建了某项会计服务，您希望将该服务提供给其他公司，让这些公司使用您的服务来管理其业务。其中的每一家公司都将被视为系统的租户。 租户在注册后通常会向租户管理员提供用户信息。然后，租户管理员可以登录系统，根据租户的业务需求对系统进行配置。其中包括能够将用户添加到给定的租户环境中。 在这种模式下提供的软件称为多租户 SaaS 系统，因为该服务的每个租户都使用一个共享的系统，该系统通过统一的体验来满足这些租户的需求。例如，对系统的更新通常会应用于该系统的所有租户。 跳转至主内容 此浏览器不再受支持。 请升级到 Microsoft Edge 以使用最新的功能、安全更新和技术支持。 你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。 可考虑用于多租户解决方案的租户模型可以通过多种方式设计要生成多租户的解决方案。 大多数情况下，此决定取决于租户之间是否共享资源以及如何共享资源。 直观地说，你可能希望避免共享任何资源，但随着业务规模拓展和越来越多的租户加入，这种情况会很快变得成本昂贵。 考虑多租户的不同模型会很有帮助，方法是先了解如何为特定组织定义租户、拥有哪些业务驱动因素以及如何规划缩放解决方案。 在此页上，我们为技术决策者提供有关你可考虑的租赁模型及其权衡的指导。 定义租户首先，需要为组织定义租户。 考虑客户是谁。 换言之，你向谁提供服务？ 有两种常见模型：
对租户的定义会影响构建解决方案时需要考虑或强调的某些事项。 例如，请考虑以下不同类型的租户：
如何决定使用哪一种模型？选择租赁模型不仅仅是技术决策；这也是需要确定的商业决策。 你需要考虑以下问题：
如果预计业务将扩展到大量客户，则部署共享基础结构非常重要。 否则，你必须维护大量且不断增加的实例。 为每个客户部署各个 Azure 资源可能是不可持续的，除非你为每个租户预配并使用专用订阅。 在多个租户之间共享同一 Azure 订阅时，随着每个新客户的增加，Azure 资源配额和限制可能会开始应用，部署和重新配置这些资源的运营成本会变得更高。 相反，如果你预计你的业务只会有少许客户，那么你可以考虑部署专用于每个客户的单租户资源。 同样，如果客户的隔离要求很高，则单租户基础结构可能比较合适。 逻辑租户和物理租户接下来，需要确定租户对特定解决方案的含义，以及是否应区分逻辑租户和物理租户。 例如，请考虑音乐流式处理服务。 最初，你可以生成一个解决方案，用于轻松应对数千（甚至数万）位用户。 不过，随着持续增长，你可能会发现需要复制解决方案或其某些组件，以便拓展到新的客户需求。 这意味着需要弄清楚如何将特定客户分配给解决方案的特定实例。 可以随机或按地理位置执行此操作，或者通过填充单个实例，然后溢出到另一个实例。 但是，你可能需要保留自己拥有哪些客户以及其数据和应用程序可用的基础结构的记录，以便能够将其流量路由到正确的基础结构。 在此例中，可以将每位用户表示为单独的逻辑租户，然后将用户映射到表示已部署的不同实例的物理租户。 逻辑租户与物理租户之间有一对多映射，可以自行决定在物理租户之间移动逻辑租户。 相比之下，请考虑为律师事务所生成云软件的公司。 客户可能坚持使用自己的专用基础结构来维护其合规性标准。 因此，需要准备好从一开始就部署和管理解决方案的许多不同实例。 在此例中，逻辑租户和物理租户相同。 逻辑租户与物理租户之间的主要区别在于隔离是如何实施的。 当多个逻辑租户共享一组基础结构时，你通常依赖于应用程序代码和数据库中的租户标识符来使每个租户的数据保持独立。 当你拥有物理租户时，它们有自己的基础结构，因此，让你的代码意识到它是在多租户环境中运行可能就不那么重要了。 有时，你会看到称为部署、超租户或标记的物理租户。 本文档的其余部分使用术语“部署”和“物理部署”，以免在逻辑租户与物理租户之间产生混淆。 收到对特定逻辑租户的请求时，你需要将其映射到保存该租户的数据的物理部署，如下所示： 租户隔离在设计多租户体系结构时，最大的注意事项之一是每个租户所需的隔离级别。 隔离可能意味着不同的事项：
应该将隔离视为一个连续体，而不是将隔离视为一个离散的属性。 可以根据要求，在你的体系结构中部署比同一体系结构中的其他组件更多或更少隔离的组件。 下图展示了隔离的连续体： 隔离级别影响你的体系结构的许多方面，包括下列各项：
解决方案体系结构可能会影响可用于隔离的选项。 例如，我们考虑一个三层解决方案体系结构示例：
可以考虑在每一层混合和匹配不同级别的隔离。 共享内容和隔离内容的确定将基于许多考虑因素，包括成本、复杂性、客户需求以及在达到 Azure 配额和限制之前可以部署的资源数量。 常见租户模型确定要求后，请根据一些常见租户模型和相应部署模式对其进行评估。 自动单租户部署在自动化单租户部署模型中，为每位租户部署一组专用基础结构，如以下示例所示： 应用程序负责启动和协调各租户资源的部署。 通常，使用此模型生成的解决方案广泛使用基础结构即代码 (IaC) 或 Azure 资源管理器 API。 需要为每位客户预配完全独立的基础结构时，可使用此方法。 规划部署时，请考虑部署标记模式。 优势：此方法的主要优势在于，各租户的数据都是独立的，这可降低意外泄漏的风险。 对于一些具有高法规合规性开销的客户来说，这可能很重要。 此外，租户不太可能影响彼此的系统性能，这有时称为“近邻干扰”问题。 可以逐步在租户之间推出更新和更改，从而减少系统范围服务中断的可能性。 风险：成本效率较低，因为你不在租户之间共享基础结构。 如果单位租户需要在基础结构上花费一定金额，那么 100 位租户可能需要花费 100 倍的成本（支出）。 此外，持续维护（如应用新配置或软件更新）可能很耗时。 请考虑自动执行操作过程，并考虑逐步通过环境应用更改。 还应考虑其他跨部署操作，例如整个资产的报告和分析。 同样，请确保规划如何跨多个部署查询和操作数据。 完全多租户部署相反的情况下，可以考虑完全多租户部署，其中所有组件都共享。 你只需部署和维护一套基础架构，所有租户都使用它，如下图所示： 优势：这种模型很有吸引力，因为使用共享组件运行解决方案的成本较低。 即使需要部署较高层级或资源的 SKU，总体部署成本仍常常低于一组单租户资源。 此外，如果用户或租户需要将其数据移动到另一逻辑租户，则无需在两个单独的部署之间迁移数据。 风险：
垂直分区部署你不必处于这些规模的极端。 而是可以考虑将租户垂直分区，并按照以下步骤：
以下示例演示了某些租户的共享部署，以及另一租户的单租户部署： 优势：由于仍在共享基础结构，因此仍可以获得共享多租户部署的一些成本优势。 可以为某些客户部署更便宜的共享资源，例如要试用服务的客户。 甚至可以向客户收取更高的单租户部署费用，从而收回部分成本。 风险：代码库可能需要设计为支持多租户部署和单租户部署。 如果计划允许在基础结构之间进行迁移，则需要考虑如何将客户从多租户部署迁移到自己的单租户部署。 你还需要清楚地了解哪些逻辑租户位于哪些物理基础结构集上，以便能够向相关客户传达有关系统问题或升级的信息。 水平分区部署还可以考虑水平分区部署。 这意味着你拥有一些共享组件，同时使用单租户部署维护其他组件。 例如，可以生成单个应用层，然后为每位租户部署单个数据库，如下图所示： 优势：如果已确定系统上的大部分负载是由于可为每位租户单独部署的特定组件，水平分区部署有助于缓解近邻干扰问题。 例如，数据库可能会吸收系统的大部分负载，因为查询负载很高。 如果单个租户向解决方案发送大量请求，则数据库的性能可能会受到负面影响，但其他租户的数据库（和共享组件，如应用层）仍不受影响。 风险：使用水平分区的部署，仍需考虑组件自动部署和管理，尤其是单个租户使用的组件。 测试隔离模型无论选择哪种隔离模型，请确保测试解决方案，以验证一位租户的数据是否不会意外泄露到另一租户，并且任何近邻干扰的影响均可接受。 请考虑使用 Azure Chaos Studio 以故意引入模拟实际中断的故障，并验证解决方案的复原能力，即使组件发生故障也是如此。 后续步骤考虑租户的生命周期。 反馈 |
Tenant租户
版權 © 2024 zh.wiewird Inc.
