SaaS架构设计实战：多租户隔离、计费与迁移避坑指南

简介这份《SaaS架构设计》PDF文档面向希望系统掌握SaaS架构原理与实践的开发者、架构师及技术学习者围绕多租户系统从需求分析到性能优化的完整设计链路展开。内容涵盖SaaS成熟度模型四级分级、RUP“41”视图模式场景、逻辑、开发、过程、物理视图、MDA模型驱动架构以及系统级与程序级安全性设计、独立数据库与共享数据库等三种多租户数据存储方案并延伸至数据库索引优化、应用层缓存、日志记录与数据加密等性能与安全实践最后给出速率、并发数、吞吐量、响应时间等云计算网络性能测试指标。资源包为1个PDF文件大小约967KB结构紧凑、便于随时查阅。目前已有197人学习适合作为SaaS架构入门与方案设计的参考笔记。1. 从一份 SaaS 架构设计文档说起多租户到底难在哪很多团队做 SaaS第一版都能跑起来第二版开始崩。崩的地方往往不是功能而是租户隔离、计费口径、数据归属这三件事。你手里如果正拿着一份 SaaS 架构设计文档或者正准备写一份真正要回答的不是“用哪些中间件”而是同一套代码怎么让一千个租户互不干扰还能按套餐差异化限流、按用量出账、按租户导出数据。SaaS 架构设计和传统 To B 项目最大的区别是“共享”与“隔离”要同时成立。共享是为了摊薄成本隔离是为了守住边界。这两者天然矛盾所以架构设计文档里最该写清楚的是隔离级别怎么选、租户上下文怎么透传、计费数据从哪来。这篇笔记按“先立住模型再落到表结构和代码最后讲踩坑”的顺序展开适合正在做 SaaS 从 0 到 1 或从 1 到 10 的后端、架构和运维同学。2. 多租户隔离模型三种方案怎么选别一上来就分库2.1 三种隔离级别的成本与边界对比SaaS 多租户隔离业内常见三种做法共享库共享表加租户字段、共享库独立表、独立库。它们不是谁替代谁而是按租户规模和合规要求分层使用。隔离级别数据存放隔离强度单租户成本适合场景共享表 tenant_id同库同表弱靠代码约束极低中小客户、免费套餐共享库独立表同库不同表中靠表名路由中中腰部客户、需要单独备份独立库每租户一库强物理隔离高大客户、强合规、私有化过渡选型逻辑很直接先看合规再看租户体量分布。如果 90% 租户是中小客户全量独立库会让运维成本失控如果头部客户要求数据物理隔离共享表方案又过不了审计。常见做法是混合默认共享表大客户走独立库用同一套租户路由层屏蔽差异。这里有个容易被忽略的点隔离级别一旦定下迁移成本极高。所以架构设计文档里必须写明“升级路径”——共享表租户如何平滑迁到独立库。我一般会要求路由层从第一天就支持按租户配置数据源哪怕初期所有租户都指向同一个库。2.2 租户上下文透传从网关到 SQL 的完整链路隔离能不能守住取决于租户上下文有没有在每一层都带上。典型链路是网关解析租户标识写入请求头应用层拦截器提取并放入 ThreadLocal 或上下文对象数据访问层从上下文取 tenant_id拼进查询条件或路由到对应数据源。// 租户上下文持有者请求结束时必须清理否则线程复用会串租户 public class TenantContext { private static final ThreadLocalString CURRENT new ThreadLocal(); public static void set(String tenantId) { CURRENT.set(tenantId); } public static String get() { return CURRENT.get(); } // 关键在 finally 中调用避免线程池复用导致租户污染 public static void clear() { CURRENT.remove(); } }逻辑说明ThreadLocal 是透传租户标识最轻的方式但它和线程池是天敌。如果请求结束不清理下一个复用该线程的请求可能读到上一个租户的 ID这就是典型的串租户事故。参数上tenantId 建议用不可猜测的字符串而非自增数字避免被遍历。数据访问层再包一层所有查询强制注入租户条件-- 共享表模式下任何查询都必须带 tenant_id禁止裸查 SELECT id, name, plan_code FROM saas_order WHERE tenant_id #{tenantId} AND status PAID;提示可以在 ORM 层做统一拦截自动追加 tenant_id 条件但一定要留“白名单”给平台级管理查询否则运营后台查不到全量数据。2.3 独立库路由动态数据源的最小实现当部分租户升级到独立库路由层要能按 tenantId 切换数据源。常见做法是用 AbstractRoutingDataSource在 determineCurrentLookupKey 里返回租户对应的数据源 key。public class TenantRoutingDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { // 从上下文取租户映射到数据源标识 String tenantId TenantContext.get(); return DataSourceRegistry.lookup(tenantId); } }逻辑说明DataSourceRegistry 维护 tenantId 到数据源 key 的映射key 对应 Spring 容器里注册的多个 DataSource。参数上要注意连接池数量——每个独立库一个连接池租户多了会耗尽数据库连接所以独立库租户数量要有上限或者用连接池共享方案。3. 套餐与计费用量数据从哪来账单怎么算准3.1 套餐模型设计功能、配额、计费项三张表SaaS 套餐的费用策略落到数据模型上就是三件事这个套餐能用哪些功能、每个功能有多少配额、超出后怎么计费。常见做法是拆成三张表plan套餐、plan_feature功能开关、plan_quota配额与计费规则。CREATE TABLE plan ( id BIGINT PRIMARY KEY, plan_code VARCHAR(64) NOT NULL UNIQUE, plan_name VARCHAR(128) NOT NULL, billing_cycle VARCHAR(16) NOT NULL -- MONTHLY / YEARLY ); CREATE TABLE plan_quota ( id BIGINT PRIMARY KEY, plan_code VARCHAR(64) NOT NULL, metric_key VARCHAR(64) NOT NULL, -- 如 api_calls / storage_gb / seats included BIGINT NOT NULL, -- 套餐内包含量 unit_price DECIMAL(12,4) NOT NULL, -- 超出单价 hard_limit BIGINT -- 硬上限NULL 表示不限 );逻辑说明metric_key 是计费项的抽象所有用量都归一到这个键上。included 是套餐内免费额度unit_price 是超出部分单价hard_limit 用于防止单个租户把系统打爆。参数上unit_price 建议用 DECIMAL 而非 FLOAT避免累计误差。3.2 用量采集埋点、聚合、对账三步走计费准不准取决于用量数据可不可信。我一般分三步采集、聚合、对账。采集层在业务动作发生时写一条用量事件聚合层按小时或天汇总对账层用聚合结果和原始事件做校验。# 用量事件写入要求幂等同一 event_id 重复写入不产生双倍计费 def record_usage(tenant_id, metric_key, amount, event_id): sql INSERT INTO usage_event (tenant_id, metric_key, amount, event_id, created_at) VALUES (%s, %s, %s, %s, NOW()) ON DUPLICATE KEY UPDATE amount amount -- 幂等重复事件不叠加 db.execute(sql, (tenant_id, metric_key, amount, event_id))逻辑说明event_id 是幂等键通常由业务侧生成比如订单号加动作类型。ON DUPLICATE KEY UPDATE 保证重复投递不重复计费。参数上amount 要统一单位比如存储统一用 GB、调用统一用次避免聚合时单位混乱。聚合任务按周期把 usage_event 汇总到 usage_summary账单只读汇总表INSERT INTO usage_summary (tenant_id, metric_key, period, total_amount) SELECT tenant_id, metric_key, DATE_FORMAT(created_at, %Y-%m), SUM(amount) FROM usage_event WHERE created_at #{start} AND created_at #{end} GROUP BY tenant_id, metric_key, DATE_FORMAT(created_at, %Y-%m) ON DUPLICATE KEY UPDATE total_amount VALUES(total_amount);逻辑说明按租户、计费项、账期三个维度汇总。ON DUPLICATE KEY UPDATE 让聚合任务可重跑修正历史数据时不会产生重复行。参数上账期格式要和账单周期对齐月付用年月年付用年份。3.3 账单生成把配额、单价、用量拼成一张账单账单生成是把 usage_summary 和 plan_quota 做匹配计算。核心逻辑是套餐内用量不计费超出部分按单价乘超出量。def calc_bill(tenant_id, period): quotas load_quotas(tenant_id) # 当前套餐配额 usages load_usage_summary(tenant_id, period) items [] for metric, used in usages.items(): quota quotas.get(metric) if not quota: continue over max(0, used - quota.included) amount over * quota.unit_price items.append({ metric: metric, used: used, included: quota.included, over: over, amount: amount }) return items逻辑说明over 用 max(0, ...) 保证套餐内不产生负计费。参数上unit_price 要区分阶梯价时这里要换成阶梯计算函数。账单生成后建议冻结快照后续套餐变更不影响已出账单。4. 避坑与排查多租户 SaaS 最容易翻车的五个地方4.1 现象某租户看到了别的租户数据原因租户上下文没清理线程池复用导致串租户或者某条 SQL 漏了 tenant_id 条件。解决在拦截器的 finally 里强制 clearORM 层统一注入租户条件并对裸 SQL 做代码扫描。血泪经验是这类问题往往在压测时才暴露因为低并发下线程复用不明显。4.2 现象计费金额和客户预期对不上原因用量事件重复投递导致双倍计费或者聚合任务重跑时没做幂等。解决所有用量事件带 event_id 并做唯一约束聚合任务用 ON DUPLICATE KEY UPDATE 保证可重跑。对账环节要保留原始事件账单争议时能回溯。4.3 现象独立库租户越来越多数据库连接被打满原因每个独立库一个连接池租户数量增长后连接数线性上升。解决给独立库租户设上限超出后引导升级到专属实例或者用连接池代理做连接复用。参数上要监控每个数据源的活跃连接数设告警阈值。4.4 现象套餐变更后当月账单算错原因账单生成时读取的是当前套餐而不是账期内的历史套餐。解决套餐变更要记录生效时间账单计算按账期匹配对应版本的套餐快照。常见做法是套餐变更时生成一条 plan_snapshot 记录账单只读快照。4.5 现象大租户导出数据时拖垮整个库原因共享表模式下大租户的全量导出会扫描大量数据影响其他租户。解决导出走只读副本或者对大租户做限流导出任务排队执行。架构设计文档里要明确“重操作隔离”策略别让一个租户的操作影响全局。5. 进阶用租户分级和灰度迁移把架构演进成本压下来SaaS 架构不是一次设计到位而是随租户结构演进的。我一般会把租户分成三级S 级走独立库、A 级走共享库独立表、B 级走共享表。分级不是拍脑袋而是按营收贡献、合规要求、数据量三个维度打分。分级的好处是架构升级时只动需要动的部分不用全量重构。灰度迁移是另一个关键技巧。当你要把一批租户从共享表迁到独立库不要一次性切。做法是双写一段时间用影子表校验数据一致性确认无误后切读最后停写旧表。迁移期间租户无感知出问题能快速回滚。# 双写校验新旧存储同时写比对结果不一致则告警 def dual_write(tenant_id, record): old_result write_to_shared(tenant_id, record) new_result write_to_dedicated(tenant_id, record) if not consistent(old_result, new_result): alert(ftenant {tenant_id} dual-write mismatch) return new_result逻辑说明双写期间以新存储为准旧存储作为回滚兜底。consistent 函数比对关键字段不一致时告警但不阻断业务。参数上双写持续时间取决于数据量和一致性要求一般至少覆盖一个完整业务周期。验证迁移是否成功我习惯看三个指标数据行数一致、关键字段校验和一致、业务查询延迟没有明显上升。这三个都过了才停旧存储。最后说个我自己的教训早期做 SaaS 时我总想把架构设计得“一步到位”结果过度设计拖慢了交付。后来才明白SaaS 架构的核心不是多先进而是隔离边界清晰、计费口径可信、迁移路径可走。把这三件事写进文档、落到代码比堆中间件有用得多。希望帮到你。本文还有配套的精品资源点击获取