# 从功能权限到业务能力：G2rain 如何实现应用化交付

企业平台发展到一定阶段后，权限系统经常会遇到一个看似矛盾的问题：菜单、按钮和接口已经管理得很细，真正向客户交付时，却仍然需要研发、实施和运维团队反复确认“这个租户究竟应该开通哪些功能”。

原因并不复杂。传统权限模型主要解决访问控制，回答的是“谁可以操作什么”；SaaS 交付还需要回答另外几个问题：

某项功能属于哪个应用？
多个功能如何组成客户能够理解的业务能力？
哪些能力已经交付给某个租户？
能力开通后，用户角色可以使用其中哪些功能？
能力升级、下线或商业化时，影响范围如何确定？

如果这些问题没有进入统一模型，平台就会出现两套事实：系统里保存一套角色权限，合同、实施文档或运维脚本里再保存一套客户交付范围。随着租户和应用增多，两套事实很难长期保持一致。

G2rain 的应用化交付模型，就是为了把访问控制与租户交付连接起来。

# 传统权限模型为什么不够

常见的后台权限系统通常围绕以下关系展开：

用户 → 角色 → 菜单、按钮、接口

这个模型适合判断某个用户能否打开页面、点击按钮或调用接口，但它更接近系统内部的技术视角。

客户采购或开通的往往不是某几个接口，而是“内容管理”“组织管理”“会员运营”这样的业务能力。实施团队交付的也不是一张资源表，而是一组可以独立使用、持续升级的应用与服务。

当平台只管理资源权限时，容易出现几类问题：

资源数量不断增长，业务含义却越来越难识别。
同一项业务能力分散在多个菜单、按钮和接口中。
租户开通范围依赖人工配置，容易遗漏或越权。
应用版本变化后，很难判断哪些租户受到影响。
权限配置与商品、订阅、实施交付之间缺少稳定连接。

因此，细粒度权限仍然必要，但它不能成为 SaaS 交付模型的终点。

# G2rain 的四层对象模型

G2rain 将资源、应用、功能权限和业务能力组织成一条连续主线，让每个对象承担不同层次的职责。

# 资源：描述系统中的操作对象

资源是页面、菜单、按钮、接口等可识别对象。它们最接近系统实现，用于建立访问控制的基础数据。

资源需要足够细，才能准确限制操作边界；但资源本身并不适合直接作为租户交付单位，因为客户不应该面对大量技术细节。

# 应用：承载身份、资源与接入边界

应用是资源和平台能力的组织载体。在 G2rain 中，应用不只是一组前端页面，而是具备独立身份和接入边界的平台单元。

平台维护应用信息与公钥，应用保存自身私钥并参与安全协作。主壳、网关、IAM 和子应用由此可以围绕明确的应用身份建立访问链路。

应用化带来的价值包括：

资源具有清晰归属，不再散落在平台全局。
前端子应用和后端接口可以围绕同一应用组织。
身份、安全、路由和权限具备共同边界。
应用可以独立开发、部署、升级和停止。

# 功能权限：平台侧最小控制单元

功能权限用于表达应用内部可以授权的具体能力。它可以聚合页面、按钮和接口资源，并与角色建立关系。

相比直接向角色分配大量资源，功能权限提供了更稳定的业务语义。例如“内容编辑”“内容审核”和“内容发布”可以分别成为功能权限，即使底层页面或接口发生调整，角色所获得的业务含义仍然清晰。

# 业务能力：租户侧最小交付单元

业务能力进一步聚合多个功能权限，面向租户表达可以开通和交付的完整能力。

例如，“内容运营”可以包含内容查询、编辑、审核和发布等功能权限。租户开通的是“内容运营”这项业务能力，租户管理员再根据岗位职责把其中不同功能分配给编辑、审核人员和运营负责人。

这让平台同时保留两种必要粒度：

对租户，以业务能力表达清晰的交付范围。
对用户，以功能权限表达细粒度的操作边界。

# 从平台能力到租户可用功能

一项新能力从开发完成到租户真正可用，可以沿着以下链路进入平台：

业务团队按领域边界实现后端服务和前端子应用。
页面、按钮和接口资源归属到对应应用。
相关资源被组织为具有业务语义的功能权限。
多个功能权限聚合为面向租户的业务能力。
平台向目标租户开通业务能力。
租户管理员根据岗位与职责向角色分配功能权限。
用户登录后，主壳根据应用、租户和权限信息呈现可用入口。
用户发起操作时，网关与后端服务继续执行身份和权限校验。

这条链路把“开发了什么”“交付了什么”和“用户能做什么”连接成同一套平台事实。

# 一个内容管理场景

以 G2rain 的 CMS 场景为例，一个租户需要使用内容管理能力，但不同岗位承担不同职责：

编辑人员负责创建和修改内容。
审核人员负责检查内容并决定是否通过。
运营负责人拥有最终发布和下线权限。

