SaaS 平台

一、SaaS 是什么

SaaS = Software as a Service，软件即服务

一句话：软件不在你本地电脑 / 服务器上安装，放在厂商云端，你通过浏览器、APP 直接用，按账号订阅付费。

核心特点：

  1. 厂商负责服务器、运维、升级、安全；你只管使用
  2. 大多按「账号 / 月 / 年」订阅收费，不用一次性买软件授权
  3. 随时随地，有网就能登录
  4. 多用户，数据存在服务商云端

和另外两个云概念简单区分（PaaS / IaaS）

类型全称通俗理解例子
SaaS 软件即服务 直接用成品软件 钉钉、企业微信、飞书、在线 CRM
PaaS 平台即服务 给你开发平台，自己写应用 阿里云函数计算、腾讯云开发
IaaS 基础设施即服务 买云服务器、硬盘、网络 阿里云 ECS、腾讯云 CVM

哪些应用属于 SaaS（日常常见）

✅ 办公协作类：飞书、钉钉、企业微信、石墨文档、腾讯文档

✅ 客户管理 CRM：销售易、纷享销客、简道云

✅ 财务 / 进销存：金蝶云星空、用友畅捷通好会计

✅ 邮件：网易企业邮箱

✅ 国外例子：Zoom、Slack、Salesforce、Office 365（微软 365）

对比传统软件（本地部署）

传统软件：买光盘 / 安装包，装在自己服务器，自己维护，一次性买授权，升级要单独花钱。 SaaS：不用部署，开通账号即用，服务商自动更新版本，订阅制。

简单举个例子

你公司要做客户管理：

  • 传统方案：买服务器，装 CRM 软件，找人维护，服务器坏了自己修。
  • SaaS 方案：直接注册销售易账号，浏览器登录，厂商负责服务器、备份、版本更新，你按账号每年交钱。

小提醒：不是所有网页版软件都是 SaaS，核心是厂商托管运维 + 订阅服务模式。比如你自己买服务器部署一套网页系统，那只是 Web 应用，不是 SaaS。

二、前端工程师需要掌握的 SaaS 知识清单

 2.1、先搞懂 SaaS 的业务概念（面试必问）

  1. 多租户 Multi-tenancy（最重要）
    • 含义：一套代码、一套后端服务，隔离多个不同客户（租户）的数据。
    • 前端要理解：
      • 租户 ID（tenantId）：几乎所有接口请求都要带上，区分是哪个企业的数据。
      • 数据隔离：A 租户看不到 B 租户的数据；前端不能把不同租户的数据混在缓存 / 本地存储。
      • 两种租户模型：
        1. 共享数据库、共享表，靠 tenantId 区分（大部分 SaaS，成本低）
        2. 独立数据库（大客户私有化，数据隔离更强）
    • 前端坑：路由、localStorage、pinia/vuex 缓存，必须按租户隔离；切换租户时，清空缓存，防止串数据。
  2. 订阅 & 计费
    • 概念：套餐、版本（免费版 / 专业版 / 企业版）、账号席位、过期时间、功能权限。
    • 前端职责：
      • 根据当前租户的套餐，控制功能可见性：按钮灰掉、菜单隐藏、弹窗提示升级。
      • 席位数量校验：比如套餐最多 20 人，新增用户时前端做拦截提示（后端必须二次校验，前端只是体验优化）。
  3. 权限体系（SaaS 前端高频开发内容）
    • 两层权限：租户级权限 + 用户角色权限
      • 租户：整个企业能使用哪些模块（购买套餐决定）
      • 用户角色：企业内不同账号（管理员 / 普通成员）能看哪些菜单、操作哪些按钮
    • 前端实现：动态路由、动态菜单、按钮级权限控制。
    • 注意：前端权限只是 UI 隐藏，安全校验一定在后端。
  4. SaaS vs 私有化部署
    • SaaS：云端托管，开箱即用，自动升级；
    • 私有化：部署在客户自己服务器。很多 SaaS 产品会做一套代码同时支持 SaaS 和私有化，前端要处理环境差异（域名、埋点、接口地址、功能开关）。

