多租户物联网平台怎么设计？数据隔离、权限模型和计费三条主线

如果你要做一个卖给多个客户的物联网平台（SaaS 模式），或者集团要给多个分公司用，就会碰到多租户问题。

最常见的错误设计是「所有表加一个 tenant_id 字段，查询时带上条件」。这个方案在租户少、数据少的时候能跑，租户多了、数据大了就会崩。

这一篇讲三条主线的正确设计。

主线一：数据隔离的三种方案

方案 A：独立数据库

每个租户一个独立数据库。

• 隔离强度：最高（物理隔离）
• 成本：高（数据库实例多，运维复杂）
• 扩展性：租户数量受限于数据库实例数
• 适用：租户少（< 50）、每个租户数据量大、有强隔离要求（如政务、金融）

优点：一个租户出问题不影响其他；备份恢复独立；数据可以单独迁出。

缺点：运维成本高（50 个租户要管 50 个库）；跨租户统计困难。

方案 B：共享库独立 Schema

一个数据库实例，每个租户一个 schema。

• 隔离强度：较高（逻辑隔离，权限层面分开）
• 成本：中
• 扩展性：较好（单库能撑几十到几百个 schema）
• 适用：租户中等（50-500）、数据量中等

这是 PostgreSQL 的强项。MySQL 的 schema 和 database 概念混同，实现起来麻烦一些。

方案 C：共享库共享表

所有租户一张表，加 tenant_id 字段。

• 隔离强度：低（靠应用层保证，一旦漏了条件就串数据）
• 成本：最低
• 扩展性：最好（租户数不受限）
• 适用：租户多（> 500）、单租户数据量小

优点：运维简单、成本低、跨租户统计容易。

缺点：隔离靠代码保证，风险高；单租户数据量大时性能下降；大租户会影响小租户。

必须做的防护：

• 所有查询强制带 tenant_id（用 ORM 的全局作用域或数据库行级安全策略）
• 数据库层面启用 RLS（Row Level Security）作为第二道防线
• 写入时强制注入 tenant_id（不允许应用层指定）
• 定期做「跨租户数据泄露」测试

怎么选

混合方案最实用：

• 小租户（数据量小）：共享表
• 大租户（数据量大或有强隔离要求）：独立库
• 平台统一管理租户的「存储位置」，对上层透明

这样既控制了成本，又能满足大客户的隔离要求。

主线二：权限模型

四级结构

• 平台方（超级管理员）：管理所有租户、平台配置、系统监控
• 租户管理员：管理本租户的用户、设备、权限、配置
• 子账号：租户内的普通用户（按角色分权限）
• 设备端：设备接入凭证（只能上报数据、接收指令）

权限的维度

权限不是简单的「角色」，是多维度的：

• 功能权限：能访问哪些菜单/接口（RBAC）
• 数据权限：能看哪些设备/区域的数据（按组织架构或设备分组）
• 操作权限：能做什么操作（查看/编辑/控制/删除）
• 时间权限：什么时间段能操作（如只允许工作时间远程控制）

最常见的错误是只做了「功能权限」，没做「数据权限」。结果是一个物业公司的多个项目，A 项目的管理员能看到 B 项目的数据。

数据权限的实现

常用模型：

• 按组织树：用户属于某个组织节点，能看到该节点及下级的数据
• 按设备分组：设备分到不同分组，用户授权到分组
• 按标签：设备打标签（如「区域=华东」「类型=水表」），用户按标签授权

建议：组织树 + 设备分组双维度，能满足大部分场景。

设备接入的权限

• 每个设备有唯一的产品密钥 + 设备密钥
• 设备只能上报自己的数据（不能冒充其他设备）
• 设备只能订阅自己的指令 Topic
• 密钥支持轮换

这一层经常被忽略。如果设备密钥管理不严，一个设备被破解就可能伪造大量数据。

主线三：计费模式

模式一：按设备数

• 定价：X 元/设备/年（或/月）
• 优点：客户容易理解、可预测
• 缺点：客户会倾向于少报设备（或频繁上下线规避）

实现要点：设备「激活」才计费（首次上线时间），设备删除后停止计费。要有「设备数快照」（每月 1 日统计），避免客户在月底删设备。

模式二：按消息数

• 定价：X 元/百万条消息
• 优点：与实际用量挂钩，公平
• 缺点：客户难预测成本（尤其是采集频率高的场景）

实现要点：消息计数要精确（不能重复计、不能漏计），要提供实时用量查询，要设「用量预警」（80%、100%）。

模式三：按功能模块

• 定价：基础版免费/低价，高级功能（AI 分析、可视化大屏、报表）单独收费
• 优点：客户按需付费，容易升级
• 缺点：功能边界要清晰，否则客户会觉得「什么都要加钱」

实践中最常见的是「组合模式」：基础套餐（含 N 个设备 + M 条消息）+ 超量按量计费 + 高级模块单独收费。

计费的实现要点

• 用量数据要准（有审计，能对账）
• 支持套餐和按量混合
• 支持预付费和后付费
• 欠费处理（预警、限流、停机，要有梯度，不能直接停）
• 账单可导出、可追溯

「欠费直接停机」是最容易引发客户投诉的做法。建议梯度：欠费 7 天预警 → 15 天限流（降采集频率）→ 30 天停机（但保留数据 90 天）。

三个设计陷阱

陷阱一：跨租户查询性能

共享表方案下，平台方要做「全平台统计」（如总设备数、总消息量），这个查询会扫全表。

解决：

• 建汇总表（按天/按租户预聚合）
• 用物化视图
• 把统计功能拆到独立的分析库（OLAP）

陷阱二：租户级配置隔离

不同租户可能需要不同的配置：告警规则、数据保留期、界面 Logo、地图服务商、短信签名。

设计要点：

• 配置分三级：平台默认 → 租户配置 → 用户配置，逐级覆盖
• 配置变更要有版本和回滚
• 敏感配置（如短信密钥）要加密存储

陷阱三：租户数据导出与迁移

客户要离开时，能不能把数据完整带走？

必须在设计时就考虑：

• 提供「全量数据导出」功能（标准格式，不只是 CSV，要含关联关系）
• 导出要能恢复到另一个租户（用于迁移测试）
• 导出操作要有权限控制和审计

很多平台上线两年后才发现「数据导不出来」，这时候改造成本极高。

平台的成本构成可以看 物联网云平台价格对比，数据归属的合同约定看 数据归谁。

最后一句

多租户设计的关键决策点只有一个：租户规模预期。如果预期 100 个租户以内、且有大客户，用「独立库 + 共享库混合」；如果预期上千个租户、都是小客户，用「共享表 + 行级安全」。选错了后期改造成本极高，所以在写第一行代码前就要定下来。

正在设计或改造多租户物联网平台，说一下预期租户规模、单租户设备量和隔离要求，可以帮你定一版架构方案。平台架构可以看 物联网架构怎么设计，服务器配置看 物联网平台服务器怎么配。