混合多租户：90% 的 SaaS 公司都选错了架构

先说结论

纯共享太挤，全隔离太贵。混合多租户才是中小 SaaS 活下去的最优解。

一、一个真实的痛苦

你做了一套 SaaS，前 100 个客户跑得很好。

第 101 个客户说："我们是国企，数据不能跟别人放一起。"

第 102 个客户说："我们要独立域名，接口必须走我们自己的网关。"

第 103 个客户说："并发太高，你们共用那套服务扛不住。"

这时候你发现——

你架构选型时偷的懒，现在全变成了债。

纯共享？大客户不买单。 全隔离？你养不起那么多套服务。

怎么办？

二、三类多租户，一次讲透

一句话区分：

• 全共享 = 一锅饭，所有人吃同一碗

• 全隔离 = 每人开一桌，成本爆炸

• 混合 = 大锅饭 + 包间，按需分配

三、为什么混合才是正解

1. 成本结构被重新定义

80% 的客户只贡献 20% 的收入，但全隔离架构让你为 100% 的客户付 100% 的成本。

混合架构的本质：用 20% 的架构复杂度，解决 80% 的成本问题。

2. APP 端只改一行配置

// 租户配置示例
{
  "tenant_id": "corp_001",
  "backend_url": "https://api.your-saas.com",      // 中小租户 → 共用接口
  "backend_url": "https://api.vip-client.com",     // 大客户 → 独立接口
  "db_mode": "shared",                              // shared / isolated
  "domain": "app.your-saas.com"                     // 统一入口
}

前端零感知，后端按需路由。 租户登录后拉取配置，所有请求自动走对应后端。

3. 迁移路径清晰

新客户 → 默认共用服务（成本最低）
     ↓
业务增长 / 合规要求 → 迁移至独立部署（平滑升级）
     ↓
不需要时 → 随时切回共用（灵活回退）

不是一刀切，是可进化的架构。

四、核心实现要点

① 统一网关层

APP 不硬编码接口地址，所有请求经过一个 Tenant Router：

APP Request → Tenant Router → 查租户配置 → 转发至对应后端

② 配置中心驱动

用 Nacos / Apollo / 自建配置中心，按租户 ID 下发后端地址、认证方式、超时策略。

③ 独立租户的部署模板化

大客户独立部署不是从零搭，而是用 Docker Compose / K8s Helm Chart 一键拉起，保证技术栈一致，运维成本可控。

④ 数据层的柔性隔离

五、什么时候不该用混合？

说句实话，混合不是银弹。

混合多租户的前提是：你已经验证了产品，开始面对真实的客户分层。

六、一句话总结

架构不是选最先进的，是选最匹配当前阶段的。

纯共享是理想，全隔离是奢侈，混合多租户是现实。

80% 的公司死在过度设计上，也死在过度省成本上。

找到那个平衡点，就是你的护城河。

如果你正在从纯共享往混合架构迁移，最难的不是技术，是跟大客户谈"独立部署"时的定价模型。这个话题值得单独写一篇，需要的话说一声。

本文图片来自于网络，如有侵权，请联系删除！