admin/CompanyRegister
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
ChuXun
2026-01-28 23:56:33 +08:00
commit f98da73376
92 changed files with 8261 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

236
plans/architecture_design.md Normal file
View File

@@ -0,0 +1,236 @@
# 智能办公管理系统 - 架构设计文档
## 项目概述
智能办公管理系统是一个企业级应用，包含考勤管理、审批流程、文档协作和即时通讯四大核心模块。系统采用微服务架构思想，前后端分离设计。
## 技术栈
### 后端技术栈
- **框架**: Spring Boot 3.2.x
- **安全**: Spring Security 6 + JWT
- **数据库**:
- PostgreSQL 15 (主业务数据)
- MongoDB 7 (文档存储)
- Redis 7 (缓存/会话)
- **消息队列**: RabbitMQ 3.12
- **实时通信**: WebSocket + STOMP
- **API文档**: SpringDoc OpenAPI 3
- **监控**: Spring Boot Actuator + Prometheus + Grafana
- **测试**: JUnit 5 + Mockito + Testcontainers
### 前端技术栈
- **框架**: React 18 + TypeScript
- **UI库**: Ant Design Pro 7.x
- **状态管理**: Redux Toolkit + RTK Query
- **路由**: React Router 6
- **构建工具**: Vite 5
- **图表**: ECharts 5
- **实时**: Socket.IO Client
### 基础设施
- **容器化**: Docker + Docker Compose
- **CI/CD**: GitHub Actions
- **部署**: 可部署到Kubernetes
- **日志**: ELK Stack (Elasticsearch, Logstash, Kibana)
## 系统架构图
```mermaid
graph TB
subgraph "客户端层"
Web[Web浏览器]
Mobile[移动端]
Desktop[桌面应用]
end
subgraph "负载均衡层"
Nginx[Nginx反向代理]
end
subgraph "应用服务层"
Gateway[API网关]
subgraph "微服务集群"
Auth[认证服务]
User[用户服务]
Attendance[考勤服务]
Approval[审批服务]
Document[文档服务]
Chat[聊天服务]
Notification[通知服务]
end
end
subgraph "数据存储层"
PostgreSQL[(PostgreSQL)]
MongoDB[(MongoDB)]
Redis[(Redis)]
RabbitMQ[(RabbitMQ)]
end
subgraph "监控层"
Prometheus[Prometheus]
Grafana[Grafana]
ELK[ELK Stack]
end
Web --> Nginx
Mobile --> Nginx
Desktop --> Nginx
Nginx --> Gateway
Gateway --> Auth
Gateway --> User
Gateway --> Attendance
Gateway --> Approval
Gateway --> Document
Gateway --> Chat
Gateway --> Notification
Auth --> PostgreSQL
User --> PostgreSQL
Attendance --> PostgreSQL
Approval --> PostgreSQL
Document --> MongoDB
Chat --> Redis
Chat --> RabbitMQ
Notification --> RabbitMQ
Auth --> Redis
User --> Redis
Prometheus --> Auth
Prometheus --> User
Prometheus --> Attendance
Grafana --> Prometheus
ELK --> Auth
ELK --> User
```
## 核心模块设计
### 1. 用户认证授权模块
- **功能**: 用户注册、登录、JWT令牌管理、权限控制
- **技术**: Spring Security + OAuth2 + JWT
- **数据库表**: users, roles, permissions, user_roles
### 2. 考勤管理模块
- **功能**: 打卡记录、请假申请、加班申请、考勤统计
- **技术**: 地理围栏、人脸识别集成、考勤规则引擎
- **数据库表**: attendance_records, leave_requests, overtime_requests
### 3. 审批流程模块
- **功能**: 工作流定义、审批节点、流程实例、审批历史
- **技术**: Activiti/Flowable工作流引擎
- **数据库表**: workflows, workflow_instances, approval_nodes
### 4. 文档协作模块
- **功能**: 文档创建、在线编辑、版本控制、权限管理
- **技术**: MongoDB GridFS + WebSocket协同编辑
- **数据库表**: documents, document_versions, collaborations
### 5. 即时通讯模块
- **功能**: 一对一聊天、群组聊天、文件传输、消息状态
- **技术**: WebSocket + STOMP + Redis Pub/Sub
- **数据库表**: chat_rooms, messages, participants
## API设计原则
1. RESTful API设计
2. 版本控制 (v1, v2)
3. 统一响应格式
4. 全局异常处理
5. 请求限流和防重放
6. API接口文档自动生成
## 安全设计
1. HTTPS强制使用
2. JWT令牌认证
3. RBAC权限模型
4. 敏感数据加密存储
5. SQL注入防护
6. XSS/CSRF防护
7. 请求频率限制
## 性能优化
1. Redis缓存热点数据
2. 数据库读写分离
3. CDN静态资源加速
4. 图片压缩和懒加载
5. API响应压缩
6. 数据库连接池优化
## 部署架构
1. 开发环境: Docker Compose本地部署
2. 测试环境: Kubernetes集群
3. 生产环境: 多可用区高可用部署
4. 数据库: 主从复制 + 自动备份
5. 文件存储: 对象存储(S3兼容)
## 监控告警
1. 应用性能监控(APM)
2. 业务指标监控
3. 日志集中收集
4. 错误追踪和告警
5. 健康检查和自愈
## 项目目录结构
```
smart-office-system/
├── backend/ # 后端项目
│ ├── smart-office-auth/ # 认证服务
│ ├── smart-office-user/ # 用户服务
│ ├── smart-office-attendance/# 考勤服务
│ ├── smart-office-approval/ # 审批服务
│ ├── smart-office-document/ # 文档服务
│ ├── smart-office-chat/ # 聊天服务
│ ├── smart-office-gateway/ # API网关
│ └── smart-office-common/ # 公共模块
├── frontend/ # 前端项目
│ ├── src/
│ │ ├── api/ # API接口
│ │ ├── components/ # 公共组件
│ │ ├── pages/ # 页面组件
│ │ ├── store/ # 状态管理
│ │ ├── utils/ # 工具函数
│ │ └── styles/ # 样式文件
│ ├── public/ # 静态资源
│ └── config/ # 配置文件
├── infrastructure/ # 基础设施
│ ├── docker/ # Docker配置
│ ├── k8s/ # Kubernetes配置
│ ├── scripts/ # 部署脚本
│ └── monitoring/ # 监控配置
├── docs/ # 项目文档
├── tests/ # 测试文件
└── plans/ # 设计文档
```
## 开发计划
1. 第一阶段: 基础框架搭建 (2周)
2. 第二阶段: 核心模块开发 (4周)
3. 第三阶段: 前端界面开发 (3周)
4. 第四阶段: 集成测试和优化 (2周)
5. 第五阶段: 部署和监控 (1周)
## 风险评估和应对
1. **技术风险**: 微服务复杂度高
- 应对: 先采用单体架构，逐步拆分
2. **性能风险**: 实时通信压力大
- 应对: 使用Redis集群和消息队列削峰
3. **安全风险**: 敏感数据泄露
- 应对: 多层安全防护和审计日志
4. **部署风险**: 多环境配置复杂
- 应对: 使用配置中心和容器化部署
## 成功指标
1. 系统可用性: 99.9%
2. API响应时间: <200ms (P95)
3. 并发用户数: 支持1000+同时在线
4. 数据一致性: 事务成功率>99.99%
5. 系统扩展性: 支持水平扩展
---
*文档版本: v1.0*
*最后更新: 2026-01-27*
*作者: 架构设计团队*

