如何实现一个多应用的 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/8/4 07:04

查看所有更新日志

7e927-文档站全面重构：目录重排、首页重写、案例独立成站、应用市场下线于 2026/8/4
8044c-docs: 同步未提交文档变更于 2026/7/4