多租户架构模式：共享数据库、独立数据库与微服务
说到多租户系统，第一个要拍板的问题就是：数据库怎么分？
我见过不少团队，一上来就扎进业务逻辑里，结果后面租户隔离没做好，审计日志对不上，回滚都找不到地方。说实话，架构模式决定了你整个系统的隔离边界。
这章我们不走教科书路线。我就把三种主流模式——共享数据库、独立数据库、微服务——掰开揉碎，结合我踩过的坑，给你一套能直接落地的判断框架。
模式一：共享数据库，共享Schema
最粗暴也最常用的模式。
所有租户的数据混在同一张表里，靠一个 tenant_id 列来区分。存储成本最低，运维最简单，但隔离性最弱。
核心特征
- 所有租户共用同一套表结构
- 每个查询都必须带上
WHERE tenant_id = ? - 数据库连接数固定，资源利用率高
个人经验： 我在一家SaaS公司做过一个CRM系统，最初就是共享Schema。上线半年，一个租户的SQL写漏了tenant_id条件，直接把另一个租户的客户数据查了出来。那是我第一次被半夜叫起来处理数据泄露——虽然最后没出事，但从此我绝不在金融、医疗这类场景用共享模式。
适合的场景： 租户数量巨大（上万级别）、每个租户数据量极小、对隔离性要求不高的内部工具或免费套餐。
避坑提示： 即使选择了共享模式，也一定要在ORM层强制绑定tenant_id。用@TenantFilter注解+拦截器，比靠开发人员的自觉靠谱得多。我曾经接手过一个项目，一半的查询没加租户过滤——那代码改得叫一个酸爽。
模式二：独立数据库，每个租户一个库
每个租户拥有自己的数据库实例或Schema。隔离性最强，数据恢复、备份、迁移都可以针对单个租户做。代价？成本线性增长。
| 对比维度 | 共享数据库 | 独立数据库 |
|---|---|---|
| 存储成本 | 极低 | 高（每个租户一堆元数据表） |
| 隔离性 | 弱（依赖代码） | 强（物理隔离） |
| 运维复杂度 | 低 | 高（连接数、备份策略） |
| 审计日志清晰度 | 需额外标记租户 | 天然按库分隔，日志天然隔离 |
| 典型租户规模 | 数万+ | 几百~几千 |
我踩过的一个坑： 以前给一个银行做监管系统，客户要求“隔离”。我们用了独立数据库，每个租户一个MySQL实例。结果租户数从50涨到800，DBA每天凌晨都在迁移数据——连接数撑爆了。后来我们加了连接池中间件，再按租户热度做动态路由，才稳住。所以独立数据库不是一劳永逸，你得提前设计连接管理和资源池。
模式三：微服务架构下的多租户
现在大部分新系统都往微服务走。但微服务 + 多租户，组合方式比单服务复杂至少一个量级。
常见做法有几种：
- 租户路由层：在网关或服务网格里根据请求头中的
X-Tenant-ID把请求分发到对应的租户服务实例 - 共享服务 + 独立数据：服务代码共用，但每个租户的数据存在不同的数据库（混合模式）
- 完全独立部署：每个租户拥有整套微服务栈（极少数场景）
⚠️ 微服务模式最容易被忽略的问题： 审计日志的跨服务追踪。一次用户操作可能涉及3~4个微服务，如果每个服务只记自己的日志，合并时根本拼不回完整的操作链路。我建议从一开始就引入全局Trace ID，每个请求生成一个唯一ID，所有服务都记录它，这样审计日志才能串联。
我的建议： 如果团队刚起步，别一上来就搞微服务多租户。先单服务共享数据库跑通业务，等租户量上来、数据隔离需求明确之后，再用绞杀者模式逐步把敏感模块拆成独立数据服务。我见过一个项目，三个月就上微服务，结果半年后因为租户路由bug丢了一批订单数据——那叫一个惨。
选型决策框架
我做了这些年，总结出一个简单的判断逻辑。下面这张图帮你快速定位：
审计日志视角的特殊考量
不管你选哪种模式，审计日志都必须记录租户上下文。共享模式最麻烦——日志表里必须有 tenant_id 索引，否则查询全量日志慢到怀疑人生。独立数据库模式天然按库分表，但跨租户的全局审计（比如监管要求“所有租户的删除操作”），你得做汇总查询或者建一个中央日志视图。
微服务模式更要注意：每个服务都有自己的一摊日志，格式不统一的话，后期审计就是一场灾难。我建议用结构化日志 + 统一Schema，所有服务输出JSON格式，至少包含 tenant_id、user_id、action、timestamp、trace_id 五个字段。这样不管后端用Elasticsearch还是ClickHouse，都能直接做关联分析。
经验之谈： 我在设计一个证券交易系统时，客户要求“任意租户的操作，5分钟内必须能在审计日志里搜到”，而且要保持3年以上。我们用了独立数据库 + 每天归档到HDFS，但为了满足5分钟查询，又给每个库配了只读副本。成本高，但审计合规是刚需，省不了。
小结
没有银弹。共享数据库省钱但风险高，独立数据库保安全但烧钱，微服务模式灵活但复杂度暴增。你真正要做的是：看清楚自己的业务场景和合规要求。如果还在犹豫，可以从共享模式起步，预留 tenant_id 字段，隔离需求上来后再往独立库或微服务迁移。记住，架构选型不是一锤子买卖，好的系统都应该能随着租户规模演进。
下个话题之前，先把这页的决策思路消化掉。你自己动手画一张模式对比表，比看十遍文章都管用。