【案例】用户管理系统设计_系统开发用户管理-CSDN博客

本文链接：https://blog.csdn.net/meanshe/article/details/145249671

1. 引言

1.1 编写目的

本文档旨在详细描述用户管理系统的设计思路、功能模块、关键技术及系统架构，以便项目团队成员了解和遵循系统设计规范，确保项目顺利实施。

1.2 背景

随着互联网技术的不断发展，各类应用系统对用户管理的需求日益增长。为满足业务需求，提高用户体验，我们需要设计一套完善的用户管理系统，用于实现用户注册、登录、权限控制、信息管理等功能。

1.3 定义和缩略词

UMS：User Management System（用户管理系统）
DB：Database（数据库）
API：Application Programming Interface（应用程序编程接口）

2. 总体设计

2.1 系统目标

提供用户注册、登录、注销功能
实现用户权限控制
支持用户信息管理
确保系统安全性和稳定性

2.2 系统架构

用户管理系统采用前后端分离的架构，主要包括以下模块：

前端：负责展示用户界面，与用户进行交互
后端：处理业务逻辑，提供数据接口
数据库：存储用户数据

2.3 技术选型

前端：React/Vue + Ant Design
后端：Spring Boot + MyBatis
数据库：MySQL
缓存：Redis
接口协议：RESTful API

3. 模块设计

3.1 用户注册模块

3.1.1 功能描述

用户注册模块允许新用户创建账号，填写基本信息并设置密码。

3.1.2 处理流程

用户填写注册信息，包括用户名、密码、邮箱等
前端提交注册请求至后端
后端验证注册信息合法性，如用户名是否已存在
后端将注册信息写入数据库
注册成功，返回前端提示信息

3.2 用户登录模块

3.2.1 功能描述

用户登录模块允许用户输入用户名和密码，验证身份后进入系统。

3.2.2 交互过程

用户输入用户名和密码
前端提交登录请求至后端
后端验证用户名和密码
验证通过，生成Token并返回给前端
前端存储Token，用于后续请求

以下是一个使用Mermaid语法的时序图，展示了用户登录时刷新Token和访问Token的完整生命周期过程：

在这个时序图中，我们展示了以下步骤：

用户向客户端发送登录请求，包括用户名和密码。
客户端将登录请求发送到认证服务器。
认证服务器向数据库验证用户信息。
数据库返回用户验证结果。
如果用户验证成功，认证服务器生成访问Token和刷新Token，并将刷新Token存储在数据库中。
认证服务器将访问Token和刷新Token返回给客户端。
客户端通知用户登录成功，并存储访问Token和刷新Token。
用户使用访问Token请求受保护的资源。
客户端向认证服务器发送资源请求，附带访问Token。
认证服务器验证访问Token的有效性。
如果访问Token有效，认证服务器授权访问资源；如果无效或过期，客户端使用刷新Token请求新的访问Token。
认证服务器验证刷新Token的有效性。
如果刷新Token有效，认证服务器生成新的访问Token并返回给客户端；如果无效或过期，提示用户重新登录。

数据

class User {
  +id: int
  +username: string
  +password: string
  +email: string
  +createdAt: datetime
  +updatedAt: datetime
}

状态

3.3 权限控制模块

3.3.1 功能描述

权限控制模块用于实现不同用户角色的权限管理，确保用户只能访问授权范围内的资源。

3.3.2 交互流程

后端根据用户角色配置权限
前端请求资源时，携带Token
后端验证Token，判断用户权限
根据权限返回相应资源或提示无权限

3.4. 用户退出模块

3.4.1 功能描述

用户退出模块允许用户登出系统等。

3.4.2 交互流程

以下是补充了用户退出流程的时序图，展示了如何使refresh_token和access_token均失效：

access_token失效逻辑:
每次请求受保护资源时，都会检查access_token的有效性。
检查Token是否过期。
检查Token是否被撤销。
refresh_token失效逻辑:
用户退出登录时，将refresh_token标记为已撤销。
当尝试使用refresh_token获取新的access_token时，会检查其有效性。
退出登录时使token失效:
当用户请求退出登录时，撤销其刷新token，同时，撤销所有关联的访问token。

4. 性能

为了提高性能，尤其是在处理访问令牌（access_token）和刷新令牌（refresh_token）时，以下是一些关键的性能设计考虑：

4.1. 使用高效的数据存储

选择合适的数据库：使用能够快速读写操作的数据库，例如NoSQL数据库（如Redis、MongoDB）或高度优化的关系型数据库（如PostgreSQL）。
索引优化：确保数据库表上有适当的索引，特别是对于经常查询的字段，如令牌ID、用户ID和过期时间。

4.2. 缓存机制

令牌缓存：将频繁访问的令牌信息缓存到内存中，减少数据库访问。
缓存失效策略：实施有效的缓存失效策略，确保缓存数据的一致性，例如使用发布/订阅模式来在令牌更新或撤销时通知缓存更新。

4.3. 分布式扩展

负载均衡：使用负载均衡器分散请求到多个服务器实例，提高系统的可用性和响应速度。
服务拆分：将认证服务与其他服务分离，允许独立扩展认证服务。

