SaaS 架构演进：从卖软件到运营平台

想象一个场景：你做了套企业管理软件，最早是一家客户一家客户地卖——装服务器、部署、培训、收钱，典型的传统软件生意。后来你想清楚了要做 SaaS：客户按月付费、打开浏览器就能用。第一家中型客户签了，第二十家也签了，直到有一天，一家银行说：“数据必须物理隔离，或者这单免谈。”

这时候你的架构怎么摆？这就是 SaaS 架构演进要回答的问题。这篇是 SaaS 系列的开篇，讲清整条演进路线的“为什么”，后面的租户隔离、生命周期、套餐计费都长在这条线上。

一、阶段一：一客户一套部署（传统交付）

起步阶段最自然的做法：每个客户独立部署一套应用和数据库。

客户 A：应用 A + 数据库 A
客户 B：应用 B + 数据库 B
客户 C：应用 C + 数据库 C ……

这个阶段谈不上“架构”，就是卖软件的交付方式。它的优点很实在：数据物理隔离，客户天然放心；每个客户还能独立定制，改了 A 的报表不影响 B。

但 SaaS 的商业模式会把它逼死：

SaaS 的盈利模型是边际成本递减——第 100 个客户几乎不增加成本。一客户一套部署正好相反，这个模式下做不了 SaaS。

SaaS 转型的核心一步：只部署一套应用、一个数据库，所有客户的数据放同一批表里，靠每张表的 tenant_id 字段隔离。

SaaS 架构演进三个阶段

成本结构瞬间变了：新增一个客户只是插一行租户记录，服务器不用加、升级只跑一遍、客户注册完当场能用。这套方案的代价是隔离强度从“物理”降到“逻辑”——所有数据挤在一批表里，一条 SQL 忘了拼 tenant_id 就是数据泄漏事故。

所以这个阶段的技术重点就一个：怎么让隔离不依赖程序员的自觉。答案是框架层自动兜底——租户插件自动改写 SQL、租户 ID 跟着登录态走、缓存和会话按租户隔离。这套机制展开讲内容很多，单独成篇：

生意做大，新问题来了。金融、医疗、政企类大客户会提合规要求：数据不能跟别人混放，要物理隔离。如果只有“全共享”和“全独立”两个选项，你只能二选一：接大客户，回到阶段一的高成本；不接，眼看着高客单价的单子飞了。

成熟的解法是混合架构：

第三点的约束比听起来难。它意味着“大客户的定制需求”不能靠改代码实现，而要靠配置和功能开关——同一套代码，用配置裁剪出不同客户的形态。这正是后面两篇的主角：

《SaaS 套餐功能开关设计》——按套餐/租户裁剪功能
混合架构里另一个隐含话题是版本漂移：独立部署的环境不归你直接运维，客户环境跑半年不升级，和大版本差得越来越远，最后升级一次的成本接近重新交付。所以独立部署通常要配套“强制升级窗口”条款和自动化升级工具。

注意演进方向：隔离强度在递减，边际成本也在递减——你牺牲的隔离感，换来了规模。而混合架构是两条曲线的平衡点：把愿意为隔离付钱的客户挑出来，其余的留在池子里。

① 一上来就设计独立库。 “客户数据放各自的库更安全”——安全是真的，但 10 个客户就要维护 10 份 schema 变更脚本，加个字段跑 10 遍 DDL，跨租户统计报表根本做不了。字段级隔离 + 框架兜底是中小租户场景的性价比之王，等真有大客户为隔离付钱，再切独立部署不迟。

② 混合架构 = 两套产品。 给大客户独立部署时忍不住“顺手改点代码”，从此独立版本和共享版本越走越远。维护两套产品的成本会在第二次大升级时爆发。正确的姿势是：差异全部收敛到配置层，代码永远只有一套。

③ 把 SaaS 理解成“部署在云上的传统软件”。 多租户不是部署问题，是数据模型和请求链路的系统性改造——从数据库字段到缓存 key 到登录会话都要有租户概念。这也是为什么“传统软件加个登录页”改不成 SaaS。