客户数据的隔离边界

发布时间:2026-06-27 12:09

## 概念是什么 一套系统服务多个客户时，隔离边界回答的问题是：客户的数据放在哪里，用什么机制保证 A 客户碰不到 B 客户的数据。边界可以画在实例级、库级、表级或行级，越往左隔离越强、成本越高，越往右资源利用越优、实现越考验功夫。选错边界的代价在多年后才显现：先是效率，然后是事故。 ## 背后的原理 实例级隔离，每个客户独立数据库实例与服务器，物理上最干净，故障与性能互相不影响，成本随客户数线性增长。库级与模式级隔离，多客户共享实例但各用独立库，权限体系天然分隔，是性价比常见的选择。行级隔离，所有客户的数据混在同一组表里靠租户字段区分，存储与查询最经济，但每一句查询都必须带上租户条件，任何一条遗漏就是数据越界，等于把安全押在代码纪律上。边界一旦上线就很难迁移，行级用深了想拆库，工程量以年计。 ## 最小实操 选择边界时用三个问题过滤：单客户的合规与定制要求有多强，要求的强度决定下限；客户数量与增长曲线，数量级决定成本的斜率；团队的工程纪律与测试覆盖，纪律不足就别选行级。确定边界后，让权限与应用双重对齐：数据库账号权限范围与隔离边界一致，应用层再校验一次租户归属，两层各挡各的。顺云的云服务器与裸金属可以承载不同层级的部署形态，合规要求最强的实例级独占场景，裸金属是自然的选择。 ## 常见错误 常见错误：只有应用层过滤，数据库账号却是全库权限，一次注入就击穿全部客户；运维通道不受边界约束，调试脚本随手查全库；客户合同结束后数据不迁出，混居的表里残留已到期数据。隔离边界是架构决定，补丁补不出来，设计期值得多花一周。