4.4. 请求频率

对于Web应用，access_token通常设置为1小时。
对于移动应用，access_token可以设置为1-7天，refresh_token可以设置为30-90天。
对于API服务，可以根据API的使用频率和敏感度来设置，通常在1小时到24小时之间。

4.5. 监控和优化

性能监控：实时监控系统的性能指标，如响应时间、吞吐量和错误率。
持续优化：根据监控结果不断优化系统配置和代码。
以下是一个简化的性能设计图：

在这个设计中，负载均衡器负责分发请求，认证服务处理认证逻辑，数据库/缓存存储令牌信息，消息队列用于异步处理令牌的生成和刷新，而令牌生成/刷新服务则负责实际的令牌操作。这样的设计有助于提高系统的性能和可扩展性。

4. 安全设计

4.1 数据加密

用户密码采用SHA256加盐加密存储
敏感信息在传输过程中使用HTTPS加密

4.2 防止SQL注入

使用MyBatis框架，避免直接拼接SQL语句
对输入参数进行校验和过滤

4.3 防止XSS攻击

对用户输入进行HTML转义
设置Content-Security-Policy头部

4.4 限制请求频率

使用Redis实现接口限流，防止恶意攻击

Token设计

在分布式系统中，token通常用于身份验证和授权。以下是一个token生成结构和算法的设计方案：

Token可以由以下几部分组成：

[Header].[Payload].[Signature]

1 Header

Header部分通常包含token的类型和使用的加密算法。

Type：标识token的类型，例如JWT（JSON Web Token）。
Algorithm：签名算法，如HS256（HMAC SHA-256）。

2 Payload

Payload部分包含token的实际数据，称为claims。

iss (Issuer)：签发token的服务器。
sub (Subject)：token的主题，通常是用户的ID。
aud (Audience)：token的接收者，可以是API的URL。
exp (Expiration Time)：token过期时间。
iat (Issued At)：token的签发时间。
nbf (Not Before)：token在此时间之前无效。
jti (JWT ID)：token的唯一标识符。

Signature

Signature部分是对Header和Payload进行签名后的结果，用于验证token的完整性和真实性。

Token生成算法

以下是一个基于JWT的token生成算法：

选择签名算法

选择一个安全的签名算法，如HS256（HMAC SHA-256）。

生成Header

{
  "alg": "HS256",
  "typ": "JWT"
}

将Header部分进行Base64Url编码。

3.3 生成Payload

{
  "iss": "https://example.com",
  "sub": "user123",
  "aud": "https://api.example.com",
  "exp": 1600000000,
  "iat": 1599990000,
  "nbf": 1599990000,
  "jti": "4f1g23a12aa"
}

将Payload部分进行Base64Url编码。

拼接Token

将Header、Payload和Signature拼接起来，形成完整的token。

token = f"{header_base64}.{payload_base64}.{signature_base64}"

5. 数据库设计

5.1. tb_user用户表

用户ID（主键）
用户名
加密后的密码哈希
盐
其他用户信息字段

用户ID采用雪花算法实现，结构为：

[时间戳][机器ID][序列号]

时间戳：使用当前时间的毫秒值，占10位，可以使用约69年。
机器ID：根据机器的IP或其他唯一标识生成，占5位，可以支持32台机器。
序列号：在同一毫秒内自增，占7位，可以支持128个ID。

用户表（Users）

CREATE TABLE Users (
    UserID INT PRIMARY KEY,
    Username VARCHAR(255) NOT NULL,
    -- 其他用户信息
);

角色表（Roles）

CREATE TABLE Roles (
    RoleID INT PRIMARY KEY,
    RoleName VARCHAR(255) NOT NULL
    -- 其他角色信息
);

权限表（Permissions）

CREATE TABLE Permissions (
    PermissionID INT PRIMARY KEY,
    PermissionName VARCHAR(255) NOT NULL,
    -- 其他权限信息
);

用户角色关联表（UserRoles）

CREATE TABLE UserRoles (
    UserID INT,
    RoleID INT,
    FOREIGN KEY (UserID) REFERENCES Users(UserID),
    FOREIGN KEY (RoleID) REFERENCES Roles(RoleID),
    PRIMARY KEY (UserID, RoleID)
);

角色权限关联表（RolePermissions）

CREATE TABLE RolePermissions (
    RoleID INT,
    PermissionID INT,
    FOREIGN KEY (RoleID) REFERENCES Roles(RoleID),
    FOREIGN KEY (PermissionID) REFERENCES Permissions(PermissionID),
    PRIMARY KEY (RoleID, PermissionID)
);

token表

CREATE TABLE AccessTokens (
    AccessTokenID INT AUTO_INCREMENT PRIMARY KEY,
    UserID INT NOT NULL,
    Token VARCHAR(255) NOT NULL,
    ExpiresAt DATETIME NOT NULL,
    CreatedAt DATETIME NOT NULL,
    Revoked BOOLEAN NOT NULL DEFAULT FALSE,
    FOREIGN KEY (UserID) REFERENCES Users(UserID) -- 假设有一个Users表
);