如何实现一个多应用的 SaaS 平台：通用应用、平台应用与定制应用
约 5285 字大约 18 分钟
2026-07-01
引言：为什么需要多应用架构
很多系统看起来功能很多，菜单很长，但本质上仍然是"单应用"。判断标准很简单：如果把系统中的某些功能模块拆分出去，是否会影响整个系统的权限模型、菜单模型和数据模型？如果答案是"会"，那它离真正的多应用还有距离。
单应用多模块的设计在业务初期没有问题，但当系统复杂到一定程度，会出现四个典型痛点：
- 菜单爆炸：所有功能堆在一个入口，用户找不到自己需要的功能。
- 无法按需订阅：租户只能全开或全关，无法单独购买某个垂直能力。
- 权限边界模糊：平台运营功能和租户业务功能混在一起，平台管理员可能误操作租户数据，租户管理员可能看到平台配置。
- 大客户定制难：行业大客户的定制需求无法独立交付，只能侵入主代码分支，导致主干越来越臃肿。
真正的多应用架构，需要在四个层面都支持"应用"这一维度：
- 数据模型：应用是独立实体，租户与应用是多对多关系。
- 菜单体系：每个应用有自己的菜单树，租户订阅后可以独立裁剪。
- 权限体系：角色和权限可以按应用划分。
- 前端入口：不同应用可以对应不同的前端工程或独立入口。
这篇文章从架构层面讲清楚：什么样的系统能称为多应用，应用有哪些类型，通用/平台/租户/定制四种形态如何区分和转换，以及多应用体系如何支撑租户定制和持续扩展。
第一部分：为什么能叫"多应用"
判断一个系统是不是真正的多应用，不能只看界面入口，而要看底层是否满足四个判定标准。
标准一：应用定义与租户绑定分离
真正的多应用必须有独立的应用定义表，以及独立的租户-应用绑定表。应用定义表回答"系统有哪些能力"，绑定表回答"这个租户开通了哪些能力"。
如果没有独立的绑定表，只是在用户角色里写死"你能看到哪些模块"，那就不是多应用，只是单应用里的权限控制。
标准二：应用可以独立订阅
应用与租户是多对多关系：
- 一个应用可以被多个租户订阅。
- 一个租户可以订阅多个应用。
- 每个租户对同一个应用可以有不同的状态、过期时间、授权策略。
这意味着平台可以像应用市场一样运营：上架、下架、试用、付费、授权码开通。
标准三：菜单和权限按应用隔离
每个应用有自己的菜单树，租户订阅后生成副本。租户管理员可以隐藏、排序、重命名、收藏菜单，而不会影响应用模板，也不会影响其他租户。
权限也可以按应用划分。同一个用户，在"系统管理"应用中是管理员，在"物联网控制台"应用中可能只有查看权限。
标准四：前端入口可以独立
不同应用可以对应不同的前端工程。平台管理后台、租户管理后台、物联网控制台、移动端 App、小程序，可以分别开发和部署，后端只负责统一的应用元信息和认证。
与单应用多模块的对比
只有同时满足"独立定义、独立订阅、独立菜单、独立入口"四个条件，才能称为真正的多应用 SaaS 平台。
第二部分：应用类型与扩展
一个 SaaS 平台需要服务多种终端：Web、移动端、小程序、原生客户端。多应用架构的设计目标之一，是让后端能力一次建设、多端复用。
应用载体的三种形态
- Web 应用：运行在浏览器中，适合管理后台、数据大屏、运营中心。
- 原生应用：需要调用设备能力或离线运行，适合移动办公、设备运维客户端。
- 小程序：轻量入口，适合微信生态、快速触达用户。
为什么需要区分载体
不同终端有不同的交互习惯、发布节奏和技术栈。把它们建模成不同的应用载体，可以带来三个好处：
- 同一后端能力服务多端，避免重复开发。
- 不同终端可以独立演进技术栈，互不拖累。
- 新增终端时，不需要改造已有应用。
如何扩展新的应用类型
新增一种终端形态时，架构上只需要三步：
- 扩展元信息：在应用模型中增加新的载体类型枚举。
- 新增前端工程：按应用模板创建新的前端工程。
- 配置应用入口：在应用管理后台录入入口地址、菜单模板、图标等信息。
原有应用的逻辑不需要改动，平台就能支持新的终端形态。这种扩展方式是多应用架构的重要收益。
第三部分：四种应用形态
多应用体系中最核心的设计，是把应用分成四种形态：通用应用、平台应用、租户应用、定制应用。它们的定义、可见范围、转换关系各不相同。
通用应用：一次开发，多租户复用
通用应用由平台统一开发，所有租户都可以订阅。它是 SaaS 规模化交付的核心。
适用场景：
- 系统管理、平台大厅等基础能力。
- 物联网控制台、数据大屏、运营中心等标准化业务系统。
- 不需要为每个租户单独开发的功能。
优势：
- 边际成本最低：开发一次，所有租户受益。
- 版本统一：所有租户使用同一版本，便于统一升级和安全修复。
- 运营灵活：可以上架、下架、试用、授权码开通、按租户授权。
实现要点：
- 应用归属公共租户，所有租户可见。
- 租户订阅时，系统生成绑定记录并复制菜单模板。
- 平台通过运营后台管理应用的上架状态、价格策略、试用规则。
平台应用：与租户应用严格隔离
平台应用是专门给平台管理员、运营人员使用的后台系统。它的权限域必须和普通租户应用严格分开。
适用场景：
- 平台级用户管理、全局配置。
- 运营统计、系统监控、授权码管理。
- 平台自身的管理和运维工具。
优势：
- 权限边界清晰：平台管理员不会误操作租户数据。
- 信息安全：租户管理员看不到平台配置。
- 独立迭代：平台功能的发布不受租户应用影响。
实现要点：
- 应用归属平台租户。
- 菜单角色限定为平台管理员。
- 查询时非平台管理员自动过滤平台应用。
租户应用：通用应用的具体实例
租户应用不是独立定义出来的，而是租户订阅通用应用后生成的绑定关系。它体现了"同一个应用在不同租户中的不同状态"。
为什么需要租户应用：
通用应用是模板，租户应用才是具体使用权。同一个通用应用被不同租户订阅后，可以各自拥有：
- 独立的启用/禁用状态。
- 独立的过期时间。
- 独立的菜单副本。
- 独立的角色和权限配置。
优势：
- 同一应用在不同租户完全独立控制。
- 支持按租户授权、试用、付费。
- 租户定制不会影响其他租户。
定制应用：满足个性化与大客户交付
定制应用是为某个具体租户或行业场景深度定制的应用。它是 SaaS 平台标准化能力之上的弹性补充。
适用场景：
- 私有化品牌控制台。
- 行业专属功能模块。
- 大客户定制流程和报表。
- 需要独立域名或品牌化入口的交付。
优势：
- 在标准化平台上交付个性化能力。
- 定制能力可以沉淀为通用应用，扩大收益。
- 支持品牌化和独立入口。
实现要点：
- 应用归属具体租户，其他租户不可见。
- 独立菜单、角色、权限、数据范围。
- 通过修改应用归属，支持定制升级成通用。
第四部分：四种形态的转换关系
四种形态不是孤立的，它们之间存在清晰的转换关系。理解这些转换关系，是设计灵活应用市场的关键。
通用应用 ↔ 定制应用
某个租户定制出来的能力具有通用价值时，可以把它改为公共归属，发布给所有租户订阅。反过来，当通用应用需要为某个大客户深度定制时，也可以复制一份并改为该租户专属。
注意事项：
- 已订阅的租户如何处理？如果是从定制改为通用，原租户继续保留使用权，其他租户也能订阅。
- 如果是从通用改为定制，必须确保其他租户已经没有订阅关系。
通用应用 → 租户应用
租户订阅通用应用时，系统自动生成绑定记录。这个转换是最常见的，每次租户开通应用都会发生。
平台应用与其他应用
平台应用不参与租户订阅，它通过租户码和菜单角色双重隔离，避免与普通租户应用混淆。
演进闭环
多应用体系最强的能力是形成"标准化 → 定制 → 再标准化"的闭环：
平台用通用应用服务大众，为大客户定制，再把经过验证的定制能力沉淀为新的通用应用，最终服务更多租户。这个闭环让 SaaS 平台既能保持标准化规模优势，又能持续吸收行业需求。
第五部分：租户定制能力
多应用体系不仅要能交付标准化应用，还要支持租户级定制。否则，租户买到的只是"一刀切的软件"，而不是"按自己业务调整过的系统"。
菜单定制
租户订阅应用后，系统会把应用菜单模板复制为租户菜单副本。租户管理员可以：
- 隐藏不需要的菜单。
- 调整菜单顺序。
- 重命名菜单。
- 收藏常用菜单。
关键设计：模板与副本分离。应用模板升级时，租户的副本不会被覆盖，保障了租户的个性化配置。
权限定制
租户管理员可以在角色管理中按应用分配权限。不同应用可以拥有独立的角色体系，同一个用户在不同应用中可以有不同的角色和权限。
典型场景：某用户在"系统管理"应用中是管理员，在"物联网控制台"应用中只有查看权限。
授权与付费定制
租户-应用绑定表记录了租户对应用的使用状态：
- 是否启用。
- 是否过期。
- 是否处于试用期。
- 是否通过授权码开通。
平台可以按租户控制应用是否可用、试用多久、是否需要付费，实现精细化的应用运营。
入口定制
应用可以配置不同的入口地址。同一应用在不同租户可以指向不同的前端地址或不同的主题。
典型场景：
- 通用版本使用平台统一的主题。
- 大客户定制版本使用客户品牌色和独立域名。
这种入口级别的定制，让 SaaS 平台在保持统一后端能力的同时，能够支撑品牌化、私有化交付。
第六部分：系统应用的自动绑定
一个 SaaS 平台总有一些基础应用是租户默认需要的，例如系统管理、平台大厅等。如果每次创建新租户都要手动开通，运营效率会很低。
为什么需要自动绑定
- 新租户应该"开箱即用"。
- 避免运营人员手动配置出错。
- 保证所有租户拥有统一的基础能力。
自动绑定的设计
- 标记系统应用：在应用定义中标记
isSysCreated = true，这些应用不可删除。 - 配置默认绑定列表：新租户创建时，系统读取默认应用 ID 列表。
- 创建绑定记录：为租户生成
SysTenantApp记录。 - 复制菜单模板：将应用菜单模板复制到
SysTenantMenu。 - 按租户类型过滤菜单角色：平台租户和普通租户看到的菜单不同。
平台租户与普通租户的差异
同一套系统应用，在不同类型租户下应该呈现不同的菜单结构：
- 平台租户：可以看到平台级菜单和普通租户菜单中适合平台运营的部分。
- 普通租户：只能看到
common归属的系统应用菜单，平台级菜单被过滤掉。
这种差异不是通过硬编码实现，而是通过菜单角色和租户类型的匹配规则自动过滤。
第七部分：前端应用的组织与扩展
多应用体系最终要落到一个问题：前端怎么组织？常见的有两种思路：单体式前端和多工程前端。
单体式前端的局限
如果所有功能都放在一个前端工程里，会出现：
- 代码量越来越大，构建时间越来越长。
- 不同团队同时修改同一个仓库，冲突频繁。
- 某个应用的改动可能影响整个平台的发布。
多工程前端的架构
采用"后端统一管理、前端独立演进"的方式：
- 每个前端工程独立存在于代码仓库。
- 独立开发、独立构建、独立部署。
- 共享基础组件库和 API 层。
- 后端统一管理应用元信息和入口地址。
快速创建新前端应用
为了降低创建新应用的成本，平台可以提供应用模板和脚手架脚本。典型流程是：
- 选择模板（例如物联网控制台模板）。
- 指定应用目录名、应用 ID、开发端口、应用标题。
- 脚本生成新的前端工程，并更新根配置。
- 在后端应用管理里录入入口地址和菜单模板。
这种方式让新应用的创建从"数周"缩短到"数小时"。
第八部分：多应用架构的权衡与踩坑
多应用架构带来灵活性的同时，也引入了一些需要警惕的问题。
通用应用 vs 定制应用：什么时候该做定制
- 坚持做标准化：需求具有行业通用性，或可以通过配置满足。
- 值得做定制：单个客户愿意支付足够溢价，且需求无法通过配置实现。
过早为每个大客户做定制，会让平台失去规模优势；过度坚持标准化，又会丢失大客户订单。关键是建立"配置 → 扩展点 → 定制"的递进策略。
平台应用与租户应用混用的风险
如果平台功能和租户功能没有清晰隔离，会出现：
- 平台管理员误操作租户数据。
- 租户管理员看到平台配置。
- 平台功能的发布需要迁就租户应用的节奏。
必须从一开始就划定权限域，并通过租户码、菜单角色、查询过滤三重机制保证隔离。
应用版本升级与租户菜单副本的兼容
应用模板升级时，如何处理已经生成的租户菜单副本？常见策略有：
- 不覆盖：只修改模板，不影响已有租户副本。适合新增菜单不会破坏租户配置的场景。
- 合并：把新增菜单追加到租户副本，保留租户的隐藏、排序等定制。适合大多数场景。
- 强制刷新：某些安全相关的菜单变更，允许平台强制同步到所有租户。
应用下架后已订阅租户的处理
应用下架不是简单地把状态改为"下架"。需要考虑：
- 已订阅的租户是否还能继续使用？
- 是否允许续费？
- 数据如何迁移或导出？
- 界面上的入口如何隐藏？
这些问题需要在应用生命周期设计阶段就定义清楚。
跨应用权限与统一身份的平衡
用户只有一个账号，但可能在多个应用中拥有不同角色。设计时需要注意：
- 登录态在所有应用间共享。
- 每个应用的权限独立判断。
- 用户切换应用时不需要重新登录，但需要重新校验应用级权限。
结语：多应用体系的核心价值
实现一个多应用 SaaS 平台，核心在于"应用定义与租户绑定分离"。应用定义描述系统有哪些能力，租户绑定描述谁开通了这些能力，菜单模板定义应用长什么样，租户菜单副本承载个性化定制。
这种分层设计带来了几个关键能力：
- 通用应用可以一次开发、多租户复用，形成规模效应。
- 平台应用可以与租户应用严格隔离，保障平台安全。
- 租户应用让同一应用在不同租户中独立运行，支持授权和付费。
- 定制应用满足大客户的个性化需求，并能把验证过的能力沉淀为新的通用应用。
- 多终端载体让后端能力一次建设、多端复用。
真正的多应用不是界面上的模块堆砌，而是数据模型、菜单体系、权限体系、前端工程都围绕"应用"这一维度进行设计。只有这样，SaaS 平台才能像应用市场一样灵活地发布、订阅、定制和扩展应用能力。
更新日志
2026/7/4 21:43
查看所有更新日志
8044c-docs: 同步未提交文档变更于
