161 lines
12 KiB
Markdown
161 lines
12 KiB
Markdown
# 自研4A对标系统 - 总体架构说明
|
||
|
||
## 1. 系统定位
|
||
|
||
### 1.1 为什么做
|
||
|
||
现网4A系统为神州泰岳采购版，存在以下核心痛点：
|
||
- **黑盒依赖**：核心数据模型、流程引擎、认证逻辑不可控，定制需求依赖厂商排期（通常3-6个月）
|
||
- **报价不透明**：二期扩容、功能增补的报价缺乏比价基准
|
||
- **技术演进受限**：无法灵活接入新认证方式（人脸、SIM卡识别等），扩展成本高
|
||
- **运维锁死**：故障排查依赖厂商支撑，MTTR难以压缩
|
||
|
||
本项目利用**1级4A 8期工程已申请的硬件资源**，划拨部分服务器，自研一套与泰岳版功能对标的4A系统，周期**两个月**。
|
||
|
||
### 1.2 核心目标
|
||
|
||
| 维度 | 目标 |
|
||
|------|------|
|
||
| **功能对标** | 覆盖泰岳版90%以上的核心功能（SSO、账号管理、权限管理、审计） |
|
||
| **流程对标** | 实现对标的24个账号管理流程、资源接入流程 |
|
||
| **架构验证** | 验证自研方案在性能、稳定性、安全性上是否可替代采购版 |
|
||
| **成本基线** | 建立"自研 vs 采购"的成本-能力对比基线，支撑后续采购决策 |
|
||
| **技术自主** | 形成完全可控的4A技术栈，后续功能迭代不受厂商约束 |
|
||
|
||
### 1.3 约束条件
|
||
|
||
- **周期**：2个月（包含开发、测试、部署、基线对比）
|
||
- **硬件**：8期工程剩余资源（具体规格视项目申请而定，按通用X86服务器 + KVM虚拟化部署）
|
||
- **团队**：非专职团队，需兼顾现网运维，强调AI辅助开发提效
|
||
- **范围**：不做全量替代，做"可验证对标"版本，功能深度聚焦核心链路
|
||
|
||
---
|
||
|
||
## 2. 四中心架构总览
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────────────┐
|
||
│ 自研4A对标系统 │
|
||
│ │
|
||
│ ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ │
|
||
│ │ 认证身份中心 │ │ 应用资源管理中心 │ │ 系统资源管理中心 │ │
|
||
│ │ │ │ │ │ (含堡垒集群) │ │
|
||
│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │
|
||
│ │ │ 账号数据模型 │ │ │ │ SSO网关 │ │ │ │ 系统资源 │ │ │
|
||
│ │ │ (LDAP/DB) │ │ │ │ (OIDC/SAML) │ │ │ │ 授权模型 │ │ │
|
||
│ │ ├───────────────┤ │ │ ├───────────────┤ │ │ ├───────────────┤ │ │
|
||
│ │ │ 多因素认证 │ │ │ │ 应用注册 │ │ │ │ 堡垒机集群 │ │ │
|
||
│ │ │ 人脸/SIM/密码 │ │ │ │ +元数据管理 │ │ │ │ SSO/录屏 │ │ │
|
||
│ │ ├───────────────┤ │ │ ├───────────────┤ │ │ ├───────────────┤ │ │
|
||
│ │ │ 令牌/会话管理 │ │ │ │ 权限配置 │ │ │ │ 权限 │ │ │
|
||
│ │ │ (JWT/Redis) │ │ │ │ +授权规则引擎 │ │ │ │ 回收/审批流 │ │ │
|
||
│ │ └───────────────┘ │ │ └───────────────┘ │ │ └───────────────┘ │ │
|
||
│ └─────────┬───────────┘ └─────────┬───────────┘ └─────────┬───────────┘ │
|
||
│ │ │ │ │
|
||
│ └──────────┬─────────────┴─────────────┬───────────┘ │
|
||
│ │ │ │
|
||
│ ┌────────▼──────────────────────────▼────────┐ │
|
||
│ │ 审计中心 │ │
|
||
│ │ │ │
|
||
│ │ ┌──────────────┐ ┌───────────────────┐ │ │
|
||
│ │ │ 审计数据湖 │ │ 报表引擎 │ │ │
|
||
│ │ │ (ES引擎存储) │ │ (定时/按需生成) │ │ │
|
||
│ │ ├──────────────┤ ├───────────────────┤ │ │
|
||
│ │ │ 合规规则引擎 │ │ 分级下发通道 │ │ │
|
||
│ │ │ (策略驱动) │ │ (部门级/公司级) │ │ │
|
||
│ │ └──────────────┘ └───────────────────┘ │ │
|
||
│ └────────────────────────────────────────────┘ │
|
||
│ │
|
||
│ ┌──────────────────────────────────────────────────────────────────────┐ │
|
||
│ │ AI全流程兜底闭环层 │ │
|
||
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
|
||
│ │ │代码生成 │ │自动测试 │ │部署编排 │ │智能运维 │ │数据一致性│ │ │
|
||
│ │ │Copilot │ │Agent │ │CI/CD │ │AIOps │ │校验Agent │ │ │
|
||
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │
|
||
│ └──────────────────────────────────────────────────────────────────────┘ │
|
||
└─────────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 2.1 中心间交互关系
|
||
|
||
```
|
||
┌─────────────────┐
|
||
│ 前端网关 │
|
||
│ (统一入口) │
|
||
└────────┬────────┘
|
||
│
|
||
┌──────────────┼──────────────┐
|
||
│ │ │
|
||
┌───────▼──────┐ ┌────▼─────┐ ┌─────▼──────┐
|
||
│ 认证身份中心 │ │ 应用资源 │ │ 系统资源 │
|
||
│ (认证鉴权) │ │ 管理中心 │ │ 管理中心 │
|
||
└───────┬──────┘ └────┬─────┘ └─────┬──────┘
|
||
│ │ │
|
||
└──────┬───────┴──────┬──────┘
|
||
│ │
|
||
┌──────▼──────────────▼──────┐
|
||
│ 审计中心 │
|
||
│ (接收全量操作事件) │
|
||
└────────────────────────────┘
|
||
```
|
||
|
||
**核心数据流**：
|
||
1. 用户请求 → 前端网关 → 认证身份中心（登录认证）→ 颁发令牌
|
||
2. 用户携带令牌 → 应用资源管理中心（SSO接入应用）/ 系统资源管理中心（SSO接入堡垒机）
|
||
3. 全量操作事件 → 异步写入 → 审计中心（ES存储）
|
||
4. 审计中心 → 合规规则引擎 → 异常告警/报表生成
|
||
|
||
---
|
||
|
||
## 3. 两个月研发计划
|
||
|
||
```
|
||
Week 1-2: 基础设施搭建 + 认证身份中心核心 (账号模型 + 密码认证 + JWT)
|
||
Week 3-4: 多因素认证接入 (人脸/SIM/短信) + 令牌管理
|
||
Week 5-6: 应用资源管理中心 (SSO网关 + 应用注册 + 基本授权)
|
||
Week 7: 系统资源管理中心 + 堡垒机SSO原型
|
||
Week 8: 审计中心MVP + AI测试 + 与泰岳版比对验证
|
||
```
|
||
|
||
### 交付原则
|
||
|
||
- **每两周一个可演示版本**：第一周结束出认证登录页，第二周结束出SSO跳转
|
||
- **AI优先**：能用AI生成的代码、测试用例、部署脚本绝不手写
|
||
- **模块化**：每个中心独立可部署，降低集成风险
|
||
- **记录一致**：所有反推结论/接口规范写入文档，作为与泰岳谈判的技术基线
|
||
|
||
---
|
||
|
||
## 4. AI全流程兜底闭环策略
|
||
|
||
详见 `ai-cicd.md`，核心思路：
|
||
|
||
1. **开发阶段**：AI辅助生成全部业务代码（CRUD + API + 前端），人工聚焦架构和安全性审查
|
||
2. **测试阶段**：AI Agent自动生成测试用例、执行回归测试、比对与泰岳版的行为差异
|
||
3. **部署阶段**：AI编排部署流水线（Ansible/Terraform），自动处理配置差异
|
||
4. **运维阶段**：AI监控日志异常、自动排查一致性偏差、推送修复建议
|
||
5. **验收阶段**：AI驱动功能覆盖度扫描，自动生成"自研vs泰岳"比对报告
|
||
|
||
---
|
||
|
||
## 5. 与泰岳版比对策略
|
||
|
||
| 比对维度 | 方法 | 产出物 |
|
||
|---------|------|-------|
|
||
| 功能覆盖 | 逐功能点人工标记 + AI辅助扫描 | 功能覆盖矩阵表 |
|
||
| 性能基准 | 相同硬件上运行压测脚本 | 响应时间/并发量对比曲线 |
|
||
| 认证流程 | 录制泰岳版操作流程 → 生成测试脚本 → 在自研版本执行 | 流程一致度报告 |
|
||
| 数据模型 | 反推泰岳库结构 → 与自研模型逐字段比对 | 数据模型差异表 |
|
||
| 安全等级 | 相同安全基线扫描工具 | 安全差距分析 |
|
||
|
||
---
|
||
|
||
## 6. 风险与对策
|
||
|
||
| 风险 | 概率 | 影响 | 对策 |
|
||
|------|------|------|------|
|
||
| 两个月内功能覆盖不足 | 高 | 中 | 聚焦核心链路（SSO+账户管理），非核心功能标记为"二期" |
|
||
| 泰岳接口反向推导不完整 | 中 | 高 | 重点攻克登录/授权关键接口，优先保证自研体系内部闭环 |
|
||
| 团队人力分散 | 高 | 中 | AI最大化替代重复劳动，每个中心配1-2人即可启动 |
|
||
| 与现网系统对接兼容问题 | 中 | 高 | 提前识别对接点，使用适配器模式隔离变更 |
|