【实战】SAAS多租户详细设计
SAAS多租户详细设计文档
请关注公众号【碳硅化合物AI】
摘要
本文档阐述SAAS多租户架构设计，解决一套系统服务多个客户时的成本、数据隔离、配置个性化、扩展性和运维复杂度问题。采用逻辑租户隔离方案，通过tenant_id字段实现数据隔离，结合RBAC权限体系、元数据驱动和OAuth2+JWT认证，确保租户数据安全隔离并支持个性化配置。相比按库隔离，该方案在成本、运维效率和扩展性之间取得平衡，适合租户数量多、数据量中等的场景。
一、SAAS化多租户解决什么问题
SAAS多租户要解决的核心问题是：一套系统服务多个客户，每个客户的数据和配置要完全隔离，互不干扰。
具体来说，主要解决这几个问题：
1. 成本问题
传统方式每个客户一套系统，服务器、数据库、运维成本都是 N 倍。多租户模式下，一套系统服务所有客户，成本大幅降低。比如原来 100 个客户需要 100 套系统，现在一套系统就够了。
2. 数据隔离问题
多个客户用同一套系统，最怕的就是数据串了。A 客户能看到 B 客户的数据，这是灾难性的。多租户必须保证数据完全隔离，A 客户只能看到自己的数据。
3. 配置个性化问题
不同客户对功能、界面、流程的需求不一样。有的客户需要自定义菜单名称，有的需要调整按钮顺序，有的需要禁用某些功能。多租户要支持这种个性化配置。
4. 扩展性问题
客户数量会增长，系统要能平滑扩展。不能因为客户多了就卡顿，也不能因为某个客户数据量大就影响其他客户。
5. 运维复杂度问题
传统方式每个客户一套系统，升级、打补丁、监控都要做 N 遍。多租户模式下，一次升级所有客户都受益，运维效率大幅提升。
二、如何实现，关键点有哪些
1. 数据隔离机制
所有业务表都加tenant_id字段，这是数据隔离的基础。查询时自动带上tenant_id条件，写入时自动设置tenant_id，确保数据不会串。
2. 租户上下文管理
系统要能识别当前请求是哪个租户的。通过中间件从 JWT Token 或请求头中提取tenant_id，放到线程上下文里，后续所有操作都基于这个上下文。
3. 权限体系（RBAC）
用户-角色-权限三层模型。用户关联角色，角色关联权限，权限关联资源（菜单/按钮/API）。这样权限管理灵活，可以按角色批量授权。
4. 元数据驱动
资源（菜单、按钮、API）基于元数据定义。元数据是模板，租户资源是实例。这样既能统一管理，又能支持个性化配置。
5. 认证与授权
采用 OAuth2 + JWT 方案。全局认证用户（auth_user）作为认证主体，租户用户（tenant_user）通过auth_user_id关联，实现一人多租。JWT Token 里包含tenant_id和权限信息，资源服务验证 Token 后直接使用，无需再查数据库。
6. 架构分层
采用 DDD 四层架构：接口层（Controller）、应用层（Service）、领域层（Domain）、基础设施层（Repository）。职责清晰，易于维护。
三、数据存储方式
多租户的数据存储主要有两种方式：按库隔离和逻辑租户隔离。我们采用逻辑租户隔离。
按库隔离（Database per Tenant）
每个租户一个数据库，完全物理隔离。
优点：
- 数据完全隔离，安全性最高
- 可以按租户独立备份、恢复
- 某个租户数据量大不影响其他租户
- 可以按租户独立扩展（分库）
缺点：
- 数据库数量多，运维复杂
- 升级、打补丁要操作 N 个库
- 跨租户统计、分析困难
- 成本高（连接池、资源占用）
适用场景：租户数量少（< 100），数据量大，对隔离要求极高。
逻辑租户隔离（Shared Database, Shared Schema）
所有租户共用一个数据库，通过tenant_id字段区分。
优点：
- 运维简单，一次升级所有租户受益
- 成本低，资源利用率高
- 跨租户统计、分析方便
- 扩展性好，可以水平分片
缺点：
- 需要严格保证
tenant_id过滤，否则会数据泄露 - 某个租户数据量大可能影响其他租户（需要分片）
- 备份恢复需要按租户过滤
适用场景：租户数量多（> 100），数据量中等，对成本敏感。
我们的选择：逻辑租户隔离
我们采用逻辑租户隔离，原因如下：
- 租户数量多：预期会有大量租户，按库隔离不现实
- 成本考虑：一套数据库服务所有租户，成本可控
- 运维效率：一次升级、一次监控，效率高
- 技术保障：通过中间件、拦截器、切面等技术手段，严格保证
tenant_id过滤
数据隔离实现
关键实现点：
- 查询拦截器：MyBatis 拦截器拦截所有 SQL，自动添加
WHERE tenant_id = ?条件 - 写入切面：AOP 切面拦截所有写入操作，自动设置
tenant_id字段 - 上下文管理：ThreadLocal 存储当前租户 ID，请求结束时清理
- 权限校验：接口层校验，确保不能跨租户访问
混合方案（可选）
如果未来某个租户数据量特别大，可以采用混合方案：
- 小租户：逻辑隔离（共享库）
- 大租户：按库隔离（独立库）
通过配置表记录每个租户的存储方式，动态路由到对应的数据源。
总结
SAAS多租户的核心是数据隔离和配置个性化。我们通过tenant_id字段实现逻辑隔离，通过元数据驱动支持个性化配置，通过 RBAC 体系管理权限，通过 OAuth2 + JWT 实现认证授权。
这种方案在成本、运维、扩展性之间取得了平衡，适合租户数量多、数据量中等的场景。关键是要严格保证tenant_id的过滤和设置，不能有遗漏，否则就是严重的安全问题。