3. 租户与客户模型：Tenant与Customer实体关系、层级结构、权限边界划分
在 ThingsBoard 的多租户架构中，Tenant（租户） 和 Customer（客户） 是核心的实体模型。理解它们之间的关系、层级结构以及权限边界，是实现数据安全隔离与资源精细化管理的基石。本章将深入剖析这两个实体的定义、关联方式以及在实际部署中的权限划分策略。
3.1 实体关系与层级结构
ThingsBoard 采用两层租户模型：顶层为 Tenant，下层为 Customer。一个 Tenant 可以拥有多个 Customer，但一个 Customer 只能属于一个 Tenant。这种一对多的关系构成了平台资源隔离的基本单元。
核心概念： Tenant 是资源的拥有者和计费主体，Customer 是资源的最终使用者和消费者。Tenant 负责创建和管理 Customer，并为每个 Customer 分配设备、仪表板、规则链等资源。
下表总结了 Tenant 与 Customer 的关键属性差异：
| 属性维度 | Tenant（租户） | Customer（客户） |
|---|---|---|
| 层级位置 | 顶层实体，系统管理员之下 | 第二层实体，隶属于 Tenant |
| 资源所有权 | 拥有设备、资产、仪表板、规则链等全部资源 | 被授予使用 Tenant 资源的权限，不拥有所有权 |
| 用户管理 | 管理本租户下的所有用户（包括 Customer 用户） | 管理本客户下的用户（仅限客户级用户） |
| 数据可见性 | 可见本租户下所有设备和客户的数据 | 仅可见被授权给自己的设备和资产数据 |
| 计费模型 | 作为计费主体，向平台支付费用 | 通常由 Tenant 向其收费，或作为 Tenant 内部的成本中心 |
| 典型场景 | 一个企业（如智慧园区运营商） | 该企业下的一个具体项目或终端客户（如某栋楼宇） |
下图展示了 Tenant 与 Customer 在 ThingsBoard 实体模型中的层级关系：
3.2 权限边界划分
权限边界是租户隔离的核心。ThingsBoard 通过实体组（Entity Group）和角色（Role）机制，在 Tenant 和 Customer 之间划定了清晰的权限边界。
3.2.1 默认权限边界
- Tenant 管理员：拥有其租户内所有资源的完全控制权，包括创建/删除 Customer、管理所有设备、配置规则链、查看所有遥测数据。
- Customer 用户：默认情况下，只能看到自己被授权的设备、资产和仪表板。无法查看其他 Customer 的资源，也无法访问 Tenant 级别的配置（如规则链、邮件服务器设置）。
- 数据隔离：Customer 用户通过 REST API 或 MQTT 请求数据时，ThingsBoard 会自动在查询条件中附加
customerId过滤，确保不会返回其他客户的数据。
常见误区： 不要将 Customer 用户视为“受限的 Tenant 管理员”。Customer 用户没有管理用户、创建规则链或修改系统设置的权限。如果业务需要更细粒度的控制，必须使用 ThingsBoard 的 RBAC（基于角色的访问控制）功能。
3.2.2 资源分配与权限模型
Tenant 将资源分配给 Customer 的过程称为 Assignment（分配）。分配后，Customer 用户才能看到并使用这些资源。分配的资源类型包括：
| 资源类型 | 分配方式 | Customer 用户权限 |
|---|---|---|
| 设备 | 在设备详情页中指定所属 Customer | 查看遥测数据、属性、发送 RPC 命令（需额外授权） |
| 资产 | 在资产详情页中指定所属 Customer | 查看资产信息、关联的设备列表 |
| 仪表板 | 在仪表板详情页中分配 Customer 或 Customer 用户 | 查看仪表板内容（只读或可编辑，取决于分配时的设置） |
| 实体组 | 创建实体组后，将 Customer 添加为组成员 | 查看组内所有实体，便于批量管理 |
下图展示了 Tenant 如何将设备资源分配给不同的 Customer，并形成数据访问边界：
3.3 多租户数据隔离机制
ThingsBoard 在数据库层面和 API 层面都实施了严格的隔离策略：
- 数据库隔离：所有实体表（如
device、asset、alarm）都包含tenant_id和customer_id字段。查询时自动附加这些字段作为过滤条件。 - API 隔离：REST API 和 WebSocket API 在解析请求时，会从 JWT Token 中提取用户角色和所属租户/客户信息，拒绝越权访问。
- 规则链隔离：规则链属于 Tenant 级别资源。Customer 用户无法创建或修改规则链，但 Tenant 可以创建针对特定 Customer 的规则链节点，实现客户特定的数据处理逻辑。
最佳实践： 在设计 IoT 解决方案时，建议将每个终端客户映射为一个 ThingsBoard Customer。这样既能享受平台提供的天然数据隔离，又能通过 Tenant 统一管理设备模板、规则链和仪表板模板，实现“一次开发，多次部署”的规模化效应。
3.4 实际应用场景示例
假设一个智慧楼宇管理平台（Tenant）为三栋不同的写字楼（Customer A、B、C）提供服务：
- Tenant 管理员：创建楼宇设备模型（温度传感器、门禁控制器），编写规则链（告警规则、数据持久化策略），设计通用仪表板模板。
- 资源分配：将 A 楼的 50 个传感器分配给 Customer A，B 楼的 30 个传感器分配给 Customer B，C 楼的 20 个传感器分配给 Customer C。
- 客户访问：Customer A 的用户登录后，只能看到 A 楼的传感器数据、告警和专属仪表板。无法搜索或访问 B 楼和 C 楼的任何设备。
- 数据安全：即使 Customer A 的用户通过 REST API 直接请求设备列表，返回的结果也仅包含 A 楼的设备，实现了强制的数据边界。
通过这种模型，ThingsBoard 在保证多租户数据安全的同时，也提供了灵活的资源管理和规模化扩展能力。