什么是多租户 (Multi-tenancy)？
软件多租户 (Multi-tenancy) 是一种 软件架构 ，其中单个 软件 的 实例 运行在一台服务器上并为多个租户服务。以这种方式设计的系统是“共享的”，而不是“专用的”或“隔离的”。
租户是共享对软件实例的特定权限的用户群体。
当服务商为多个客户提供标准化服务时，经常更倾向于多租户架构。这些服务通常只有最小的定制化，所有客户共享同一个应用程序实例。当应用程序更新时，它将同时适用于所有客户。
例如，CRM（客户关系管理）系统经常使用多租户架构为所有客户提供相同的服务。
多租户的一个关键原则是“共享”。这并不意味着解决方案的每个部分都是共享的；这意味着至少有一些组件可供多个租户重用。理解这个更广泛的概念可以帮助你更好地满足客户的需求。
多租户 (Multi-tenancy) 产品的使用案例有哪些？
多租户应用程序通常用于软件即服务 (SaaS) 产品中，如生产力工具、协作软件等。在这种设置中，每个“租户”通常代表一个商业客户，并有多个用户（通常是员工）。在不同的产品中，它可能被称为租户、工作区或项目，具体取决于上下文。一个企业也可能有多个租户来代表不同的部门或组织。
在更复杂的情况下，如超越 SaaS 的 B2B 应用程序，多租户应用程序为不同的团队、商业客户和合作伙伴公司提供了一个共享平台来访问你的服务。
为什么要在 SaaS 产品中采用多租户 (Multi-tenancy)
通过多租户 (Multi-tenancy) 实现扩展
对企业业务而言，多租户是有效满足其可用性、资源管理、成本管理和数据安全性要求的关键。从技术层面来看，采用多租户方法可简化开发流程，减少技术挑战，促进平滑扩展。
创造统一的体验
当审视 SaaS 产品的根源时，它类似于一个包含多个公寓的建筑。所有租户共享公共设施，如水、电和煤气，但他们可以独立管理自己的空间和资源。这种方法简化了物业管理。
通过租户隔离确保安全
在多租户架构中，引入了“租户”一词，以创建分隔不同租户资源和数据的界限，并确保在共享实例中保持安全。这确保了即使在使用相同的底层资源时，各租户的数据和操作仍保持独立和安全。
在多租户 (Multi-tenancy) 架构中如何实现租户隔离？
在讨论多租户应用程序时，总是需要实现租户隔离。这意味着在共享系统（例如，云基础设施或多租户应用程序）中保持不同租户的数据和资源分离和安全。这防止了任何未经授权的尝试访问其他租户的资源。
虽然解释可能显得抽象，但我们将通过示例和关键细节进一步解释隔离思维和实现租户隔离的最佳实践。
租户隔离并不违背多租户的“共享”理念
这是因为租户隔离不一定是基础设施资源级别的结构。在多租户和隔离的领域中，一些人将隔离视为实际基础设施资源之间的严格划分。这通常导致一个模型，其中每个租户都有独立的数据库、计算实例、账户或私有云。在共享资源的场景中，如多租户应用程序，实现隔离的方法可以是逻辑上的结构。
在架构的设计中，可以实现不同程度的租户之间的资源隔离：
通常，共享资源的越多，系统迭代和维护的成本就越低。相反，资源共享的越少，成本就越高。
租户隔离专注于使用“租户”上下文来限制对资源的访问。它评估当前租户的上下文，并使用该上下文确定该租户可访问哪些资源。
认证 (Authentication) 和授权 (Authorization) 不等于“隔离”
使用认证 (Authentication) 和授权 (Authorization) 来控制访问你的 SaaS 环境很重要，但这不足以实现完全隔离。这些机制只是安全难题的一部分。
人们常问一个问题，我可以使用通用的授权 (Authorization) 解决方案和基于角色的访问控制 (RBAC) 来实现租户隔离吗？
你可以构建一个多租户应用程序，但不能说你遵循最佳实践实现和采用了租户隔离策略。我们通常不推荐这样做，因为租户隔离与认证 (Authentication) 和授权 (Authorization) 是独立的。
举例来说，考虑一个场景，你已为你的 SaaS 系统设置了认证 (Authentication) 和授权 (Authorization)。当用户登录时，他们会收到一个令牌，其中包含关于他们角色的信息，决定了他们在应用程序中可以做什么。这种方法提高了安全性，但并不保证隔离。
使用“组织”作为上下文代表 SaaS 产品租户，以实现租户隔离
单靠认证 (Authentication) 和授权 (Authorization) 不会阻止具有正确角色的用户访问其他租户的资源。因此，我们需要并入一个“租户”上下文，比如租户 ID，以限制对资源的访问。
这就是租户隔离发挥作用的地方。它使用特定于租户的标识符来建立边界，就像墙壁、门和锁一样，确保租户之间的明确分隔。
在多租户应用程序中如何管理身份？
我们讨论了租户隔离，那么身份呢？你如何确定你的身份是否应该“隔离”？
关于“身份隔离”这个概念经常会有困惑。它可能指的是在一般理解中，一个现实世界的用户拥有两个身份的情况。
- 两个身份可以存在于单个身份系统中。例如，Sarah 可能有一个个人电子邮件注册以及一个通过单点登录 (SSO) 连接的公司电子邮件。
- 用户在不同的身份系统中维护两个独立的身份，代表完全不同的产品。这些产品彼此完全无关。
有时，这些情况被称为“身份隔离”，但这个术语可能对决策帮助不大。
与其问是否需要“身份隔离”，不如考虑你业务或产品的某些部分是否需要单独的身份系统。这将指导你的系统设计。对于多租户应用而言，在大多数情况下，身份是共享的，而每个租户的资源是保持分开的。
在多租户应用程序中，身份在租户之间共享，不同于仅限租户的资源和数据。这就像是一个楼宇管理员——你不想维护两个单独的租户姓名列表。
当目标是实现租户隔离时，经常会提到“组织”这个术语，因为这是构建多租户应用的最佳实践。
通过在许多 CIAM（顾客身份管理）或认证 (Auth) 服务中使用“组织”，你可以在多租户应用中实现租户隔离，同时仍维持统一的身份系统。
如何选择合适的授权 (Authorization) 模型来实现更好的访问控制？
在选择合适的授权 (Authorization) 模型时，考虑以下问题：
- 你是在开发一个 B2C、B2B 产品，还是两者的组合？
- 你的应用程序是否具有多租户架构？
- 你的应用程序中是否需要由业务部门确定的某种隔离级别？
- 需要在组织的上下文中定义哪些权限和角色，以及哪些不需要？