在只管理菜单的系统中，团队可能为不同角色组合页面与按钮，并额外记录该租户是否购买了内容管理模块。

在应用化交付模型中，可以这样组织：

g2rain-cms-app 作为前端交互应用承载内容管理入口。
g2rain-cms 作为领域服务提供内容相关业务接口。
页面、按钮和接口形成应用资源。
编辑、审核、发布分别形成稳定的功能权限。
这些功能权限共同组成面向租户交付的内容管理业务能力。
租户开通业务能力后，再按照岗位为角色分配具体功能权限。

如果后续增加新的内容检查步骤，可以调整应用资源和功能权限，而不必改变“租户已经开通内容管理能力”这一交付事实。

这个例子说明的是平台建模方式，具体功能范围应以对应项目的最新公开文档和版本为准。

# 应用独立身份为什么重要

当平台只有一个后台系统时，所有请求共享同一种客户端身份似乎已经足够。但在多应用 SaaS 平台中，不同应用可能由不同团队维护，具有不同发布周期和访问范围。

如果平台只识别用户，不识别应用，就难以完整回答：

这次调用由哪个应用发起？
该应用是否允许请求这个接口？
用户虽然拥有某项角色，是否能够通过当前应用使用它？
某个应用下线后，相关访问链路是否已经关闭？

因此，G2rain 同时关注用户身份与应用身份。用户身份说明“谁在操作”，应用身份说明“通过哪个受信任的接入单元操作”。两者与租户、角色和功能权限结合，形成更适合多应用平台的安全上下文。

# 从功能交付走向持续交付

应用化模型的价值不只体现在首次开通，更体现在平台长期演进中。

# 独立升级

业务域服务和前端子应用保持独立边界，可以按照自身节奏开发和发布。平台通过应用与能力模型识别影响范围，再通过标准部署体系完成更新。

# 清晰回收

租户停止使用某项业务时，可以围绕业务能力回收交付范围，而不是人工查找所有相关菜单和接口。应用停止服务时，也有明确的身份和资源边界。

# 商业化衔接

业务能力比菜单或接口更适合与商品、订阅和开通流程关联。一个商品可以组合多项业务能力，租户订阅后由平台完成对应能力开通。

商业化不是权限系统的附带逻辑，而是建立在稳定能力模型上的后续流程。

# AI 调用治理

当平台能力未来通过 MCP Server 提供给 Agent 和 Skill 时，同一套模型仍然有效：AI 能发现哪些工具，不代表它天然拥有调用权限。

平台仍需根据用户、应用、租户、功能权限和业务能力做确定性判断。这样，AI 成为新的受控交互方式，而不是绕过现有治理体系的特殊入口。

# 对不同团队意味着什么

# 对平台研发团队

共性身份与权限能力不必在每个业务项目中重复实现。
新应用按照统一模型接入，降低长期维护的不一致。
资源变化与业务交付之间具有清晰边界。

# 对业务开发团队

可以专注领域逻辑，通过标准工程体系快速创建服务和子应用。
业务能力复用平台身份、权限、网关和基础设施能力。
独立模块不会因为接入平台而被迫并入一个大型单体。

# 对实施和运营团队

可以用业务语言描述租户获得的能力。
租户开通范围与系统实际权限配置更容易保持一致。
新增、升级和回收能力时，影响范围更加明确。

# 对租户管理员

平台决定租户拥有哪些业务能力。
租户管理员在已开通范围内，根据组织岗位分配功能权限。
平台交付边界与企业内部职责分工不会混在一起。

# 当前对应的开源项目

G2rain 已经围绕应用化交付形成多个相互协作的项目：

g2rain-basis：承载应用、角色、资源、功能权限等平台核心模型。
g2rain-iam：负责统一认证与身份主链路。
g2rain-main-shell：承载统一前端入口与子应用装载。
g2rain-manager-app：提供平台管理侧交互入口。
g2rain-app-template 与 g2rain-app-cli：帮助新子应用遵循统一接入规范。
g2rain-deploy：负责标准部署、持续更新、备份与回滚。

这些项目分别解决模型、身份、交互、工程和交付问题，共同组成应用化能力，而不是由某一个仓库独立完成全部职责。

# 结语

企业 SaaS 平台的权限系统不能只停留在“谁能看到哪个菜单”。随着应用、租户和业务能力持续增长，平台还需要建立从技术资源到客户价值的稳定映射。

G2rain 通过资源、应用、功能权限和业务能力四个层次，把细粒度访问控制与租户交付连接起来：资源负责精确控制，应用负责组织与身份边界，功能权限负责平台授权，业务能力负责租户交付。

当控制模型和交付模型使用同一套事实，平台才能更可靠地支持独立应用扩展、持续部署、商业化开通，以及未来由 AI 驱动的业务能力编排。