SaaS 平台中，一个大客户的导入或报表可能影响其他客户。按租户拆服务、拆数据库或拆部署都有成本。选型前应先确认隔离需求来自性能、权限、恢复还是合同要求。
把隔离要求拆成具体问题
客户是否需要独立恢复数据？是否要求专属容量？故障是否必须限制在单个租户？不同答案对应不同方案。仅在所有表增加 tenant_id，解决不了全部隔离需求；独立部署也不会自动修复权限过滤漏洞。
检查租户上下文的传播
入口、后台任务、消息和导出流程都应明确租户来源。不要完全依赖客户端传来的租户标识，还要结合身份和业务权限判断。共享缓存的键与后台查询也需要遵守同样的边界。
先处理可识别的资源争用
对批量任务设置租户级配额、排队和并发限制，观察是否足够缓解问题。确需专属资源的客户可以进入独立方案，但要同时维护迁移、升级和监控流程，避免每个租户演变成不可维护的定制系统。
验收跨租户异常场景
覆盖标识伪造、缓存混用、消息错投与大任务争用，核实访问范围和性能影响。恢复演练也要验证能否只恢复目标租户的数据而不覆盖其他租户。
常见问题：租户越多就越应该独立数据库吗？
不能只看数量。应结合数据规模、隔离要求、恢复目标和维护成本进行分层设计。
技术参考：微软：资源隔离模式。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。