架构风格与模式58 条

多租户架构模型

多租户按隔离程度分档:共享数据库共享 schema、共享数据库独立 schema、独立数据库(甚至独立实例);隔离越强成本越高,需结合合规与噪声邻居评估。

多租户是什么

多租户指一套系统同时服务多个客户(租户),数据与配置按租户隔离。核心决策是隔离档位:共享数据库共享 schema、共享数据库独立 schema、独立数据库、独立实例,隔离越强,单位成本与运维复杂度越高。

档位怎么选

判断依据是合规要求、客户规模与噪声邻居风险。中小客户、成本敏感的早期产品通常从共享 schema 起步;有数据驻留或审计要求的大客户需要独立库,甚至独立实例。迁移路径要提前规划,否则从共享 schema 迁到独立库时才发现表上没有可靠的租户标识,历史数据无法拆分。

四种模型

模型隔离度成本与运维适用
共享库共享 schema低成本低,需防串租与噪声邻居中小客户、成本敏感
共享库独立 schema中迁移与备份可按租户处理中等隔离要求
独立数据库高成本高,可独立扩容与恢复大客户、合规要求
独立实例或环境很高近乎单租户部署强合规与专属部署

基本信息

租户标识所有业务表带租户字段,并在数据访问层强制注入
配置隔离按租户覆盖主题、字段、流程与限额
资源控制限流、配额与任务调度按租户维度分别统计
计费口径按租户统计存储、请求量与计算资源占用

典型使用场景

  • SaaS 初期:共享 schema 快速上线,压低单租户成本
  • 大客户接入:单独建库满足审计与数据隔离要求
  • 私有化交付:独立实例部署,与标准版本保持同源代码
  • 成本核算:按租户统计资源占用,支撑分级定价
  • 分批升级:先在小租户验证新版本,再逐步放量
无论哪种模型,都要在数据访问层强制租户标识校验,并专门测试跨租户越权场景;只在查询里手工拼接租户条件,迟早会漏掉一处。

易错点

  • 查询遗漏租户条件导致跨租户数据越权,是最严重的数据事故类型之一
  • 单个租户的批量任务占满共享资源,影响其他租户,形成噪声邻居问题
  • 共享 schema 下没有为租户字段建索引,带租户条件的查询退化为全表扫描
  • 定制需求直接改在主干代码里,缺少按租户开关,功能互相干扰

数据来源与参考

  • Microsoft Azure 多租户 SaaS 架构指南
  • AWS Well-Architected SaaS Lens
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