简体中文
多租户应用的租赁模型
深入探讨“多租户”概念，并分享我们对这一概念的看法。
Guamian
Product & Design
Product & Design
深入探讨“多租户”概念，并分享我们对这一概念的看法。
我们经常听到创建一个多租户应用的重要性，尤其是在开发软件即服务（SaaS）应用的背景下。
关于“多租户应用”的概念及开发所用的各种模型存在一些混淆。在这篇文章中，我们以更实用的方式仔细研究了这些术语。
单租户架构是一种软件或云计算模型，其中每个客户或租户都有一个专用的应用或服务实例。如果我们查看 B2B 商业模式的起源，它是从每个软件实例仅服务一个客户或组织开始的。
单租户架构通常用于合规性至关重要或需要定制安全要求的场景。例如，金融、医疗和政府等行业有严格的监管要求，常常偏好单租户解决方案以确保合规性。
然而，值得注意的是，与多租户架构相比，单租户架构可能需要更多资源并且管理更复杂，因为每个客户的实例都需要自己的基础设施和维护。因此，它们可能更适合于客户较少但更大的应用，或者需要重要的定制化和隔离。
软件多租户是一种软件架构，其中一个实例的软件在服务器上运行并为多个租户服务。这样的系统是“共享的”（而不是“专用的”或“隔离的”）。一个租户是一组共享软件实例特定权限的用户。在多租户架构中，软件应用被设计为为每个租户提供实例的专用份额——包括数据、配置、用户管理、租户独特功能及非功能属性。 -- 维基百科
我们从架构的角度提供了定义，使得区分多租户和单租户设计变得直观。然而，这更倾向于技术定义。如果在设计租赁模型时，在实际开发环境中使用这些定义，这种思维方式假设多租户应用必须拥有一个纯粹的共享多租户基础设施。
但是，业务和产品变化很大，并且有许多逐个情况的需求，所以没有通用的解决方案。
想象一个场景，其中租户使用共享基础设施的资源，但由于特定业务需求，他们需要系统的一到两个部分专门为他们服务。这些专用部分可能是数据库、实例或其他组件的组合，同时共享整体基础设施。这就是混合租户架构的用武之地。
在实际的 SaaS 产品开发中，常常会遇到这样的场景：产品主要是设计为通用的多租户模型。然而，架构或资源的某些方面可能朝着“单租户”方法发展。
AWS 用以下案例作为例子来传达这一概念：多租户是一个广泛的概念，并且是逐个情况结合和选择合适的策略来定义你想要实现的共享资源和数据隔离。
换句话说，有时人们仍然称这种模型为“多租户”，因此在多租户的广义定义中，它并不意味着解决方案中的每个组件都是共享的。相反，它意味着至少一些解决方案的组件在多个租户之间重用。
广泛理解这个术语可以更好地帮助你理解客户的需求及他们的背景。
而不是固定在单一的架构模型上，多租户反映了现实世界中 SaaS 产品架构的实用性。当我们提到多租户应用时，并不一定意味着应用完全遵循一个架构模型；它可能运用了多种租赁策略，意味着至少其一些组件是共享的。
问题来了，我该如何为我的产品提出租赁策略？以下是一些重要问题供你思考：
记住，在你的产品中没有必须选择纯多租户或纯单租户模型的严格划分。你的决定应该基于如何划分产品的架构组件，以及客户或业务所需的特定隔离级别。然后你可以相应地应用不同的方法。
我们讨论了多租户应用的“新”定义，那么租户隔离、身份及如何确定你的身份是否应被隔离呢？身份“隔离”是什么意思？
处理一个现实世界用户有两个不同身份的情况时，经常会产生混淆。是否适合将这种情况标记为“身份隔离”？
我们将在系列即将发布的文章中回答这些问题。敬请期待！