495
plans/database_design.md Normal file
View File

@@ -0,0 +1,495 @@
# 智能办公管理系统 - 数据库设计文档
## 数据库架构概述
系统采用多数据库设计，根据业务特点选择最适合的数据库类型：
- **PostgreSQL**: 核心业务数据（用户、角色、权限、考勤、审批等）
- **MongoDB**: 文档协作、聊天记录、文件元数据等非结构化数据
- **Redis**: 缓存、会话、分布式锁、消息队列
- **Elasticsearch**: 日志、搜索、分析
## PostgreSQL数据库设计
### 1. 认证授权模块 (auth_service)
#### 1.1 用户表 (sys_user)
```sql
CREATE TABLE sys_user (
id BIGSERIAL PRIMARY KEY,
username VARCHAR(50) NOT NULL UNIQUE,
password VARCHAR(200) NOT NULL,
email VARCHAR(100),
phone VARCHAR(20),
nickname VARCHAR(50),
real_name VARCHAR(50),
avatar VARCHAR(500),
gender INTEGER DEFAULT 0,
birthday TIMESTAMP,
dept_id BIGINT,
position VARCHAR(100),
status INTEGER DEFAULT 1,
last_login_time TIMESTAMP,
last_login_ip VARCHAR(50),
login_count INTEGER DEFAULT 0,
failed_login_count INTEGER DEFAULT 0,
lock_time TIMESTAMP,
password_reset_time TIMESTAMP,
is_super_admin BOOLEAN DEFAULT FALSE,
remark VARCHAR(500),
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
create_by BIGINT,
update_by BIGINT,
deleted BOOLEAN DEFAULT FALSE
);
CREATE INDEX idx_username ON sys_user(username);
CREATE INDEX idx_email ON sys_user(email);
CREATE INDEX idx_phone ON sys_user(phone);
CREATE INDEX idx_dept_id ON sys_user(dept_id);
```
#### 1.2 角色表 (sys_role)
```sql
CREATE TABLE sys_role (
id BIGSERIAL PRIMARY KEY,
role_code VARCHAR(50) NOT NULL UNIQUE,
role_name VARCHAR(50) NOT NULL,
description VARCHAR(200),
data_scope INTEGER DEFAULT 1,
status INTEGER DEFAULT 1,
sort INTEGER DEFAULT 0,
is_system BOOLEAN DEFAULT FALSE,
remark VARCHAR(500),
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
create_by BIGINT,
update_by BIGINT,
deleted BOOLEAN DEFAULT FALSE
);
CREATE INDEX idx_role_code ON sys_role(role_code);
CREATE INDEX idx_role_name ON sys_role(role_name);
```
#### 1.3 权限表 (sys_permission)
```sql
CREATE TABLE sys_permission (
id BIGSERIAL PRIMARY KEY,
permission_code VARCHAR(100) NOT NULL UNIQUE,
permission_name VARCHAR(50) NOT NULL,
permission_type INTEGER NOT NULL,
parent_id BIGINT DEFAULT 0,
path VARCHAR(200),
component VARCHAR(200),
icon VARCHAR(100),
sort INTEGER DEFAULT 0,
status INTEGER DEFAULT 1,
is_visible BOOLEAN DEFAULT TRUE,
is_cache BOOLEAN DEFAULT FALSE,
is_external BOOLEAN DEFAULT FALSE,
external_url VARCHAR(500),
request_method VARCHAR(20),
api_path VARCHAR(500),
remark VARCHAR(500),
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
create_by BIGINT,
update_by BIGINT,
deleted BOOLEAN DEFAULT FALSE
);
CREATE INDEX idx_permission_code ON sys_permission(permission_code);
CREATE INDEX idx_parent_id ON sys_permission(parent_id);
CREATE INDEX idx_sort ON sys_permission(sort);
```
#### 1.4 关联表
```sql
-- 用户角色关联表
CREATE TABLE sys_user_role (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
role_id BIGINT NOT NULL,
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
UNIQUE(user_id, role_id)
);
-- 角色权限关联表
CREATE TABLE sys_role_permission (
id BIGSERIAL PRIMARY KEY,
role_id BIGINT NOT NULL,
permission_id BIGINT NOT NULL,
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
UNIQUE(role_id, permission_id)
);
```
### 2. 考勤管理模块 (attendance_service)
#### 2.1 考勤记录表 (attendance_record)
```sql
CREATE TABLE attendance_record (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
dept_id BIGINT,
attendance_date DATE NOT NULL,
check_in_time TIMESTAMP,
check_out_time TIMESTAMP,
work_hours DECIMAL(5,2),
late_minutes INTEGER DEFAULT 0,
early_minutes INTEGER DEFAULT 0,
overtime_hours DECIMAL(5,2) DEFAULT 0,
attendance_status INTEGER DEFAULT 0, -- 0:正常, 1:迟到, 2:早退, 3:缺勤, 4:请假, 5:加班
location VARCHAR(200),
latitude DECIMAL(10,8),
longitude DECIMAL(11,8),
device_info VARCHAR(200),
ip_address VARCHAR(50),
remark VARCHAR(500),
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_user_date ON attendance_record(user_id, attendance_date);
CREATE INDEX idx_dept_date ON attendance_record(dept_id, attendance_date);
```
#### 2.2 请假申请表 (leave_request)
```sql
CREATE TABLE leave_request (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
leave_type INTEGER NOT NULL, -- 1:年假, 2:病假, 3:事假, 4:婚假, 5:产假, 6:丧假
start_time TIMESTAMP NOT NULL,
end_time TIMESTAMP NOT NULL,
duration_days DECIMAL(5,2),
reason VARCHAR(500),
attachment_url VARCHAR(500),
status INTEGER DEFAULT 0, -- 0:待审批, 1:已通过, 2:已拒绝, 3:已取消
approval_flow_id BIGINT,
current_approver_id BIGINT,
remark VARCHAR(500),
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_user_status ON leave_request(user_id, status);
CREATE INDEX idx_approval_flow ON leave_request(approval_flow_id);
```
#### 2.3 加班申请表 (overtime_request)
```sql
CREATE TABLE overtime_request (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
overtime_date DATE NOT NULL,
start_time TIMESTAMP NOT NULL,
end_time TIMESTAMP NOT NULL,
duration_hours DECIMAL(5,2),
reason VARCHAR(500),
compensation_type INTEGER DEFAULT 1, -- 1:调休, 2:加班费
status INTEGER DEFAULT 0,
approval_flow_id BIGINT,
current_approver_id BIGINT,
remark VARCHAR(500),
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
```
### 3. 审批流程模块 (approval_service)
#### 3.1 工作流定义表 (workflow_definition)
```sql
CREATE TABLE workflow_definition (
id BIGSERIAL PRIMARY KEY,
workflow_code VARCHAR(50) NOT NULL UNIQUE,
workflow_name VARCHAR(100) NOT NULL,
workflow_type INTEGER NOT NULL, -- 1:请假, 2:加班, 3:报销, 4:采购, 5:通用
description VARCHAR(500),
version INTEGER DEFAULT 1,
status INTEGER DEFAULT 1,
form_schema JSONB,
process_definition JSONB,
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
create_by BIGINT,
update_by BIGINT
);
```
#### 3.2 工作流实例表 (workflow_instance)
```sql
CREATE TABLE workflow_instance (
id BIGSERIAL PRIMARY KEY,
workflow_definition_id BIGINT NOT NULL,
business_key VARCHAR(100),
business_type VARCHAR(50),
business_data JSONB,
initiator_id BIGINT NOT NULL,
current_node_id BIGINT,
current_assignee_id BIGINT,
status INTEGER DEFAULT 0, -- 0:进行中, 1:已完成, 2:已终止, 3:已取消
start_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
end_time TIMESTAMP,
duration_days INTEGER,
remark VARCHAR(500),
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_business_key ON workflow_instance(business_key);
CREATE INDEX idx_initiator_status ON workflow_instance(initiator_id, status);
```
#### 3.3 审批节点表 (approval_node)
```sql
CREATE TABLE approval_node (
id BIGSERIAL PRIMARY KEY,
workflow_instance_id BIGINT NOT NULL,
node_code VARCHAR(50) NOT NULL,
node_name VARCHAR(100) NOT NULL,
node_type INTEGER NOT NULL, -- 1:开始, 2:审批, 3:会签, 4:或签, 5:结束
assignee_type INTEGER NOT NULL, -- 1:指定人, 2:角色, 3:部门负责人, 4:发起人自选
assignee_ids JSONB,
status INTEGER DEFAULT 0, -- 0:待处理, 1:已通过, 2:已拒绝, 3:已跳过
start_time TIMESTAMP,
end_time TIMESTAMP,
duration_hours DECIMAL(5,2),
comment VARCHAR(500),
attachment_url VARCHAR(500),
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
```
### 4. 文档协作模块 (document_service)
#### 4.1 文档表 (document) - MongoDB集合
```json
{
"_id": ObjectId,
"document_id": String,
"title": String,
"content": String,
"content_type": String, // "text", "markdown", "html"
"owner_id": Number,
"owner_name": String,
"space_id": String,
"parent_id": String,
"tags": [String],
"permissions": {
"view": [Number], // 用户ID列表
"edit": [Number],
"comment": [Number],
"share": [Number]
},
"version": Number,
"current_version_id": String,
"is_published": Boolean,
"published_version": Number,
"status": String, // "draft", "published", "archived"
"metadata": {
"word_count": Number,
"page_count": Number,
"language": String,
"created_from": String // "web", "mobile", "import"
},
"statistics": {
"view_count": Number,
"edit_count": Number,
"comment_count": Number,
"share_count": Number
},
"created_at": Date,
"updated_at": Date,
"deleted_at": Date
}
```
#### 4.2 文档版本表 (document_version) - MongoDB集合
```json
{
"_id": ObjectId,
"version_id": String,
"document_id": String,
"version_number": Number,
"title": String,
"content": String,
"content_hash": String,
"change_summary": String,
"author_id": Number,
"author_name": String,
"created_at": Date,
"metadata": {
"operation": String, // "create", "edit", "restore"
"client_info": String,
"ip_address": String
}
}
```
### 5. 即时通讯模块 (chat_service)
#### 5.1 聊天室表 (chat_room) - MongoDB集合
```json
{
"_id": ObjectId,
"room_id": String,
"room_name": String,
"room_type": String, // "private", "group", "channel"
"avatar": String,
"description": String,
"owner_id": Number,
"admin_ids": [Number],
"member_ids": [Number],
"settings": {
"mute_all": Boolean,
"allow_invite": Boolean,
"need_approval": Boolean,
"max_members": Number
},
"last_message": {
"message_id": String,
"content": String,
"sender_id": Number,
"sender_name": String,
"timestamp": Date
},
"unread_count": Map, // userId -> count
"created_at": Date,
"updated_at": Date
}
```
#### 5.2 消息表 (message) - MongoDB集合
```json
{
"_id": ObjectId,
"message_id": String,
"room_id": String,
"sender_id": Number,
"sender_name": String,
"sender_avatar": String,
"content_type": String, // "text", "image", "file", "voice", "video"
"content": String,
"metadata": {
"file_url": String,
"file_name": String,
"file_size": Number,
"duration": Number,
"width": Number,
"height": Number
},
"reply_to": String, // 回复的消息ID
"mentions": [Number], // 被@的用户ID
"reactions": Map, // emoji -> [userId]
"read_by": [Number], // 已读用户ID
"deleted_for": [Number], // 对哪些用户不可见
"is_system": Boolean,
"is_edited": Boolean,
"edited_at": Date,
"is_recalled": Boolean,
"recalled_at": Date,
"created_at": Date,
"updated_at": Date
}
```
### 6. 系统管理模块
#### 6.1 部门表 (sys_department)
```sql
CREATE TABLE sys_department (
id BIGSERIAL PRIMARY KEY,
dept_code VARCHAR(50) NOT NULL UNIQUE,
dept_name VARCHAR(100) NOT NULL,
parent_id BIGINT DEFAULT 0,
ancestors VARCHAR(500),
leader_id BIGINT,
sort INTEGER DEFAULT 0,
status INTEGER DEFAULT 1,
phone VARCHAR(20),
email VARCHAR(100),
address VARCHAR(200),
remark VARCHAR(500),
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
create_by BIGINT,
update_by BIGINT,
deleted BOOLEAN DEFAULT FALSE
);
CREATE INDEX idx_dept_code ON sys_department(dept_code);
CREATE INDEX idx_parent_id ON sys_department(parent_id);
```
#### 6.2 操作日志表 (sys_operation_log)
```sql
CREATE TABLE sys_operation_log (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT,
username VARCHAR(50),
real_name VARCHAR(50),
operation_type VARCHAR(50),
operation_module VARCHAR(100),
operation_description VARCHAR(500),
request_method VARCHAR(10),
request_url VARCHAR(500),
request_params TEXT,
request_ip VARCHAR(50),
request_location VARCHAR(100),
user_agent VARCHAR(500),
execute_time BIGINT,
status INTEGER DEFAULT 1,
error_message TEXT,
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_user_time ON sys_operation_log(user_id, create_time);
CREATE INDEX idx_module_time ON sys_operation_log(operation_module, create_time);
```
## 数据库优化策略
### 1. 索引优化
- 为所有外键字段创建索引
- 为频繁查询的组合字段创建复合索引
- 为时间范围查询字段创建索引
### 2. 分区策略
- 按时间分区：操作日志、考勤记录等时间序列数据
- 按业务分区：不同租户的数据分离
### 3. 读写分离
- 主库：写操作和实时读操作
- 从库：报表查询、数据分析等非实时读操作
### 4. 缓存策略
- Redis缓存热点数据：用户信息、权限信息、配置信息
- 缓存查询结果：复杂查询结果缓存5-30分钟
- 分布式会话：用户会话信息存储在Redis中
### 5. 数据归档
- 历史数据归档到冷存储
- 定期清理过期数据
- 数据备份和恢复策略
## 数据库初始化脚本
系统启动时会自动执行以下初始化：
1. 创建数据库和用户
2. 创建表结构和索引
3. 插入基础数据（系统角色、权限、管理员用户）
4. 创建数据库函数和触发器
## 数据迁移策略
1. 使用Flyway进行数据库版本管理
2. 支持回滚操作
3. 数据迁移前备份
4. 灰度发布，逐步迁移
## 监控和告警
1. 数据库连接池监控
2. 慢查询监控和优化
3. 死锁检测和解决
4. 空间使用监控
5. 备份状态监控
---
*文档版本: v1.0*
*最后更新: 2026-01-27*
*作者: 数据库设计团队*

