2、多租户架构基础：租户概念、多租户模型、隔离策略、ThingsBoard中的租户层级
好，咱们正式开始聊多租户。说实话，这个知识点是IoT平台的灵魂。你想想看，一个平台要服务成百上千个客户，每个客户的数据、设备、规则都不能串，靠什么？就是多租户架构。
我个人习惯把多租户比作「写字楼」。整栋楼是一个SaaS平台，每个公司租一层，门禁独立、水电独立、装修风格也独立。嗯，这个比喻虽然简单，但核心思想全在里面了。
2.1 租户概念：到底什么是「租户」？
租户（Tenant），说白了就是平台上的一个逻辑隔离单元。它不是一个物理服务器，也不是一个数据库实例，而是一组资源、数据和配置的集合。
我在项目中遇到过不少新人，上来就问：「租户是不是就是客户？」其实不完全对。客户可能是一个企业，但一个企业可以开多个租户，比如生产环境和测试环境各一个。所以更准确地说，租户是「客户在平台上的一个独立工作空间」。
租户的核心特征：
- 身份隔离：每个租户有独立的用户体系，A租户的用户看不到B租户的数据
- 资源隔离：设备、规则链、仪表板等资源归属明确
- 配置独立：告警规则、邮件模板、系统设置都可以按租户定制
- 计费独立：每个租户的使用量单独统计，方便做计量计费
你可能会问：「那租户和用户有什么区别？」好问题。用户是登录系统的个体，租户是用户所属的组织。一个租户下面可以有多个用户，比如管理员、操作员、只读用户等。这个层级关系，后面会详细讲。
2.2 多租户模型：三种主流实现方式
多租户的实现，业界主要有三种模型。我按隔离强度从高到低给你排个序：
| 模型 | 隔离级别 | 成本 | 适用场景 |
|---|---|---|---|
| 独立数据库 | 最高 | 高 | 金融、医疗等强合规场景 |
| 共享数据库、独立Schema | 中 | 中 | 大多数SaaS平台 |
| 共享数据库、共享Schema | 低 | 低 | 小型应用、内部系统 |
模型一：独立数据库
每个租户一个数据库实例。隔离性最好，但运维成本也最高。我记得有一次帮客户做POC，对方是银行，明确要求每个分行必须独立数据库。没办法，合规大于天。
模型二：共享数据库、独立Schema
所有租户在同一个数据库里，但每个租户有自己的Schema（在PostgreSQL里就是不同的Schema）。这是ThingsBoard默认采用的方式。我个人比较推荐这个方案，隔离性和成本之间取得了很好的平衡。
模型三：共享数据库、共享Schema
所有租户的数据混在同一个表里，通过tenant_id字段区分。成本最低，但隔离性也最差。一旦where条件写漏了，数据就串了。嗯，这里要特别小心。
避坑指南：我曾经在共享Schema模式下踩过坑。一个开发同事写SQL时忘了加tenant_id过滤，结果A租户的仪表板里出现了B租户的设备数据。虽然数据没丢，但客户投诉了一整天。从那以后，我要求所有SQL必须显式带上租户ID，并且用数据库视图做一层强制过滤。
2.3 隔离策略：数据、性能、安全三管齐下
多租户不只是「数据不串」那么简单。真正的隔离策略要覆盖三个维度：
数据隔离
- 读写分离：每个租户的读写操作限定在自己的数据范围内
- 缓存隔离：Redis里用租户ID做key前缀，避免缓存污染
- 文件隔离：设备上传的固件、配置文件按租户分目录存储
性能隔离
- 资源配额：限制每个租户的设备数量、API调用频率、消息吞吐量
- 线程池隔离：高负载租户不能拖垮其他租户
- 限流降级：某个租户突发流量时，自动限流，保护平台整体稳定
安全隔离
- 认证隔离：每个租户有独立的OAuth2配置、LDAP绑定
- 权限隔离：租户管理员只能管理本租户的用户和角色
- 审计隔离：操作日志按租户分开存储，方便追溯
我的经验：性能隔离往往被忽视。很多团队只关注数据隔离，结果某个大租户的批量设备上报把整个平台搞挂了。我建议在架构设计阶段就把资源配额加进去，哪怕初期设得宽松一点，也比后面补强。
2.4 ThingsBoard中的租户层级：从系统到设备
好了，咱们落地到ThingsBoard。它的租户层级设计得非常清晰，一共四层：
系统管理员 (System Admin)
└── 租户 (Tenant)
└── 客户 (Customer)
└── 设备 (Device)第一层：系统管理员
这是平台的超级管理员。负责创建租户、配置全局参数、查看系统健康状态。说白了，就是管「写字楼」的物业公司。系统管理员不直接操作设备，也不属于任何租户。
第二层：租户
租户是ThingsBoard的核心实体。每个租户拥有自己的设备、仪表板、规则链、告警配置。租户管理员可以创建客户、分配设备、设置权限。嗯，你可以把租户理解成一个「子公司」。
第三层：客户
客户是租户下的子组织。比如一个智慧园区项目，租户是园区运营方，客户可以是各个入驻企业。客户只能看到自己被授权的设备和仪表板。这个层级设计非常灵活，适合做渠道分销场景。
第四层：设备
设备是最底层的实体。每个设备必须属于某个客户（或者直接属于租户）。设备的数据、属性、遥测都严格限定在所属租户和客户范围内。
关键点：ThingsBoard的权限控制是「向下继承」的。租户管理员能看到所有客户和设备，客户管理员只能看到自己的设备。系统管理员能看到所有租户的概况，但不能操作具体设备。这个设计很巧妙，既保证了管理效率，又防止了越权。
我建议你在做多租户设计时，先画一张层级图。把系统管理员、租户、客户、设备的关系理清楚。很多权限问题，其实在层级图上就能看出来。
举个例子：如果你想让某个用户只能查看温度超过50度的设备告警，那这个权限应该配在客户层级还是设备层级？嗯，答案是客户层级。因为设备层级只负责数据采集，不负责权限判断。
好了，这一章的内容就到这里。多租户架构是ThingsBoard的基石，理解透了，后面的权限管理、规则链设计、仪表板共享都会轻松很多。下一章咱们聊具体的租户创建和配置流程，到时候我会手把手带你操作一遍。