3. 平台门户架构设计：微服务前端、后端API网关、认证鉴权、插件化集成机制

平台门户作为 Operator 集群资源可视化与运维的统一入口，其架构设计直接决定了系统的可扩展性、安全性与运维效率。本章围绕四大核心组件展开：微服务前端（负责界面组合与动态路由）、后端API网关（负责请求分发与协议转换）、认证鉴权（负责身份校验与权限控制）、插件化集成机制（负责第三方工具与自定义能力的无缝接入）。

3.1 架构总览：四层职责分离

平台门户采用前后端分离的微服务架构，整体分为四层：

3.2 微服务前端：动态组合与沙箱隔离

平台门户的前端采用微前端架构，将原本单体庞大的运维控制台拆分为多个独立开发、独立部署的子应用。主应用（Shell）负责布局、导航、全局状态与认证，子应用负责具体的业务功能，如集群资源列表、Operator 安装向导、告警大盘等。

3.2.1 核心机制

• 动态注册与路由分发：子应用通过注册中心向主应用声明自己的路由前缀与资源入口。主应用根据 URL 路径动态加载对应子应用的 JS/CSS 资源。
• 沙箱隔离：每个子应用运行在独立的 JavaScript 沙箱中，全局变量、样式、DOM 事件互不干扰。qiankun 使用 Proxy 拦截全局对象，Module Federation 通过 Webpack 5 的共享模块机制实现隔离。
• 共享组件库：通用 UI 组件（表格、表单、图表、导航）由主应用统一提供，子应用通过 import map 或 npm 包引用，避免重复打包。

3.3 后端API网关：统一入口与流量治理

API 网关是平台门户的流量枢纽，所有来自前端的请求都必须经过网关。网关负责将请求路由到正确的后端微服务，同时执行跨横切关注点（Cross-Cutting Concerns）的逻辑。

3.3.1 网关核心功能清单

3.4 认证鉴权：零信任安全模型

平台门户采用零信任安全模型，即“永不信任，始终验证”。每个请求（无论来自内部还是外部）都必须经过认证与授权检查。

3.4.1 认证流程

1. 用户登录：前端将用户名/密码或 OAuth2 授权码发送到认证中心（如 Keycloak）。
2. 签发：认证中心验证身份后，返回 Access （JWT 格式，有效期短）和 Refresh （有效期长）。
3. 请求携带 ：前端将 Access 放在 HTTP Header Authorization: Bearer <> 中发送到 API 网关。
4. 网关校验：API 网关使用公钥或 JWKS 端点验证 JWT 签名与有效期，通过后将请求转发到后端服务。
5. 后端细粒度鉴权：后端服务根据 JWT 中的用户角色、租户 ID 执行 RBAC 或 ABAC 权限检查。

3.4.2 RBAC 权限模型

平台门户使用基于角色的访问控制（RBAC），权限结构如下：

• 用户（User）：平台的实际操作者，可属于多个租户。
• 角色（Role）：权限的集合，如 cluster-admin、operator-installer、viewer。
• 权限（Permission）：对特定资源的操作，如 cluster:list、operator:install、alert:acknowledge。
• 租户（Tenant）：资源隔离单元，用户在不同租户下可拥有不同角色。

3.5 插件化集成机制：可插拔的扩展能力

平台门户需要集成多种第三方工具（如 Prometheus、Grafana、ArgoCD、自定义 Operator 面板）。插件化集成机制允许开发者以标准方式注册新功能，而无需修改核心代码。

3.5.1 插件生命周期

3.6 架构设计要点总结

• 前端微服务化：主应用只负责壳与路由，子应用独立迭代，降低团队协作冲突。
• 网关前置认证：在网关层统一校验 JWT，拒绝无效请求，减轻后端服务压力。
• 权限下沉到服务：网关不做细粒度鉴权，由后端服务结合 OPA 或本地策略引擎执行。
• 插件生命周期标准化：注册、加载、运行、卸载四个阶段必须有明确的钩子与清理机制。
• 沙箱隔离：前端使用 qiankun 或 Module Federation 沙箱，后端使用 WebAssembly 或容器 Sidecar 隔离。