三、多租户说明

多租户 ≠ 权限控制。权限控制解决「同一个租户内部，A 用户能不能看 B 用户的数据」；多租户解决「租户 A 整个企业，绝对不能摸到租户 B 企业的数据」。

权限是应用层的访问规则；多租户是数据隔离架构，权限只是它上层的其中一层能力。

1. 举个例子帮你分清

租户 A：阿里巴巴；租户 B：字节跳动。 租户 A 内部：员工甲、员工乙

  • 权限控制：控制「阿里巴巴的员工甲能不能看员工乙的单据」。是同一套数据池里的行级访问限制。
  • 多租户：保证阿里巴巴的任何人，不管什么角色，都查不到字节跳动任何一条数据。是租户之间的数据边界。

如果你只做权限，不做多租户： 后端表里没有tenantId，所有企业数据混在一起。哪怕你前端做了菜单隐藏，后端接口一旦出现漏洞，A 企业直接查到 B 企业数据。 👉 权限是 “拦在门口的门卫”；多租户是物理隔开的两栋楼。门卫再严，楼打通了就有泄露风险。

2. 为什么 SaaS 必须做多租户，不能只用权限搞定？

SaaS 商业模式：一套程序实例，同时卖给几十上百家客户。 如果不做多租户隔离，只靠权限，会有几个致命问题：

  1. 安全风险极高 权限是业务逻辑实现的，代码 bug、SQL 拼接失误、接口参数绕过，就会发生跨企业数据泄露。 多租户是底层强制隔离：所有查询强制带上 tenantId，数据库层面过滤，作为兜底。
  2. 业务维度是企业（租户），不是用户 套餐、席位数量、计费、域名、企业配置、水印、企业 SSO、企业独立设置，这些都是绑定在租户身上，不是绑定在单个用户身上。 权限模型只管理用户，管理不了企业级资源。

比如：租户 A 买了高级报表套餐，租户 B 是免费版。这是租户维度开关，不是用户权限。

  1. 运维、资源、计费隔离 多租户可以做：租户级存储用量、租户操作日志、租户独立功能开关、租户数据备份。权限体系做不到按企业统计资源消耗。

3. 两种多租户数据模型（前端要理解差异）

  1. 共享数据库，共享表（最常用 SaaS） 所有客户数据放同一张表，每行数据带tenantId。
  • 前端：每次请求自动带上 tenantId；切换租户必须清空全局状态 / 缓存，防止串租户。
  • 后端：所有 SQL 强制where tenant_id = #{当前租户}。

这里多租户是底层约束，权限是租户内部再叠加一层。

  1. 共享数据库，独立 Schema 或者独立数据库 大客户单独一套表 / 库，隔离更强。 前端感知不大，主要后端成本高，一般给私有化 / 大客户。

4. 他们之间的关系（重点）

多租户隔离（底层边界：企业和企业之间）
    ↓ 在租户内部，再叠加
权限控制（业务访问：同一个企业内不同用户）

✅ 多租户 + 权限：标准 SaaS 架构 ❌ 只有权限、没有租户隔离：不是 SaaS，只是一个多用户后台系统

很多内部管理后台：一套系统，公司内部几千个账号，只用 RBAC 权限，不需要 tenantId，因为只有一家企业在用。这就是普通后台，不是 SaaS。

5. 前端视角最容易踩的坑（面试常问）

很多前端误以为：只要控制好菜单按钮就是 SaaS。 但前端的坑来自租户切换：

  • 用户从租户 A 切换到租户 B，Pinia/Vuex 里残留 A 租户列表数据；
  • localStorage 缓存的数据没有加 tenantId 前缀，串数据；
  • 接口请求丢失 tenantId，后端查出别的企业数据。

👉 前端：tenantId 是全局上下文，不是权限列表里的一项。

6. 极简总结方便面试

权限解决租户内部用户的数据访问；多租户解决不同租户之间的数据隔离。 权限是业务层访问控制，多租户是 SaaS 底层的数据隔离架构。 只靠权限无法防止跨企业数据泄露，所以 SaaS 必须引入多租户。

