企业级 SaaS 系统开发中，最容易被 "技术先进" 带偏、也最容易埋下后期隐患的，就是第一步的架构选型。很多团队一上来就上微服务，结果分布式事务、链路追踪、服务治理的成本远超业务本身的复杂度。
结合多年服务企业数字化转型的经验，聊聊三种主流架构怎么选，以及多租户数据隔离这个 SaaS 特有的关键决策。
一、三种架构的本质区别
- 单体架构：一个进程、一个数据库，逻辑简单，部署运维成本最低，适合业务早期或中小体量。
- 模块化单体：仍是单进程，但按业务域划分清晰模块，模块间通过内部接口解耦。它是单体到微服务之间的 "性价比最优解"------ 大部分企业 SaaS 业务体量，到这里就够了。
- 微服务：按业务能力拆分成独立服务，独立部署、独立扩展。适合团队规模大、业务模块间确需独立伸缩、多团队并行开发的场景。
判断标准不是 "哪个先进"，而是三个问题：业务复杂度是否真的需要拆分？团队是否有能力承担分布式治理成本？流量是否到了单实例无法承载的程度？
二、SaaS 特有的核心决策：多租户数据隔离
这是企业级 SaaS 和普通项目最不一样的地方。三种主流方案各有取舍：
| 方案 | 隔离级别 | 优点 | 代价 |
|---|---|---|---|
| 独立数据库 | 高 | 租户间物理隔离，合规好做，便于单独备份 | 成本高，运维量大 |
| 共享数据库、共享 Schema | 低 | 成本最低，资源利用率高 | 隔离弱，一处故障影响所有租户 |
| 共享库、独立 Schema | 中 | 逻辑隔离，兼顾成本与安全 | 跨库查询复杂，迁移麻烦 |
选型建议 ：对数据合规要求高、客户数据敏感的行业（如金融、医疗、企业 ERP），优先独立库或独立 Schema；对标准化 SaaS 产品，共享库 + Row Level Security 配合严格的租户 ID 隔离，是成本和安全的平衡点。关键是不管选哪种，租户 ID 必须进入所有核心表的主键或索引设计，这是后期不返工的前提。
三、必须避开的三个坑
- 过早微服务化：业务还没跑通就拆服务，把简单问题复杂化。建议 "模块化单体起步，按需演进"。
- 数据库设计不做租户隔离：上线后发现隔离有漏洞，改造成本极高，还可能引发数据越权风险。
- 忽略可观测性：日志、监控、链路追踪在架构设计阶段就要规划，而不是上线出问题才补。
架构选型速查：
- 团队 < 20 人、业务初期 → 单体 / 模块化单体
- 多团队并行、模块独立扩展 → 微服务
- 数据敏感行业 → 独立库 / 独立 Schema
- 标准化产品、控成本 → 共享库 + 租户 ID 隔离
架构没有最好，只有最适合当前阶段。判断一个架构是否成功，不是看它多 "先进"，而是看业务在三年内是否被架构拖累。把选型逻辑想清楚，远比跟风技术潮流更重要。