多租户物联网平台的设计权衡：隔离到什么程度才够

把单租户的物联网平台改造成 SaaS，表面上是「加个 tenant_id 字段」的事，真正动工才发现每一层都在问同一个问题：隔离到什么程度才够？

数据隔离的三档方案

方案	隔离性	成本	适用
共享表 + tenant_id	弱	最低	中小客户、标准化功能
独立 Schema	中	中	有定制需求的客户
独立数据库	强	最高	大客户、合规敏感行业

物联网场景的特殊性在于数据是两层的：业务数据（设备档案、告警、用户）量小但结构复杂；时序数据（遥测）量大但结构简单。不必一刀切——常见的务实做法是业务库共享表 + 时序库按租户打 tag，查询层统一注入租户过滤条件。

共享表方案的隐藏成本

选择了最便宜的共享表，代价会在这些地方找上门：

• 越权防线在代码里：每一条 SQL、每一个缓存 key、每一次消息订阅都必须带租户上下文，任何一处遗漏就是水平越权漏洞。建议用 ORM 拦截器/插件统一注入，而不是依赖开发自觉；
• 噪声邻居：某个租户的几万台设备集中上报，共享资源（连接池、线程池、写入带宽）被挤占，其他租户跟着抖。需要租户级限流配额；
• 备份与删除：单租户数据导出、注销删除都要从共享表里「抠」数据，GDPR 类合规场景下工作量不可小觑。

连接层的租户感知

MQTT 接入层同样绕不开：设备认证时要解析出所属租户，Topic 权限按租户隔离——A 租户的设备绝不能订阅到 B 租户的 Topic。Broker 的 ACL 规则最好用通配符 + 租户前缀一次配置，而不是为每台设备写规则。

我的取舍建议

1. 起步期：共享表 + 严格的租户上下文注入，把「隔离正确性」做成自动化测试用例；
2. 大客户来了：为其单独部署实例（独立库 + 独立 Broker 集群），配置即隔离；
3. 时序数据从第一天起就按租户打标签，迁移成本最低。

多租户设计的本质不是技术选型，而是在商业定价和技术复杂度之间找平衡：隔离越强，单客户成本越高；把隔离做成可选档位，让它成为价格体系的一部分。