7、个人疑问

是不是在权限管理上面加一层 tenant_id 权限查询?

表面看起来确实像是：在原有权限查询上多了一个 tenant_id = ? 的 where 条件，但本质定位不一样，不能简单理解成 “多一条权限规则”。

RBAC 权限：同一个租户内部，限制「这个用户能访问哪些业务行」 tenantId 过滤：跨租户隔离，限制「只能访问属于当前企业的所有行」 tenantId 是前置强制过滤条件，不是业务权限。

举个 SQL 对比

假设表：orders，字段 id, tenant_id, owner_user_id

1. tenantId 过滤（多租户）

SELECT * FROM orders WHERE tenant_id = 't1001'

先把所有不属于 t1001 的数据全部筛掉。这一步做完，数据库结果集里，永远不会出现别的企业任何数据。

2. 再叠加 RBAC（租户内部权限）

SELECT * FROM orders 
WHERE tenant_id = 't1001' -- 租户前置过滤
AND owner_user_id = 'u001' -- 当前用户只能看自己创建的订单

RBAC 是在租户数据子集里面再做细粒度控制。

关键区别：为什么不能把 tenantId 当成普通权限？

1. 安全层级不一样

  • RBAC 是业务逻辑层权限，是业务功能。开发很容易漏写、写错、逻辑漏洞。
  • tenantId 是底层安全边界，是强制兜底。理想架构里，后端中间件自动给所有查询追加 tenant_id，业务代码不需要手动写这个条件。

哪怕业务权限代码写崩了（比如忘记加 owner_user_id 条件），只要 tenantId 强制注入，也查不到别的企业数据。 如果 tenantId 只是 RBAC 里的一条权限规则，一旦权限逻辑 bug，直接跨租户泄露。

2. 归属主体不一样

  • RBAC 绑定到用户：用户有角色、菜单权限、数据权限。
  • tenantId 绑定到租户（企业）：套餐、席位、企业配置、企业水印、企业域名、企业 SSO，这些都是租户维度，跟单个用户无关。

同一个用户，可以切换多个租户（比如顾问，同时管理 A、B 两家企业），切换租户本质就是切换全局tenantId，用户本身的角色权限可以不变。 如果 tenantId 只是用户权限的一部分，切换租户这套模型就很难设计。

3. 失败的后果完全不同

  • RBAC 权限失效：同一家企业内，A 员工看到 B 员工单据（内部数据泄露）。
  • tenantId 过滤失效：A 企业看到 B 企业全部数据（客户级重大安全事故，SaaS 致命）。

通俗类比

想象一栋大楼：

  • tenant_id：楼层。t1001 在 3 楼，t1002 在 4 楼。任何查询第一步：只能访问本楼层。
  • RBAC 权限：房间钥匙。在 3 楼里面，你只能打开你有权限的房间。

你不能把 “限制只能在 3 楼活动” 当成一把房间钥匙。楼层是空间隔离，钥匙是房间访问权限。

回到你的疑问：“看起来就是多一层查询条件”

没错，在 SQL 层面代码表现上，确实就是多一个 where 条件。 但是在系统架构、安全模型、业务模型上，二者是分开两层： 第一层：租户隔离（过滤其他企业） 第二层：租户内 RBAC 权限（企业内部数据访问）

前端视角理解这点有什么用

  1. tenantId 是全局上下文，独立于权限列表；登录后先确定当前租户。
  2. 切换租户：改 tenantId，清空所有页面缓存 / 状态，不是单纯重新拉一遍权限。
  3. 接口请求头里，tenantId 一般单独放，不和权限 token 混为一谈。

面试一句话总结

从 SQL 上看确实只是多了一个 tenant_id 查询条件，但二者不是同一层。tenantId 是前置强制过滤，用来隔离不同企业数据，属于 SaaS 底层安全边界；RBAC 权限是在租户数据范围内，控制企业内部用户访问。tenantId 不能当做普通权限，因为它是兜底防护，防止跨租户数据泄露。

posted @ 2026-09-25 12:42  吴飞ff  阅读(25)  评论(0)    收藏  举报