# G2rain 平台架构：从统一底座到持续交付
企业 SaaS 平台真正困难的部分，往往不是完成第一个业务系统，而是让第十个应用、第一百个租户和持续变化的业务流程仍然能够在同一套规则下运行。
随着系统数量增长，认证、权限、应用接入、业务交付和运维能力很容易散落在不同项目中。短期看，每个团队都能独立完成需求；长期看，重复建设和不一致的模型会不断抬高平台的演进成本。
G2rain 希望解决的正是这个问题：先建立稳定、可治理的企业级平台底座，再让业务域、前端应用和 AI 能力在清晰边界内持续扩展。
# 架构设计的三个出发点
# 平台能力必须统一沉淀
认证、权限、应用、资源、审计、网关和运行基础设施不是某一个业务系统的附属功能，而是所有应用共享的平台能力。只有把这些能力统一起来，租户隔离、角色授权和多应用协作才不会随着项目增多而失控。
# 业务扩展不能侵入平台核心
企业业务会持续变化，平台核心却需要保持稳定。G2rain 通过 DDD 组织业务域，让 CMS、部门等领域服务独立演进，同时复用身份、权限和基础设施能力。新业务不是继续向“平台大单体”追加代码，而是以领域模块和独立应用接入。
# 开发完成不等于可以交付
一个能力只有能够被应用承载、被权限控制、向租户开通并稳定部署，才真正具备平台价值。因此，G2rain 将应用化、业务能力和部署交付视为架构主干，而不是开发完成后的补充工作。
# 六层架构如何协作
G2rain 当前由 20 个持续维护的正式开源项目组成，按照六个方向组织。每一层解决一类问题，同时通过统一模型连接起来。
| 架构层 | 核心职责 | 代表项目 |
|---|---|---|
| 边缘入口层 | 统一路由、入口控制以及与认证链路协同 | g2rain-gateway-webflux、g2rain-gateway-webmvc |
| 交互接入层 | 主壳、子应用装载、菜单路由、应用身份和前端安全链路 | g2rain-main-shell、g2rain-manager-app 等 5 个前端项目 |
| 平台核心层 | 身份认证、应用与角色资源、功能权限和公共基础设施 | g2rain-basis、g2rain-iam、g2rain-infra |
| 业务域扩展层 | 按 DDD 承载具体业务，保持领域能力与平台核心解耦 | g2rain-cms、g2rain-department |
| 工程支撑层 | 公共库、Starter、数据访问扩展、代码生成和应用脚手架 | g2rain-common、g2rain-crafter、g2rain-app-cli 等 7 个项目 |
| 部署交付层 | 环境初始化、服务编排、部署更新、备份与回滚 | g2rain-deploy |
# 一次访问如何穿过这些层
从用户打开平台到操作某项业务能力，典型链路可以概括为：
- 用户从统一入口访问平台，请求首先进入网关和前端接入链路。
g2rain-iam建立用户身份与登录状态，应用自身也以独立身份参与安全协作。g2rain-basis根据租户、应用、角色、资源和功能权限判断可访问范围。g2rain-main-shell加载租户已开通并且用户有权访问的子应用。- 子应用调用对应业务域服务，业务服务复用平台公共能力，但保持领域逻辑独立。
g2rain-infra提供字典、国际化、区域语言、路由元数据、分布式 ID 等运行支撑。- 最终由标准部署体系把网关、后端服务、前端应用和中间件交付到目标环境。
这条链路体现了 G2rain 的核心取舍：身份、控制、业务和交付各有边界，但不是彼此孤立的模块。
# 应用化模型是架构中轴
很多管理平台的权限模型停留在“用户—角色—菜单/接口”。这能够回答用户能否访问某项资源，却难以回答能力如何组合、如何交付给租户，以及如何进一步进入订阅和开通流程。
G2rain 将这些对象组织为一条连续主线：
- 页面、按钮、接口等资源归属到应用。
- 应用承载平台侧最小控制单元——功能权限。
- 多个功能权限可以聚合为面向业务的能力包。
- 业务能力成为租户侧更清晰的交付与开通单元。
- 业务能力可以继续与商品、订阅和开通流程衔接。
因此，“应用”在 G2rain 中不是一组页面。每个应用都具有独立身份、接入边界和能力集合，是安全控制、前端装载和业务交付共同依赖的载体。
# 从一个业务域到可交付应用
如果团队要增加一个新的业务域，推荐路径不是复制一个已有项目后自由扩展，而是沿着平台约束逐步落地。
# 领域建模
先明确业务边界、核心对象和最小业务能力，再通过 DDD 组织后端模块。领域服务只维护自身业务规则，身份、权限等共性问题交给平台底座。
# 工程生成
后端可以复用 Common、Spring Boot Starter、MyBatis 扩展、Maven 生成插件和 Crafter；前端可以通过 App CLI 与标准模板创建符合平台约定的微前端应用。脚手架的意义不只是少写代码，更重要的是让新项目天然符合接入规范。
# 平台接入
把接口、页面和操作资源注册到应用，建立功能权限并聚合业务能力。平台由此知道“这个应用提供什么”“谁可以使用”以及“向哪个租户交付”。
# 独立交付
后端领域服务和前端子应用保持独立版本边界，再通过 g2rain-deploy 进入统一部署、更新、备份与回滚流程。这样，新业务可以快速加入平台，又不需要改变平台核心的职责。
# 安全不是某个模块的单独责任
G2rain 的安全链路同时面向用户身份和应用身份：
- IAM 负责统一认证、令牌与登录主链路。
- 平台维护应用信息与公钥，应用保存自身私钥并参与签名协同。
- 网关承担统一入口控制，与身份体系共同完成 API 访问保护。
- 角色、资源、功能权限和业务能力决定授权范围。
- 租户、部门和数据权限进一步约束企业数据边界。
这让“谁在调用、以哪个应用调用、能够操作什么、能力交付给谁”可以在同一平台模型中得到回答，也为未来 AI 调用平台能力提供治理基础。
# 当前开源版图与演进边界
20 个正式项目已经覆盖平台核心、双技术栈网关、主壳与业务子应用、DDD 业务示例、工程脚手架和标准部署。g2rain-member 与 g2rain-member-app 仍在开发中，不计入正式开源项目数量。
AI 原生方向建立在现有平台底座之上：先让接口能力具备清晰的领域边界、身份约束和权限语义，再逐步接入 MCP Server、Agent、Skill 以及云端编排与监控。它是 G2rain 的持续演进主线，不应被理解为所有 AI 能力已经一次性完成。
# 这套架构适合谁
G2rain 更适合需要长期建设企业平台的团队，而不是只寻找单一业务成品的团队。典型场景包括：
- 需要统一管理多个后台应用和业务子系统。
- 需要同时处理用户身份、应用身份、多租户和细粒度权限。
- 需要持续增加业务域，又希望平台核心保持稳定。
- 希望把功能开发、租户交付和后续商业化放进同一模型。
- 正在探索如何让 AI 安全地进入企业私有业务流程。
# 结语
G2rain 的架构目标不是把更多组件放进一张图，而是建立一套能够持续工作的协作规则：平台底座负责统一治理，业务域负责快速变化，应用模型连接控制与交付，工程体系保证扩展一致性，部署体系把能力送到真实环境。
当这些基础关系稳定下来，AI 才有机会从一个附加功能，进一步成为能够理解、组合和执行平台能力的新交互方式。