多租户应用的租赁模型

我们经常听到创建一个多租户应用的重要性，尤其是在开发软件即服务（SaaS）应用的背景下。

关于“多租户应用”的概念及开发所用的各种模型存在一些混淆。在这篇文章中，我们以更实用的方式仔细研究了这些术语。

从技术角度理解不同的租赁模型#

单租户架构#

单租户架构是一种软件或云计算模型，其中每个客户或租户都有一个专用的应用或服务实例。如果我们查看 B2B 商业模式的起源，它是从每个软件实例仅服务一个客户或组织开始的。

特点#

• 隔离: 每个客户或租户在一个隔离的环境中操作，拥有专用的资源、数据库和配置。
• 定制化: 单租户架构通常允许更大的定制化和灵活性以满足特定客户的需求。
• 安全性: 提升的安全性和数据隐私，因为客户数据不会与其他租户的数据混合。
• 可扩展性: 调整资源和容量可能更简单，因为可以独立调整每个租户的实例。
• 维护: 独立的维护和更新，因为对一个租户环境的改动不会影响其他租户。
• 成本: 由于需要为每个租户维护单独的实例，所以通常会有更高的基础设施和运营成本。

例子#

• 专用托管: 传统的网页托管提供商提供单租户架构，每个客户拥有自己的资源、数据库或配置。
• 本地软件: 一些企业级软件应用程序，如客户关系管理（CRM）或人力资源管理系统（HRMS），为有严格数据安全和定制要求的组织提供单租户部署选项。
• 带有高级级别的 SaaS: 在一些软件即服务（SaaS）产品中，高级或企业级别为需要增强安全性、合规性或定制化的客户提供单租户选项。

单租户架构通常用于合规性至关重要或需要定制安全要求的场景。例如，金融、医疗和政府等行业有严格的监管要求，常常偏好单租户解决方案以确保合规性。

然而，值得注意的是，与多租户架构相比，单租户架构可能需要更多资源并且管理更复杂，因为每个客户的实例都需要自己的基础设施和维护。因此，它们可能更适合于客户较少但更大的应用，或者需要重要的定制化和隔离。

多租户架构#

软件多租户是一种软件架构，其中一个实例的软件在服务器上运行并为多个租户服务。这样的系统是“共享的”（而不是“专用的”或“隔离的”）。一个租户是一组共享软件实例特定权限的用户。在多租户架构中，软件应用被设计为为每个租户提供实例的专用份额——包括数据、配置、用户管理、租户独特功能及非功能属性。 -- 维基百科

特点#

• 共享资源: 多个租户共享相同的基础设施，包括服务器、数据库和网络资源，以优化资源利用。
• 隔离: 租户的数据和配置是逻辑上隔离的，确保数据隐私和安全。
• 规模经济: 多租户可能更具成本效益，因为开销在多个用户间分摊，降低了运营和基础设施成本。
• 可扩展性: 该架构可以水平或垂直扩展，以适应日益增长的租户和用户数量。
• 维护: 更新和维护是统一的，因为更改适用于所有租户，简化了管理。
• 定制化: 尽管可以进行一些定制化，但通常比单租户架构更有限以维持系统的一致性。

例子#

• 基于云的 SaaS: 大多数软件即服务（SaaS）应用程序，如 Google Workspace 和 Salesforce，采用多租户来在共享平台上为多个组织或用户服务。
• 共享托管: 在网页托管中，共享托管服务在同一服务器上托管多个网站，每个网站属于不同的客户或组织。
• 公共云服务: 像 AWS 和 Azure 这样的公共云提供商使用多租户为不同客户提供共享数据中心内的虚拟隔离资源。
• 企业级基础设施解决方案: 比如一个由组织内多个业务单元使用的共享 Kubernetes 集群。

在现实世界中重新定义多租户应用#

我们从架构的角度提供了定义，使得区分多租户和单租户设计变得直观。然而，这更倾向于技术定义。如果在设计租赁模型时，在实际开发环境中使用这些定义，这种思维方式假设多租户应用必须拥有一个纯粹的共享多租户基础设施。

但是，业务和产品变化很大，并且有许多逐个情况的需求，所以没有通用的解决方案。

想象一个场景，其中租户使用共享基础设施的资源，但由于特定业务需求，他们需要系统的一到两个部分专门为他们服务。这些专用部分可能是数据库、实例或其他组件的组合，同时共享整体基础设施。这就是混合租户架构的用武之地。

在实际的 SaaS 产品开发中，常常会遇到这样的场景：产品主要是设计为通用的多租户模型。然而，架构或资源的某些方面可能朝着“单租户”方法发展。

AWS 用以下案例作为例子来传达这一概念：多租户是一个广泛的概念，并且是逐个情况结合和选择合适的策略来定义你想要实现的共享资源和数据隔离。

换句话说，有时人们仍然称这种模型为“多租户”，因此在多租户的广义定义中，它并不意味着解决方案中的每个组件都是共享的。相反，它意味着至少一些解决方案的组件在多个租户之间重用。

广泛理解这个术语可以更好地帮助你理解客户的需求及他们的背景。

而不是固定在单一的架构模型上，多租户反映了现实世界中 SaaS 产品架构的实用性。当我们提到多租户应用时，并不一定意味着应用完全遵循一个架构模型；它可能运用了多种租赁策略，意味着至少其一些组件是共享的。

决定你的租赁模型策略的关键考量#

问题来了，我该如何为我的产品提出租赁策略？以下是一些重要问题供你思考：

• 你的业务目标是什么？
• 单租户解决方案能否支持你的未来增长计划？
• 你的运营团队有多大，你可以自动化管理多少基础设施？你关注敏捷性和成本效率吗？
• 你的客户对不同的多租户选项感到满意吗？
• 每个选项如何影响合规性，包括你的和客户的合规性？
• 你预期达到服务级别协议（SLA）还是目标特定服务级别目标（SLO）？
• 你是否考虑过安全性、成本、性能、可靠性以及对个别租户需求的响应？

记住，在你的产品中没有必须选择纯多租户或纯单租户模型的严格划分。你的决定应该基于如何划分产品的架构组件，以及客户或业务所需的特定隔离级别。然后你可以相应地应用不同的方法。

继续#

我们讨论了多租户应用的“新”定义，那么租户隔离、身份及如何确定你的身份是否应被隔离呢？身份“隔离”是什么意思？

处理一个现实世界用户有两个不同身份的情况时，经常会产生混淆。是否适合将这种情况标记为“身份隔离”？

我们将在系列即将发布的文章中回答这些问题。敬请期待！