企业官网建设流程全解析

在架构师考试中，“SaaS（Software as a Service）多租户架构”是云计算领域的高频考点。

题目通常会给你设定一个场景：

“某公司开发了一套企业级 CRM 系统，准备以 SaaS 模式卖给 1000 家中小企业使用。这就面临一个核心问题：不同企业（租户）的数据该怎么存？”

是给每家企业单独建一个数据库？还是大家挤在同一张表里？

如果选错了，要么公司破产（成本撑不住），要么公司倒闭（数据泄露被起诉）。

今天咱们就来拆解 SaaS 架构中最关键的决策点——数据隔离策略。

一、 策略一：独立数据库（Database per Tenant）—— 也就是“独栋别墅”

方案描述： 来一个客户（租户），我就在 MySQL 里CREATE DATABASE tenant_001。1000 个客户就有 1000 个数据库。

架构师评价：

• 优点（隔离性 Max） ： 安全 ：数据物理隔离，绝对不会出现“A公司看到了B公司的订单”这种重大事故。 灵活 ：大客户如果要定制化（比如加个字段），可以直接改他的库，不影响别人。 备份恢复快 ：某客户误删数据，直接回滚他的库就行。

• 缺点（成本 Max） ： 贵 ：数据库实例是要钱的，连接池资源是有限的。几千个库在这个实例上跑，性能开销巨大。 运维难 ：你要升级表结构，得写脚本遍历 1000 个库去执行 ALTER TABLE。

适用场景：

• 银行、医疗、政务 等对数据安全和合规性要求极高的 土豪客户 。

二、 策略二：共享库，独立Schema（Shared Database, Separate Schema）—— 也就是“联排公寓”

方案描述： 所有客户共用一个物理数据库实例，但每个客户有自己独立的 Schema（在 Oracle 里是 User，在 MySQL 里也是 Database 概念，但共享进程）。

架构师评价：

• 优点 ：比独立数据库稍微省点资源，逻辑上还是隔离的。

• 缺点 ：跨库关联查询依然很难，且一旦数据库挂了，所有人都挂了。

适用场景：

• 中等规模客户，愿意出点钱买个“安心”。

三、 策略三：共享库，共享表（Shared Database, Shared Schema）—— 也就是“集体宿舍”

方案描述： 所有人都在同一个数据库、同一张表里。 表结构里加一个核心字段：tenant_id（租户ID）。

• 查询时：SELECT * FROM orders WHERE tenant_id = 1001。

• 插入时：INSERT INTO orders (tenant_id, ...) VALUES (1001, ...)。

架构师评价：

• 优点（成本 Min） ： 极度便宜 ：无论来多少客户，数据库永远只有那一套。开发维护（改表结构）非常简单。

• 缺点（安全 Min） ： 代码写错就完蛋 ：如果程序员在写 SQL 时忘加 WHERE tenant_id = ?，全库数据就泄露了（这叫 数据串扰 ）。 吵闹的邻居 ：一个大客户发起了一次慢查询，拖垮了整个数据库，所有小客户都得跟着卡顿。

适用场景：

• 面向中小微企业（SMB） 的标准化 SaaS，如钉钉、飞书的普通版。

四、 架构师选型决策（案例必背）

在考试中，如果题目没有明确指定“不差钱”，或者明确说是“面向海量中小用户”，默认首选策略三（共享表）。

但在设计时，必须补充两点安全措施（得分点）：

1. 架构层面的防泄露 ： 千万别让业务开发手动写 SQL 拼接 tenant_id。 利用 MyBatis 拦截器 / Hibernate Filter ：在底层框架里强制拦截所有 SQL，自动注入 tenant_id 条件。从根源上杜绝人为疏忽。

2. 分级服务（Tiered Service） ： 对于普通/免费用户，用策略三（共享表）。 对于 VIP/私有化部署用户，额外收费，提供策略一（独立库）。 这就是传说中的 “混合模式” 。

小结

SaaS 架构的本质就是“批发”。

1. 想省钱、做规模 -> 选共享表（TenantId）。

2. 想合规、做大客 -> 选独立库。

3. 既要又要 -> 搞混合模式。