1、多租户基础概念：SaaS多租户定义、租户与用户的关系、ThingsBoard中的租户模型概述
1.1 SaaS多租户定义
多租户（Multi-Tenancy）是SaaS（Software as a Service）架构的核心特征，指单个软件实例同时服务于多个独立组织（租户）的能力。每个租户在逻辑上拥有专属的运行环境，包括数据、配置、用户和资源，但共享底层的基础设施与应用程序代码。
核心特征：
- 共享实例：所有租户运行在同一套应用代码和数据库实例上。
- 逻辑隔离：租户之间的数据、配置、设备、规则链完全隔离，互不可见。
- 可扩展性：新增租户无需部署新实例，仅需在系统中创建租户记录。
- 按需计费：租户根据实际使用的资源（设备数、消息量、存储量）付费。
在物联网平台场景中，多租户意味着一个平台可以同时为多个企业客户提供设备管理、数据采集、规则引擎和可视化仪表板服务，而每个企业客户只能看到自己的设备和数据。
1.2 租户与用户的关系
租户（Tenant）和用户（User）是多租户体系中最基础的两个实体，它们之间存在明确的层级归属关系：
| 实体 | 定义 | 示例 |
|---|---|---|
| 租户 | 一个独立的组织或客户，拥有自己的设备、资产、仪表板和规则链。 | 某智慧工厂、某连锁超市、某水务公司 |
| 用户 | 属于某个租户的个体操作者，拥有登录凭证和角色权限。 | 工厂管理员、运维工程师、门店经理 |
关键关系要点：
- 一个租户包含多个用户：租户是用户的容器，用户必须归属于某个租户才能登录系统。
- 用户不能跨租户：用户只能访问其所属租户的资源，无法查看其他租户的数据。
- 租户管理员：每个租户可以指定一个或多个用户作为租户管理员，负责管理本租户内的用户、设备和配置。
- 系统管理员：平台运营方拥有系统管理员角色，可以管理所有租户，但通常不直接操作租户内部数据。
实践提示：在ThingsBoard中，租户管理员可以创建、编辑、删除本租户下的用户，并为用户分配角色（如租户管理员、租户用户、客户用户）。系统管理员则可以在租户级别进行资源配额限制。
1.3 ThingsBoard中的租户模型概述
ThingsBoard采用三层层级模型来组织多租户架构：系统层 → 租户层 → 客户层。每一层都有明确的职责和资源边界。
1.4 租户模型中的核心实体
在ThingsBoard的租户模型中，以下实体构成了多租户资源隔离的基本单元：
| 实体 | 所属层级 | 隔离范围 | 说明 |
|---|---|---|---|
| Tenant | 租户层 | 全局唯一 | 租户本身，包含名称、域名、联系人、资源配额等属性 |
| Device | 租户层 | 租户内唯一 | 物联网设备，每个设备属于一个租户，设备凭证在租户内隔离 |
| Asset | 租户层 | 租户内唯一 | 资产（如建筑、生产线、车辆），用于组织设备层级 |
| Dashboard | 租户层 | 租户内唯一 | 可视化仪表板，可分配给租户或客户 |
| Rule Chain | 租户层 | 租户内唯一 | 规则链，定义数据流转和处理逻辑 |
| Customer | 客户层 | 租户内唯一 | 租户的终端客户，可拥有自己的用户和授权设备 |
| User | 租户/客户层 | 所属层级内唯一 | 系统用户，通过角色绑定到租户或客户 |
1.5 租户资源隔离机制
ThingsBoard通过以下机制实现租户间的强隔离：
- 数据隔离：所有数据库表通过
tenant_id字段进行逻辑分区，查询时自动过滤。 - 设备凭证隔离：设备接入令牌（Access Token）、MQTT用户名密码、X.509证书在租户间不可复用。
- 规则链隔离：每个租户拥有独立的规则链执行环境，规则链中的节点只能访问本租户的设备数据。
- 仪表板隔离：仪表板资源按租户分组，租户管理员只能看到本租户创建的仪表板。
- API访问隔离：REST API和WebSocket连接通过租户上下文进行权限校验。
注意：ThingsBoard的租户隔离是逻辑隔离而非物理隔离。在极端高安全场景下，可能需要结合数据库分库或独立部署实例来增强隔离性。但在绝大多数SaaS场景中，逻辑隔离已满足合规要求。
1.6 租户生命周期
一个租户在ThingsBoard中的典型生命周期包含以下阶段：
- 创建：系统管理员通过UI或REST API创建租户，设置名称、域名和初始配额。
- 配置：租户管理员登录后，配置本租户的邮件服务器、通知设置、设备配置文件等。
- 运营：租户管理员创建用户、添加设备、构建仪表板和规则链，进入日常运营。
- 监控：系统管理员监控租户的资源使用情况，必要时调整配额。
- 停用/删除：租户到期或退订后，系统管理员可停用或删除租户，释放资源。