4、平台门户架构设计：微服务前端架构、API网关模式、门户与后端服务通信模型

镜像供应链信任边界平台的门户并非单体应用，而是采用微服务前端架构（Micro-Frontend），结合API网关模式实现前后端解耦与统一入口。本节将拆解门户的技术栈选型、网关路由策略以及前后端通信模型，确保平台在RBAC集成后仍保持高内聚、低耦合的架构韧性。

4.1 微服务前端架构设计

平台门户采用主应用 + 子应用的微前端架构，每个功能域（镜像扫描、策略管理、审计日志、用户中心）独立开发、独立部署，通过主应用容器聚合。

层级 组件 技术选型 职责
主应用容器 Shell App Vue 3 + Vite 路由分发、全局认证、菜单布局、子应用生命周期管理
子应用A 镜像扫描门户 React 18 + Ant Design 镜像漏洞展示、扫描任务提交、结果导出
子应用B 策略管理中心 Vue 3 + Element Plus 信任策略编排、签名规则配置、RBAC角色映射
子应用C 审计与合规 Angular 15 + PrimeNG 操作日志检索、合规报告生成、告警事件流
子应用D 用户与租户管理 Vue 3 + Naive UI 组织架构、RBAC角色分配、SSO集成
架构要点：子应用之间不直接通信，所有跨域数据交互通过主应用的全局状态总线（基于 RxJS 的 EventBus）或共享 API 网关完成。每个子应用拥有独立的构建产物，通过 qiankun 或 Module Federation 加载到主应用沙箱中。

4.2 API网关模式与路由策略

API网关作为门户的唯一后端入口，承担请求路由、身份认证、限流熔断、协议转换四大职责。平台选用 Kong Gateway（开源版） 作为网关层，部署在 Kubernetes 集群边缘。

网关功能 实现方式 对应RBAC集成点
请求路由 基于 Path + Header 分发到不同微服务 路由规则中携带 X-Role 标签用于下游鉴权
身份认证 JWT 校验 + OAuth2 Proxy 网关层解析 中的 sub 和 realm_access.roles
限流熔断 Kong Rate Limiting + Circuit Breaker 插件 按角色等级分配不同 QPS 配额（admin 1000/s, viewer 50/s）
协议转换 gRPC-Web 转 gRPC / REST 转 GraphQL 转换层注入 X-User-Context 元数据
网关路由示例（Kong声明式配置）： 
services:
  - name: image-scan-service
    url: http://scan-svc:8080
    routes:
      - name: scan-route
        paths: [/api/v1/scan]
        methods: [GET, POST]
        plugins:
          - name: jwt
            config: { claims_to_verify: ["exp", "nbf"] }
          - name: rate-limiting
            config: { minute: 200, policy: "local" }

4.3 门户与后端服务通信模型

前端门户与后端微服务之间采用分层通信模型，确保RBAC上下文在每一层透传且不丢失。整体通信链路分为三层：

  1. 浏览器 → API网关：HTTPS + JWT Bearer ，网关校验 有效性并提取角色信息。
  2. API网关 → 微服务：内部 gRPC 或 HTTP/2，网关在请求头注入 X-User-ID、X-User-Roles、X-Tenant-ID。
  3. 微服务 → 数据层：服务内部通过 Sidecar（Istio）或 SDK 解析上下文，执行行级 RBAC 过滤。
关键约束：微服务不得信任网关传递的原始角色字符串，必须通过内部 或 mTLS 证书二次校验。网关仅做透传，不做授权决策；授权决策下沉到各微服务的 Policy Engine（如 OPA / Casbin）。
门户与后端服务通信模型 门户与后端服务通信模型（三层链路） 浏览器 / SPA 门户 HTTPS + JWT API 网关（Kong） JWT校验 限流 路由 gRPC / HTTP/2 + 上下文注入 镜像扫描服务 策略管理服务 审计日志服务 OPA Policy Casbin RBAC OPA Policy PostgreSQL + Row-Level RBAC Redis + 策略缓存 Elasticsearch + 审计索引 说明：网关层仅做身份校验与路由，授权决策下沉至各微服务的Policy Engine，数据层执行行级RBAC过滤

4.4 通信模型中的RBAC上下文传递

RBAC上下文在通信链路中的传递遵循“透传不篡改，落地必校验”原则。下表展示各层传递的上下文属性：

通信段 传递方式 携带属性 安全约束
浏览器 → 网关 HTTP Header: Authorization: Bearer <JWT> sub, realm_access.roles, tenant_id JWT 签名校验 + 过期时间检查
网关 → 微服务 gRPC Metadata / HTTP Header: X-User-Context user_id, roles (JSON数组), tenant_id mTLS 双向认证，网关与微服务共享CA
微服务 → 数据层 SQL Session Variable / Redis Key Prefix current_user, current_roles 数据库连接池隔离，每请求设置 SET SESSION app.current_user
最佳实践：在微服务内部使用 gRPC Interceptor 统一解析 X-User-Context，将其注入到 context.Context 中，后续所有数据库查询和策略评估均从 Context 中提取 RBAC 信息，避免重复解析。
RBAC上下文传递时序图 RBAC上下文传递时序图 浏览器 API网关 微服务 数据层 1. POST /api/v1/scan (JWT) 2. gRPC (X-User-Context) OPA评估 3. SQL (SET SESSION app.roles) 4. 行级RBAC过滤结果 5. gRPC响应 (含RBAC审计) 6. HTTP 200 (JSON) 关键点：网关解析JWT后构造X-User-Context，微服务通过Interceptor注入Context， 数据层通过Session Variable实现行级RBAC过滤，全程不丢失角色与租户信息

4.5 架构决策与避坑指南

  • 避免网关过重：API网关只做路由与认证，不做业务聚合。业务聚合由BFF（Backend For Frontend）层或GraphQL网关完成，防止网关成为性能瓶颈。
  • 子应用隔离：微前端子应用必须运行在沙箱中（CSS隔离 + JS沙箱），防止子应用之间样式污染或全局变量冲突。推荐使用 qiankun 的 sandbox: { strictStyleIsolation: true }。
  • 刷新策略：JWT Access 有效期设为15分钟，Refresh 设为7天。网关层统一处理 刷新，子应用无需感知。
  • 上下文透传测试：在 CI/CD 管道中加入 RBAC上下文传递集成测试，模拟不同角色（admin/auditor/viewer）发起请求，验证数据层返回结果是否按角色过滤。
生产级配置示例（Kong网关JWT插件）： 
plugins:
  - name: jwt
    config:
      uri_param_names: [jwt]
      cookie_names: []
      key_claim_name: iss
      secret_is_base64: false
      claims_to_verify: [exp, nbf]
      anonymous: null
      run_on_preflight: true
← 上一章 📖 返回目录 下一章 →