908
plans/project_requirements_document.md Normal file
View File

@@ -0,0 +1,908 @@
# 智能办公管理系统 - 项目需求文档
## 文档信息
| 项目 | 说明 |
|------|------|
| **文档版本** | v1.0 |
| **最后更新** | 2026-01-28 |
| **作者** | 架构设计团队 |
| **审核状态** | 待审核 |
| **适用范围** | 项目重新开发技术规范 |
---
## 1. 项目概述
### 1.1 项目背景与目标
**项目背景：**
随着企业数字化转型的加速，传统办公管理方式已无法满足现代企业的需求。现有办公系统存在以下问题：
1. 功能分散，系统间数据孤岛严重
2. 用户体验差，操作复杂
3. 扩展性不足，难以适应业务变化
4. 安全性薄弱，存在数据泄露风险
**项目目标：**
1. 构建统一、智能的办公管理平台
2. 实现业务流程数字化、自动化
3. 提升员工工作效率和协作体验
4. 保障企业数据安全和合规性
5. 支持灵活扩展和定制化需求
### 1.2 项目范围
**包含范围：**
- 用户认证与权限管理
- 考勤管理（打卡、请假、加班）
- 审批流程管理
- 用户与组织架构管理
- 文档协作（基础功能）
- 即时通讯（基础功能）
- 通知服务
- 系统监控与运维
**排除范围：**
- 财务报销系统（二期规划）
- 项目管理模块（二期规划）
- 客户关系管理（三期规划）
- 移动端原生应用（后续开发）
### 1.3 目标用户群体
| 用户角色 | 主要需求 | 使用频率 |
|----------|----------|----------|
| **普通员工** | 日常打卡、请假申请、查看通知、文档协作 | 每日多次 |
| **部门经理** | 审批申请、查看团队考勤、管理文档权限 | 每日多次 |
| **HR管理员** | 用户管理、考勤统计、权限配置 | 每日使用 |
| **系统管理员** | 系统配置、监控告警、数据备份 | 定期使用 |
| **企业领导** | 数据报表、审批决策、系统概览 | 定期查看 |
### 1.4 核心价值主张
1. **一体化平台**：整合多个办公场景，消除系统孤岛
2. **智能自动化**：基于规则的自动审批、智能考勤统计
3. **安全可靠**：企业级安全防护，数据加密存储
4. **移动友好**：响应式设计，支持多端访问
5. **开放扩展**：微服务架构，支持快速功能扩展
### 1.5 实施阶段与交付边界（本仓库版本）
为保证可落地交付，本仓库的 **v1.0（MVP）** 采用“可运行的单体应用 + 前后端分离”的方式实现核心流程，微服务架构作为后续演进方向。
**v1.0 必须交付的模块：**
- 认证与权限：用户名/密码登录、JWT、角色分级（员工/经理/管理员）
- 用户管理：用户新增、查询、状态管理（启用/禁用/锁定）
- 考勤管理：手动打卡（上班/下班）、个人考勤记录
- 请假审批：请假申请、经理/管理员审批、审批记录
- 通知服务：站内通知（审批结果通知）
**v1.0 明确不交付（规划至二期及以后）：**
- 文档协作、即时通讯、外部消息渠道（短信/邮件/企业微信）
- 地理围栏/人脸识别打卡、流程设计器、复杂规则引擎
- 多租户、微服务拆分、分布式事务、日志与监控平台全量接入
**说明：**
- 本期目标是“可部署、可演示、流程闭环”，与后续微服务化不冲突。
- 若项目进入二期，将根据稳定版本逐步拆分服务与引入基础设施。
---
## 2. 功能需求
### 2.1 用户认证与权限管理模块
#### 2.1.1 功能描述
- 用户注册、登录、登出
- 密码管理（修改、重置、找回）
- 多因素认证支持
- JWT令牌管理（签发、刷新、验证）
- 基于角色的访问控制（RBAC）
- 权限细粒度控制
#### 2.1.2 验收标准
- v1.0 默认支持用户名/密码登录；手机号/邮箱登录作为二期扩展
- 登录失败5次后账户锁定30分钟
- JWT令牌有效期可配置（默认24小时）
- v1.0 先实现角色级权限控制，权限继承与组合为后续增强
- 提供完整的权限审计日志
#### 2.1.3 技术实现建议
- 使用Spring Security 6 + JWT
- Redis存储会话和令牌黑名单
- 密码使用BCrypt加密存储
- 集成验证码防暴力破解
### 2.2 考勤管理模块
#### 2.2.1 功能描述
- 上下班打卡（支持地理位置、WiFi验证）
- 请假申请与审批
- 加班申请与审批
- 考勤规则配置（工作时间、迟到早退阈值）
- 考勤统计与报表
- 异常考勤提醒
#### 2.2.2 验收标准
- v1.0 支持手动打卡与可选的地点描述；位置/WiFi打卡为二期
- 请假类型支持：年假、病假、事假、婚假、产假、丧假
- 加班补偿方式：调休、加班费
- 考勤报表支持按日、周、月、季度、年统计
- 异常考勤自动发送通知
#### 2.2.3 技术实现建议
- 使用地理围栏技术验证打卡位置
- 集成人脸识别（可选）
- 考勤规则引擎支持复杂规则
- 使用Quartz调度器处理定时统计任务
### 2.3 审批流程模块
#### 2.3.1 功能描述
- 工作流定义与配置
- 审批流程实例化
- 多级审批（串行、并行、会签）
- 审批节点配置（审批人、抄送人）
- 审批历史记录
- 流程监控与统计
#### 2.3.2 验收标准
- v1.0 支持固定审批流程（员工 → 经理/管理员），不提供可视化设计器
- 审批节点条件分支、超时自动处理、流程版本管理在二期实现
- v1.0 提供审批记录列表与状态变更时间
#### 2.3.3 技术实现建议
- 集成Flowable工作流引擎
- 使用BPMN 2.0标准定义流程
- 支持动态审批人指定（角色、部门、特定人员）
- 审批数据与业务数据分离存储
### 2.4 用户管理模块
#### 2.4.1 功能描述
- 用户信息管理（增删改查）
- 组织架构管理（部门、岗位）
- 角色与权限管理
- 用户导入导出
- 用户状态管理（启用、禁用、锁定）
#### 2.4.2 验收标准
- 支持批量用户导入（Excel模板）
- 组织架构支持树形结构
- 角色权限支持细粒度控制
- 用户操作记录完整审计
- 支持用户数据脱敏导出
#### 2.4.3 技术实现建议
- 使用部门表实现组织树
- 权限表支持菜单权限和API权限
- 集成LDAP/AD域认证（可选）
- 用户数据分页查询和条件过滤
### 2.5 文档协作模块（待实现）
#### 2.5.1 功能描述
- 文档创建、编辑、删除
- 版本控制与历史记录
- 文档权限管理（查看、编辑、评论、分享）
- 在线协同编辑
- 文档模板管理
- 文档搜索与分类
#### 2.5.2 验收标准
- 支持Markdown、富文本编辑
- 文档版本可回滚
- 协同编辑实时同步
- 文档权限支持继承
- 全文搜索支持关键词高亮
#### 2.5.3 技术实现建议
- 使用MongoDB存储文档内容
- 集成Operational Transformation算法实现协同编辑
- 使用Elasticsearch实现全文搜索
- 文档版本使用增量存储
### 2.6 即时通讯模块（待实现）
#### 2.6.1 功能描述
- 一对一聊天
- 群组聊天
- 文件传输
- 消息状态（已发送、已送达、已读）
- 聊天记录查询
- 消息撤回、删除
#### 2.6.2 验收标准
- 消息实时推送延迟<1秒
- 支持文本、图片、文件、表情消息
- 聊天记录支持分页查询
- 群组管理（创建、解散、成员管理）
- 消息加密传输
#### 2.6.3 技术实现建议
- 使用WebSocket + STOMP协议
- Redis Pub/Sub实现消息广播
- 消息使用AES加密
- 大文件使用分片上传
### 2.7 通知服务模块（基础实现）
#### 2.7.1 功能描述
- 系统通知（公告、提醒）
- 业务通知（审批结果、考勤异常）
- v1.0 仅提供站内通知；外部渠道推送为二期
- 通知模板管理（二期）
- 通知记录与统计（基础）
#### 2.7.2 验收标准
- v1.0 支持即时发送站内通知、已读状态与统计
- 定时通知、优先级、用户偏好、去重合并为二期
#### 2.7.3 技术实现建议
- 使用消息队列（RabbitMQ）解耦
- 集成多个推送渠道SDK
- 通知模板支持变量替换
- 使用线程池处理批量发送
---
## 3. 非功能需求
### 3.1 性能需求
| 指标 | 要求 | 说明 |
|------|------|------|
| **响应时间** | API P95 < 200ms | 95%的API请求响应时间在200ms内 |
| **并发用户** | 支持1000+同时在线 | 系统应支持1000个用户同时在线操作 |
| **吞吐量** | 1000 TPS | 核心接口支持每秒1000个事务处理 |
| **数据量** | 支持百万级用户数据 | 用户表、考勤记录表支持百万级数据量 |
| **页面加载** | 首屏加载 < 3秒 | 前端页面首屏加载时间不超过3秒 |
> 注：以上为生产目标值；v1.0 本地演示环境以功能正确与可用性为优先。
### 3.2 安全性需求
1. **认证安全**
- 密码强度策略（最小长度8位，包含大小写字母和数字）
- 登录失败锁定机制
- 会话超时自动退出
- 防止暴力破解
2. **数据安全**
- 敏感数据加密存储（密码、手机号、身份证号）
- 数据传输使用HTTPS
- 数据库访问权限最小化
- 定期安全漏洞扫描
3. **权限安全**
- 基于角色的访问控制
- 接口级别权限验证
- 防止越权访问
- 操作日志完整记录
4. **审计安全**
- 所有关键操作记录审计日志
- 日志不可篡改
- 支持日志查询和导出
- 符合等保2.0三级要求
### 3.3 可用性需求
1. **系统可用性**
- 生产环境可用性 ≥ 99.9%
- 支持7×24小时不间断运行
- 计划内维护提前通知
2. **容错能力**
- 单点故障不影响核心功能
- 数据库故障自动切换
- 服务异常自动重启
- 数据一致性保证
3. **灾难恢复**
- RTO（恢复时间目标）≤ 4小时
- RPO（恢复点目标）≤ 1小时
- 定期灾难恢复演练
### 3.4 可维护性需求
1. **代码质量**
- 代码规范遵循阿里巴巴Java开发手册
- 单元测试覆盖率 ≥ 80%
- 集成测试覆盖核心业务流程
- 代码审查流程规范化
2. **文档完整性**
- API文档自动生成（OpenAPI 3.0）
- 数据库设计文档完整
- 部署运维手册详细
- 用户操作手册齐全
3. **监控告警**
- 应用性能监控（APM）
- 业务指标监控
- 异常告警及时通知
- 日志集中收集和分析
### 3.5 可扩展性需求
1. **架构扩展性**
- 微服务架构支持水平扩展
- 数据库支持读写分离
- 缓存支持集群部署
- 消息队列支持横向扩展
2. **功能扩展性**
- 模块化设计，支持插件式开发
- API版本管理，支持平滑升级
- 配置中心支持动态配置
- 支持第三方系统集成
3. **数据扩展性**
- 数据库支持分库分表
- 大数据量支持数据归档
- 支持多种数据源接入
- 数据迁移工具完善
---
## 4. 技术架构需求
### 4.1 系统架构设计
#### 4.1.1 整体架构
系统目标采用微服务架构，前后端分离设计；**v1.0 采用单体应用承载核心模块**，后续再拆分为微服务。整体分为以下层次：
1. **客户端层**：Web浏览器、移动端H5、桌面应用
2. **接入层**：Nginx反向代理、API网关、负载均衡
3. **应用服务层**：多个微服务（认证、用户、考勤、审批等）
4. **数据存储层**：关系数据库、NoSQL数据库、缓存、消息队列
5. **基础设施层**：容器平台、监控告警、日志收集
#### 4.1.2 架构图
```mermaid
graph TB
subgraph "客户端层"
Web[Web浏览器]
Mobile[移动端H5]
Desktop[桌面应用]
end
subgraph "接入层"
Nginx[Nginx反向代理]
Gateway[API网关]
LB[负载均衡器]
end
subgraph "应用服务层"
Auth[认证服务]
User[用户服务]
Attendance[考勤服务]
Approval[审批服务]
Document[文档服务]
Chat[聊天服务]
Notification[通知服务]
Common[公共服务]
end
subgraph "数据存储层"
MySQL[(MySQL)]
MongoDB[(MongoDB)]
Redis[(Redis)]
RabbitMQ[(RabbitMQ)]
ES[(Elasticsearch)]
end
subgraph "基础设施层"
Docker[Docker容器]
K8s[Kubernetes]
Monitor[监控告警]
Log[日志收集]
end
Web --> Nginx
Mobile --> Nginx
Desktop --> Nginx
Nginx --> Gateway
Gateway --> Auth
Gateway --> User
Gateway --> Attendance
Gateway --> Approval
Gateway --> Document
Gateway --> Chat
Gateway --> Notification
Auth --> MySQL
User --> MySQL
Attendance --> MySQL
Approval --> MySQL
Document --> MongoDB
Chat --> Redis
Chat --> RabbitMQ
Notification --> RabbitMQ
Common --> ES
Monitor --> Auth
Monitor --> User
Log --> Auth
Log --> User
```
### 4.2 技术栈选择
#### 4.2.1 后端技术栈
- **开发框架**：Spring Boot 3.2.x + Spring Cloud 2023.x
- **安全框架**：Spring Security 6 + JWT
- **数据库**：
- 关系数据库：MySQL 8.0（主业务数据）
- v1.0 本地演示可使用H2内存模式以降低部署复杂度
- NoSQL数据库：MongoDB 7.0（文档、聊天记录）
- 缓存：Redis 7.0（会话、热点数据）
- 搜索：Elasticsearch 8.0（全文搜索、日志）
- **消息队列**：RabbitMQ 3.12（异步处理、解耦）
- **API文档**：SpringDoc OpenAPI 3
- **服务注册发现**：Nacos 2.3 / Eureka
- **配置中心**：Nacos Config
- **分布式事务**：Seata 1.7
- **监控**：Spring Boot Actuator + Prometheus + Grafana
- **测试**：JUnit 5 + Mockito + Testcontainers
#### 4.2.2 前端技术栈
- **框架**：React 18 + TypeScript 5.x
- **UI库**：Ant Design Pro 7.x
- **状态管理**：Redux Toolkit + RTK Query
- **路由**：React Router 6
- **构建工具**：Vite 5
- **图表**：ECharts 5
- **实时通信**：Socket.IO Client
- **代码规范**：ESLint + Prettier + Husky
#### 4.2.3 基础设施
- **容器化**：Docker 24.x + Docker Compose
- **编排**：Kubernetes 1.28（生产环境）
- **CI/CD**：GitHub Actions / Jenkins
- **代码仓库**：Git + GitHub
- **镜像仓库**：Harbor / Docker Hub
- **日志收集**：ELK Stack（Elasticsearch, Logstash, Kibana）
- **监控告警**：Prometheus + AlertManager + Grafana
- **对象存储**：MinIO（兼容S3协议）
### 4.3 数据库设计
#### 4.3.1 数据库选型策略
- **MySQL**：核心业务数据，需要事务支持的表
- **MongoDB**：非结构化数据，文档内容，聊天记录
- **Redis**：缓存、会话、分布式锁、消息队列
- **Elasticsearch**：日志、搜索、分析
#### 4.3.2 数据库分库分表策略
1. **垂直分库**：按业务模块分库
- `smart_office_auth`：认证授权相关表
- `smart_office_attendance`：考勤相关表
- `smart_office_approval`：审批相关表
- `smart_office_user`：用户组织相关表
2. **水平分表**：大数据量表按时间或用户ID分表
- 考勤记录表按月份分表
- 操作日志表按季度分表
- 消息记录表按用户ID哈希分表
#### 4.3.3 数据库优化策略
- 为所有外键字段创建索引
- 为频繁查询的组合字段创建复合索引
- 为时间范围查询字段创建索引
- 使用数据库连接池（HikariCP）
- 定期执行慢查询分析和优化
- 使用读写分离提升读性能
### 4.4 部署架构
#### 4.4.1 环境规划
1. **开发环境**：本地Docker Compose部署，便于开发调试
2. **测试环境**：Kubernetes集群，模拟生产环境
3. **预发布环境**：与生产环境配置一致，用于最终测试
4. **生产环境**：多可用区高可用部署，保障业务连续性
#### 4.4.2 部署模式
- **容器化部署**：所有服务打包为Docker镜像
- **服务网格**：使用Istio进行服务治理（可选）
- **自动扩缩容**：基于CPU/内存使用率自动扩缩容
- **蓝绿部署**：支持零停机部署和回滚
- **金丝雀发布**：逐步将流量切换到新版本
#### 4.4.3 高可用设计
- 每个服务至少部署2个实例
- 数据库主从复制+自动故障转移
- Redis集群模式，数据分片存储
- 负载均衡器健康检查
- 多可用区部署，避免单点故障
---
## 5. 接口需求
### 5.1 内部服务接口
#### 5.1.1 服务间通信协议
- **同步调用**：使用OpenFeign + LoadBalancer
- **异步通信**：使用RabbitMQ消息队列
- **实时通信**：使用WebSocket + STOMP
- **文件传输**：使用MinIO对象存储
#### 5.1.2 服务发现与注册
- 所有微服务向Nacos注册中心注册
- 服务消费者通过服务名调用
- 支持服务健康检查
- 服务下线自动通知
#### 5.1.3 服务熔断与降级
- 使用Resilience4j实现熔断器
- 服务调用超时自动熔断
- 降级策略：返回默认值或缓存数据
- 熔断器状态监控
### 5.2 外部系统接口
#### 5.2.1 第三方认证集成
- 企业微信/钉钉单点登录
- LDAP/AD域认证
- OAuth 2.0第三方登录
- 短信验证码服务
#### 5.2.2 消息推送接口
- 企业微信机器人
- 钉钉工作通知
- 邮件SMTP服务
- 短信网关接口
#### 5.2.3 文件存储接口
- 阿里云OSS
- 腾讯云COS
- 七牛云存储
- 本地MinIO
### 5.3 API设计规范
#### 5.3.1 RESTful API设计原则
1. **资源导向**：使用名词表示资源，动词表示操作
2. **HTTP方法**：
- GET：获取资源
- POST：创建资源
- PUT：更新完整资源
- PATCH：部分更新资源
- DELETE：删除资源
3. **版本管理**：URL路径包含版本号 `/api/v1/users`
4. **状态码**：正确使用HTTP状态码
5. **错误处理**：统一错误响应格式
#### 5.3.2 API响应格式
```json
{
"code": 200,
"message": "操作成功",
"data": {
"id": 1,
"username": "admin"
},
"timestamp": "2026-01-28T08:38:44.921Z"
}
```
#### 5.3.3 API安全规范
1. **认证**：所有API需要JWT令牌认证（除登录注册接口）
2. **授权**：接口级别权限验证
3. **限流**：接口访问频率限制
4. **防重放**：请求签名和时间戳验证
5. **参数校验**：输入参数严格校验
#### 5.3.4 API文档规范
- 使用OpenAPI 3.0规范
- 接口文档自动生成
- 提供在线测试功能
- 版本变更记录清晰
---
## 6. 数据需求
### 6.1 数据模型设计
#### 6.1.1 核心实体关系
1. **用户体系**：用户 ↔ 角色 ↔ 权限 ↔ 部门
2. **考勤体系**：用户 ↔ 考勤记录 ↔ 请假申请 ↔ 加班申请
3. **审批体系**：工作流定义 ↔ 工作流实例 ↔ 审批节点
4. **文档体系**：文档 ↔ 文档版本 ↔ 协作记录
5. **通讯体系**：聊天室 ↔ 消息 ↔ 参与者
#### 6.1.2 数据一致性要求
1. **强一致性**：用户账户、权限数据需要强一致性
2. **最终一致性**：统计报表、通知消息可以最终一致性
3. **事务边界**：跨服务事务使用分布式事务解决方案
4. **数据同步**：主从数据库数据同步延迟 < 1秒
### 6.2 数据存储策略
#### 6.2.1 数据分类存储
- **热数据**：用户会话、权限信息 → Redis缓存
- **温数据**：近期考勤记录、审批记录 → MySQL
- **冷数据**：历史日志、归档数据 → 对象存储/归档数据库
- **分析数据**：统计报表、分析结果 → Elasticsearch
#### 6.2.2 数据生命周期管理
1. **实时数据**（0-30天）：在线访问，高性能存储
2. **近期数据**（30-180天）：在线访问，标准存储
3. **历史数据**（180-365天）：离线访问，归档存储
4. **归档数据**（365天以上）：只读访问，低成本存储
#### 6.2.3 数据备份策略
- **全量备份**：每周一次，保留4周
- **增量备份**：每天一次，保留30天
- **日志备份**：每小时一次，保留7天
- **异地备份**：每月一次，保留12个月
### 6.3 数据安全要求
#### 6.3.1 数据加密
- **传输加密**：所有数据传输使用TLS 1.3
- **存储加密**：敏感数据加密存储（AES-256）
- **密钥管理**：使用KMS管理加密密钥
- **密码存储**：使用BCrypt加盐哈希
#### 6.3.2 数据脱敏
- **显示脱敏**：前端显示时脱敏（手机号、身份证号）
- **查询脱敏**：非授权用户查询时自动脱敏
- **导出脱敏**：数据导出时根据权限脱敏
- **日志脱敏**：日志中不记录敏感信息
#### 6.3.3 数据访问控制
- **行级权限**：用户只能访问自己有权限的数据
- **字段级权限**：敏感字段根据角色控制访问
- **操作审计**：所有数据访问操作记录审计日志
- **数据血缘**：记录数据来源和变更历史
#### 6.3.4 数据合规性
- **个人信息保护**：符合《个人信息保护法》要求
- **数据出境**：敏感数据不出境
- **数据留存**：按照法规要求保留数据
- **数据删除**：支持用户数据彻底删除
---
## 7. 部署与运维需求
### 7.1 部署环境
#### 7.1.1 硬件要求
| 环境 | CPU | 内存 | 存储 | 网络 |
|------|-----|------|------|------|
| **开发环境** | 4核 | 8GB | 100GB | 100Mbps |
| **测试环境** | 8核 | 16GB | 200GB | 1Gbps |
| **生产环境** | 16核 | 32GB | 500GB | 10Gbps |
#### 7.1.2 软件要求
- **操作系统**：Ubuntu 22.04 LTS / CentOS 8
- **容器运行时**：Docker 24.x / containerd
- **容器编排**：Kubernetes 1.28+
- **Java环境**：OpenJDK 17
- **Node.js环境**：Node.js 18 LTS
- **数据库**：MySQL 8.0, MongoDB 7.0, Redis 7.0
#### 7.1.3 网络要求
- **域名**：至少一个备案域名
- **SSL证书**：有效的SSL证书（Let's Encrypt或商业证书）
- **防火墙**：只开放必要端口（80, 443, 22）
- **CDN**：静态资源使用CDN加速
- **负载均衡**：Nginx或云厂商负载均衡器
### 7.2 监控与告警
#### 7.2.1 监控指标
1. **基础设施监控**
- CPU使用率、内存使用率、磁盘使用率
- 网络流量、连接数、错误率
- 容器状态、Pod状态、节点状态
2. **应用监控**
- JVM内存、GC次数、线程数
- 接口响应时间、QPS、错误率
- 数据库连接数、慢查询、锁等待
- 缓存命中率、消息队列堆积
3. **业务监控**
- 用户活跃数、在线用户数
- 考勤打卡成功率、审批处理时长
- 通知发送成功率、消息送达率
- 系统关键业务流程成功率
#### 7.2.2 告警策略
- **紧急告警**：服务不可用、数据库宕机 → 电话通知
- **重要告警**：性能下降、错误率升高 → 企业微信/钉钉
- **一般告警**：资源使用率高、备份失败 → 邮件通知
- **预警**：趋势异常、容量不足 → 定期报告
#### 7.2.3 监控工具栈
- **指标收集**：Prometheus + node_exporter
- **可视化**：Grafana
- **日志收集**：ELK Stack（Elasticsearch, Logstash, Kibana）
- **链路追踪**：Jaeger / SkyWalking
- **告警管理**：AlertManager
### 7.3 备份与恢复
#### 7.3.1 备份策略
1. **数据库备份**
- 全量备份：每周日02:00执行
- 增量备份：每天02:00执行（除周日）
- 备份保留：全量备份保留4周，增量备份保留30天
- 备份验证：每周验证一次备份可恢复性
2. **文件备份**
- 上传文件：实时同步到备份存储
- 配置文件：版本控制+定期备份
- 日志文件：集中存储+定期归档
3. **配置备份**
- 应用配置：Git版本控制
- 环境变量：配置中心备份
- 密钥证书：专用密钥管理系统
#### 7.3.2 恢复策略
1. **数据恢复**
- 恢复点目标（RPO）：≤ 1小时
- 恢复时间目标（RTO）：≤ 4小时
- 恢复验证：恢复后必须验证数据完整性
2. **服务恢复**
- 服务故障：自动重启或切换到备用实例
- 数据库故障：主从切换或从备份恢复
- 全站故障：从最近备份恢复，优先恢复核心服务
3. **灾难恢复**
- 灾难恢复计划（DRP）文档完整
- 定期灾难恢复演练（每季度一次）
- 异地备份数据可恢复性验证
#### 7.3.3 备份存储
- **本地存储**：NAS或专用备份服务器
- **云存储**：对象存储（兼容S3协议）
- **异地存储**：不同地域的云存储
- **加密存储**：备份数据加密存储
---
## 8. 项目约束与假设
### 8.1 技术约束
#### 8.1.1 开发约束
- 必须使用Java 17+和Spring Boot 3.x框架
- 前端必须使用React + TypeScript
- 数据库必须支持MySQL 8.0+和MongoDB 7.0+
- 必须支持Docker容器化部署
- 必须提供完整的API文档（OpenAPI 3.0）
#### 8.1.2 安全约束
- 所有用户密码必须加密存储（BCrypt）
- 敏感数据传输必须使用HTTPS
- 必须实现基于角色的访问控制（RBAC）
- 必须记录完整的操作审计日志
- 必须通过安全漏洞扫描
#### 8.1.3 性能约束
- API响应时间P95必须 < 200ms
- 系统必须支持1000+并发用户
- 页面首屏加载时间必须 < 3秒
- 数据库查询必须使用索引优化
### 8.2 时间约束
#### 8.2.1 项目里程碑
1. **需求分析与设计阶段**：2周
2. **基础框架搭建阶段**：2周
3. **核心功能开发阶段**：6周
4. **前端界面开发阶段**：4周
5. **集成测试与优化阶段**：2周
6. **部署上线与运维阶段**：1周
#### 8.2.2 关键时间节点
- 项目启动：第1周
- 需求评审完成：第2周
- 架构设计完成：第3周
- 核心功能开发完成：第9周
- 集成测试完成：第11周
- 系统上线：第12周
- 项目验收：第13周
### 8.3 资源约束
#### 8.3.1 人力资源
- **后端开发**：3人（Java开发工程师）
- **前端开发**：2人（React开发工程师）
- **测试工程师**：1人
- **运维工程师**：1人（兼）
- **产品经理**：1人
- **项目经理**：1人（兼）
#### 8.3.2 硬件资源
- **开发环境**：每人一台开发机（16GB内存，512GB SSD）
- **测试环境**：专用服务器或云服务器（8核16GB）
- **生产环境**：云服务器集群或物理服务器集群
#### 8.3.3 软件资源
- **开发工具**：IntelliJ IDEA Ultimate、VS Code
- **版本控制**：Git + GitHub/GitLab
- **项目管理**：Jira/禅道
- **文档管理**：Confluence/语雀
- **沟通工具**：企业微信/钉钉/Slack
### 8.4 假设条件
#### 8.4.1 技术假设
1. 用户网络环境稳定，能够正常访问互联网
2. 用户设备支持现代浏览器（Chrome 90+、Firefox 88+、Safari 14+）
3. 服务器资源充足，能够满足系统运行需求
4. 第三方服务（短信、邮件、存储）稳定可用
5. 团队成员具备相关技术栈的开发经验
#### 8.4.2 业务假设
1. 企业组织架构相对稳定，不会频繁变动
2. 考勤规则相对固定，不会每天变化
3. 审批流程相对规范，不会频繁调整
4. 用户数量在可预测范围内增长
5. 业务需求在项目周期内不会发生重大变更
#### 8.4.3 环境假设
1. 生产环境网络稳定，延迟在可接受范围内
2. 数据库性能满足业务增长需求
3. 监控告警系统能够及时发现问题
4. 备份恢复机制能够保障数据安全
5. 安全防护措施能够抵御常见攻击
---
## 附录
### A. 术语表
| 术语 | 解释 |
|------|------|
| **RBAC** | 基于角色的访问控制（Role-Based Access Control） |
| **JWT** | JSON Web Token，用于身份验证的开放标准 |
| **API网关** | 所有外部请求的统一入口，负责路由、认证、限流等 |
| **微服务** | 将单一应用程序划分成一组小的服务 |
| **容器化** | 将应用程序及其依赖打包到容器中，实现环境一致性 |
| **CI/CD** | 持续集成/持续部署，自动化软件交付流程 |
| **P95响应时间** | 95%的请求响应时间低于该值 |
| **RTO/RPO** | 恢复时间目标/恢复点目标，灾难恢复指标 |
### B. 参考资料
1. 《阿里巴巴Java开发手册》
2. 《微服务架构设计模式》
3. 《Spring Boot实战》
4. 《React设计模式与最佳实践》
5. 《数据库系统概念》
6. 《企业级应用架构设计》
7. 《网络安全法》和《个人信息保护法》
### C. 修订历史
| 版本 | 日期 | 作者 | 说明 |
|------|------|------|------|
| v1.0 | 2026-01-28 | 架构设计团队 | 初始版本创建 |
| v1.1 | 待更新 | 待更新 | 根据评审意见更新 |
---
## 文档审批
| 角色 | 姓名 | 部门 | 审批意见 | 签字 | 日期 |
|------|------|------|----------|------|------|
| 产品经理 | | 产品部 | | | |
| 技术负责人 | | 技术部 | | | |
| 项目经理 | | 项目部 | | | |
| 客户代表 | | 客户方 | | | |
**文档状态**：✅ 已完成
**下一步行动**：组织需求评审会议，确认需求细节和优先级