架构设计原则：隔离性、可扩展性、安全性、成本效益、租户感知设计
好，咱们直接进入正题。多租户架构的核心，说白了就是「怎么让一群用户住在一栋楼里，还互不打扰」。这栋楼的设计，决定了你未来是省心还是天天救火。我个人习惯把这五个原则当成「五根柱子」——少一根，楼都可能塌。
1. 隔离性：租户之间的「防火墙」
隔离性是我最看重的原则。没有隔离，多租户就是个笑话。
数据隔离的三种模式，我简单列个表，你一看就明白：
| 模式 | 做法 | 隔离强度 | 成本 |
|---|---|---|---|
| 独立数据库 | 每个租户一个库 | 最高 | 最高 |
| 共享数据库、独立Schema | 同一个库，不同表前缀或Schema | 中 | 中 |
| 共享数据库、共享表 | 所有数据在一张表，用tenant_id区分 | 低 | 最低 |
我在项目中遇到过一家SaaS公司，初期为了省钱选了「共享表」模式。结果有个大租户跑了个全表扫描的报表，直接把其他租户的查询拖死了。嗯，这就是典型的「省了小钱，赔了大钱」。
我的建议： 金融、医疗类业务，直接上独立数据库。普通SaaS应用，用独立Schema就够。千万别为了省几台服务器，把命根子搭进去。
2. 可扩展性：别让架构成为瓶颈
可扩展性，说白了就是「业务涨10倍，系统能不能扛住」。你想想看，如果架构设计时没考虑扩展，等用户量上来再重构，那成本可就不是翻倍那么简单了。
水平扩展 vs 垂直扩展，我一般这样选：
- 垂直扩展：加CPU、加内存。简单粗暴，但有上限。一台机器再强，也扛不住所有租户。
- 水平扩展：加机器。这才是正道。但前提是——你的应用层必须无状态。
我记得有一次帮客户做压测，发现数据库CPU飙到100%。查了半天，原来是某个租户的定时任务把整个库锁住了。后来我们做了「租户级连接池隔离」，每个租户最多用20个连接，问题就解决了。
3. 安全性：租户数据的「保险柜」
安全性这个话题，我每次讲课时都会多说两句。为什么？因为多租户系统里，一个漏洞可能让所有租户的数据裸奔。
三个必须做好的安全措施：
- 租户上下文传递：每个请求都必须携带租户ID，并且在服务间传递时不能丢失。我习惯用ThreadLocal或者请求头来传递。
- 数据访问拦截：所有SQL查询，必须自动拼接 tenant_id 条件。别指望程序员手动写，一定会漏。
- API鉴权：每个接口都要校验当前用户是否有权访问该租户的数据。
我曾经见过一个案例：开发人员写了个导出功能，忘了加租户过滤。结果A租户的管理员，导出了B租户的全部客户数据。嗯，这种事故一旦发生，基本就是公关灾难。
4. 成本效益：花最少的钱，办最多的事
成本效益，说白了就是「老板给你100万，你要做出500万的效果」。多租户架构里，成本控制主要体现在资源复用上。
我常用的成本优化策略：
- 按需分配资源：小租户给最低配置，大租户给专属资源。别搞一刀切。
- 冷热数据分离：活跃租户放高性能存储，不活跃的放廉价存储。我见过一个项目，把3个月前的数据归档到对象存储，成本直接降了60%。
- 共享基础设施：比如Redis、消息队列这些中间件，尽量让多个租户共用，但要做好限流和隔离。
你想想看，如果每个租户都独立部署一套Redis，那成本得多高？但如果不做隔离，一个租户的突发流量可能把Redis打爆，影响所有人。所以这里有个平衡点——我个人习惯用「租户级限流+共享实例」的方案。
5. 租户感知设计：让系统「认识」每个租户
租户感知，是前面四个原则的「粘合剂」。没有它，隔离、扩展、安全、成本都无从谈起。
什么是租户感知？ 就是系统里的每个组件，都知道自己正在为哪个租户服务。从网关到应用层，从缓存到数据库，租户ID必须贯穿始终。
我一般这样设计租户感知的架构：
// 伪代码示例：租户上下文传递
public class TenantContext {
private static ThreadLocal<String> currentTenant = new ThreadLocal<>();
public static void setTenantId(String tenantId) {
currentTenant.set(tenantId);
}
public static String getTenantId() {
return currentTenant.get();
}
public static void clear() {
currentTenant.remove();
}
}
// 在拦截器中自动注入
public class TenantInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
String tenantId = request.getHeader("X-Tenant-Id");
TenantContext.setTenantId(tenantId);
return true;
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
TenantContext.clear(); // 别忘了清理，否则内存泄漏
}
}
最后说一句：这五个原则不是孤立的。隔离性做得好，安全性自然就强；可扩展性考虑周全，成本效益才能最大化。而租户感知，就是把这些原则串起来的那根线。
嗯，下一章咱们聊聊具体的「数据隔离方案选型」，到时候我会拿几个真实案例来拆解。你先把这五个原则消化一下，有问题随时问。