LoadUp Framework - 项目规划与路线图¶

版本: 0.0.2-SNAPSHOT
更新日期: 2026-02-28
项目定位: 企业级应用开发框架
发展策略: 巨石应用优先，保留分布式能力扩展
核心理念: 先把单体应用做到极致，再考虑分布式拆分

📋 目录¶

1. 项目现状分析
2. 架构优势与不足
3. 发展路线图
4. 后续优化方向
5. 通用业务模块规划
6. 技术演进路线

1. 项目现状分析¶

1.1 已完成的核心能力¶

✅ 基础设施层 (Commons)¶

loadup-commons-api: 通用接口定义
loadup-commons-dto: 统一数据传输对象
loadup-commons-util: 工具类库

✅ 技术组件层 (Components) - 15个组件¶

安全能力: - loadup-components-authorization - 轻量级方法级授权框架 - loadup-components-captcha - 验证码生成与验证 - loadup-components-signature - 数字签名和摘要计算

数据能力: - loadup-components-database - 数据库访问和工具 - loadup-components-cache - 缓存抽象 (Caffeine/Redis) - loadup-components-dfs - 分布式文件存储 (Local/S3/Database) - loadup-components-flyway - 数据库版本管理

业务能力: - loadup-components-gotone - 统一消息通知 (Email/SMS/Push/Webhook) - loadup-components-retrytask - 分布式重试任务框架 - loadup-components-globalunique - 全局幂等性控制 - loadup-components-scheduler - 任务调度 (Quartz/XXL-Job/PowerJob)

工程能力: - loadup-components-extension - 插件化扩展框架 - loadup-components-tracer - 分布式链路追踪 - loadup-components-testcontainers - 测试容器支持

✅ 中间件层 (Middleware)¶

loadup-gateway: 自研轻量级 API 网关
基于 Spring MVC (非 WebFlux)
Action 责任链模式
支持多种认证策略 (JWT/签名/自定义)
集成链路追踪
统一异常处理和响应封装
loadup-testify: 测试框架

✅ 业务模块层 (Modules)¶

loadup-modules-upms: 用户权限管理系统
RBAC3 权限模型 (角色继承、职责分离、数据权限)
组织架构管理 (无限层级部门树)
多种登录方式 (用户名/邮箱/手机)
OAuth 2.0 第三方登录 (微信/QQ/GitHub/Google等9种渠道)
操作审计和登录日志

1.2 技术栈选型¶

分类	技术	版本	评估	优先级
核心框架	Spring Boot	3.4.3	✅ 最新稳定版	P0
编程语言	Java	21	✅ LTS版本，虚拟线程支持	P0
ORM框架	MyBatis-Flex	1.11.5	✅ 类型安全，性能优秀	P0
数据库	MySQL	8.0+	✅ 主流选择	P0
缓存	Redis (Redisson)	-	✅ 已集成	P0
API网关	自研 Gateway	-	✅ 轻量级，满足单体需求	P0
链路追踪	OpenTelemetry	1.57.0	✅ 已集成	P1
任务调度	Quartz/XXL-Job	-	✅ 多种选择	P1
消息队列	-	-	⏸️ 暂缓，保留扩展能力	P3
服务注册	-	-	⏸️ 分布式阶段再考虑	P3
配置中心	-	-	⏸️ 分布式阶段再考虑	P3
RPC框架	Dubbo	3.2.8	⏸️ 已集成但暂不使用	P3

1.3 代码质量保障¶

工具	配置	状态
代码格式化	Spotless (Palantir Java Format)	✅ 已配置，CI 强制检查
单元测试	JUnit 5 + Mockito + AssertJ	✅ 已配置
集成测试	Testcontainers	✅ 已配置
代码覆盖率	JaCoCo	✅ 已配置
静态代码分析	SpotBugs + FindSecBugs	✅ 已配置，CI 强制检查
代码规范检查	PMD + Checkstyle	✅ 已配置，CI 强制检查
架构约束检查	ArchUnit	✅ 已配置，覆盖分层依赖/循环依赖/命名规范
安全漏洞扫描	OWASP Dependency-Check	✅ 已配置，main/develop 分支触发
License检查	License Maven Plugin	✅ 已配置
依赖管理	Maven BOM	✅ 已配置
API文档	OpenAPI/Swagger	✅ 已集成

2. 架构优势与不足¶

2.1 核心优势 💪¶

清晰的分层架构
严格的单向依赖规则
模块职责明确，边界清晰
符合 DDD 分层思想
高度模块化
15个独立可复用组件
插件化扩展机制
组件间松耦合
企业级最佳实践
统一异常处理
统一响应格式
完善的审计日志
安全机制完备
开发效率高
自动配置优先
丰富的工具类
完善的文档
测试友好
Testcontainers 集成测试
高代码覆盖率要求
分离单元测试和集成测试

2.2 当前不足与待改进 🔧¶

核心能力层面 (高优先级)¶

基础能力建设不完善 🔴
❌ 缺少统一配置管理模块
❌ 缺少集中日志管理
❌ 缺少系统监控和告警
❌ 测试覆盖率不足 (当前约40%)
❌ 性能基准测试缺失
代码质量保障不足 🔴
⚠️ 静态代码分析未集成
⚠️ 架构约束检查缺失
⚠️ 代码规范自动化程度低
❌ 安全漏洞扫描未配置
业务模块单一 🟠
✅ 只有 UPMS 一个业务模块
❌ 缺少其他通用业务模块 (Config/Log/Notification等)
❌ 缺少业务模块间协作示例
性能优化空间大 🟠
❌ 缺少数据库连接池优化
❌ 缺少查询性能监控
❌ 缺少缓存策略优化
❌ 批量操作未充分利用
开发体验待提升 🟡
❌ 缺少代码生成器
❌ 缺少开发者工具
⚠️ API文档需要完善
❌ 缺少最佳实践示例

分布式能力层面 (低优先级，保留扩展)¶

微服务能力 🟢 (P3)
暂不需要：服务注册与发现
暂不需要：配置中心
暂不需要：服务网格
保留扩展：Dubbo已集成但暂不使用
消息驱动能力 🟢 (P3)
暂不需要：消息队列
暂不需要：事件驱动架构
暂不需要：分布式事务
可替代：使用本地事件机制

DevOps 能力层面 (中优先级)¶

DevOps 能力 🟡 (P2)
❌ 缺少 CI/CD 配置
❌ 缺少 Docker 镜像构建优化
⚠️ 只有基本的 Dockerfile
❌ 缺少自动化部署脚本

3. 发展路线图¶

3.1 短期目标 (1-3个月) - v0.1.0¶

主题: 基础能力建设 + 质量提升 + 核心业务模块

阶段一：质量保障体系建设 (3周) 🔴 P0¶

Week 1: 测试框架完善 - [ ] 提升单元测试覆盖率到 80% - [ ] 完善集成测试用例 - [ ] 引入 Mutation Testing (PIT) - [ ] 配置 JaCoCo 覆盖率门禁

Week 2: 代码质量工具集成 - [ ] 集成 SonarQube 静态代码分析 - [ ] 集成 ArchUnit 架构约束检查 - [ ] 优化 Spotless 代码格式化规则 - [ ] 配置 OWASP Dependency Check

Week 3: CI/CD 自动化 - [ ] GitHub Actions CI 配置 - [ ] 自动化测试流水线 - [ ] 代码质量自动检查 - [ ] Docker 镜像自动构建

阶段二：基础设施完善 (4周) 🔴 P0¶

Week 4-5: 可观测性建设 - [ ] 完善 OpenTelemetry 链路追踪 - [ ] 集成 Prometheus + Grafana 监控 - [ ] 统一日志格式 (JSON) - [ ] 实现应用健康检查端点

Week 6: 配置管理模块 - [ ] 开发 Config 配置管理模块 - [ ] 系统参数管理 - [ ] 数据字典管理 - [ ] 配置热更新机制

Week 7: 日志中心模块 - [ ] 开发 Log 日志中心模块 - [ ] 操作日志自动记录 (AOP) - [ ] 审计日志记录 - [ ] 日志查询和导出

阶段三：性能优化 (2周) 🟠 P1¶

Week 8: 数据库性能优化 - [ ] HikariCP 连接池调优 - [ ] 慢查询监控和优化 - [ ] 索引优化建议 - [ ] 批量操作优化

Week 9: 缓存策略优化 - [ ] 实现多级缓存 (Caffeine + Redis) - [ ] 缓存一致性方案 - [ ] 缓存穿透/击穿防护 - [ ] 缓存预热机制

阶段四：业务模块扩展 (3周) 🟠 P1¶

Week 10: Notification 消息中心 - [ ] 站内消息功能 - [ ] WebSocket 实时推送 - [ ] 消息订阅管理 - [ ] 公告管理

Week 11-12: 安全加固 - [ ] 实现 API 限流 (令牌桶算法) - [ ] IP 黑白名单 - [ ] 防重放攻击 - [ ] 敏感数据脱敏 - [ ] SQL 注入防护

3.2 中期目标 (3-6个月) - v0.5.0¶

主题: 业务模块丰富 + 开发效率提升 + 平台化初探

通用业务模块开发 (见第5章详细规划)¶

核心业务模块 (8周): - [ ] CMS 内容管理模块 - 3周 - 文章管理 (Markdown/富文本) - 分类标签体系 - 媒体资源管理 - 全文搜索 (Elasticsearch 可选)

[ ] Workflow 工作流模块 - 4周
集成 Flowable/Camunda
流程设计器
任务管理
流程监控
[ ] Report 报表中心 - 3周
报表设计器
图表报表 (ECharts)
Excel 导出
定时报表

开发者工具建设 (4周)¶

Week 1-2: 代码生成器 - [ ] CRUD 代码生成 - [ ] 基于模板的代码生成 - [ ] MyBatis-Flex 代码生成增强 - [ ] 前端代码生成 (Vue/React)

Week 3: 开发者工具 - [ ] SQL 审核工具 - [ ] API 测试工具 - [ ] 数据库文档生成 - [ ] ER 图生成

Week 4: 文档完善 - [ ] 完善组件使用文档 - [ ] 编写最佳实践指南 - [ ] 常见问题 FAQ - [ ] 视频教程录制

单体应用性能极致优化 (4周)¶

Week 1: 数据库优化 - [ ] 读写分离 (主从复制) - [ ] 连接池深度优化 - [ ] 慢查询自动优化建议 - [ ] 定期索引优化

Week 2: 缓存架构升级 - [ ] 实现三级缓存架构 - [ ] 缓存预热自动化 - [ ] 热点数据自动识别 - [ ] 缓存监控大盘

Week 3: 异步化改造 - [ ] 全面启用虚拟线程 - [ ] 异步任务框架 - [ ] 事件驱动机制 (本地事件总线) - [ ] 批量任务处理优化

Week 4: 性能基准 - [ ] JMH 性能基准测试 - [ ] 压力测试脚本 - [ ] 性能监控大盘 - [ ] 性能优化报告

3.3 长期目标 (6-12个月) - v1.0.0¶

主题: 平台化建设 + 生态成熟 + 商业化探索

开发者平台建设 (8周)¶

项目脚手架生成器: - [ ] 基于模板的项目初始化 - [ ] 可视化配置界面 - [ ] 组件选择和组合 - [ ] 一键生成项目结构

在线开发工具: - [ ] 在线 SQL 编辑器 - [ ] API Mock 平台 - [ ] 数据库设计工具 - [ ] 接口文档管理

开发者社区: - [ ] 技术博客平台 - [ ] 问答社区 - [ ] 案例分享 - [ ] 插件市场

运维管理平台 (6周)¶

监控大盘: - [ ] 应用性能监控 - [ ] 数据库监控 - [ ] 缓存监控 - [ ] 业务指标监控

配置中心: - [ ] 统一配置管理界面 - [ ] 配置版本管理 - [ ] 配置灰度发布 - [ ] 配置审计

日志平台: - [ ] 集中日志查询 - [ ] 日志分析 - [ ] 告警规则管理 - [ ] 日志导出

低代码平台探索 (8周)¶

可视化建模: - [ ] 数据模型设计器 - [ ] 页面设计器 - [ ] 流程设计器 - [ ] 规则引擎

代码生成: - [ ] 前后端代码生成 - [ ] API 自动生成 - [ ] 文档自动生成 - [ ] 测试用例生成

分布式能力预留 (可选，按需启用)¶

微服务化准备 (仅保留扩展点): - [ ] Dubbo RPC 深度集成文档 - [ ] 服务拆分最佳实践 - [ ] Nacos 集成方案 (文档) - [ ] 服务网格方案调研

消息驱动 (可选): - [ ] RocketMQ 集成组件 (按需) - [ ] 本地事件总线增强 - [ ] 事件溯源模式 - [ ] CQRS 架构模式

注意: 分布式能力仅作为扩展选项保留，默认不启用，仅在业务确实需要时再考虑。

4. 后续优化方向¶

4.1 架构优化¶

1. Gateway 增强 🚀¶

当前问题: - 功能相对简单 - 不支持限流熔断 - 不支持动态路由

优化方向:

Phase 1: 核心功能增强
├─ 实现限流策略 (令牌桶/滑动窗口)
├─ 实现熔断降级 (Hystrix模式)
├─ 实现重试机制
└─ 实现动态路由配置

Phase 2: 高级功能
├─ 灰度发布支持
├─ AB测试路由
├─ 请求聚合 (BFF)
└─ 响应缓存

Phase 3: 可观测性
├─ 实时流量监控
├─ 错误率统计
├─ 响应时间分布
└─ 自定义告警

2. 数据库层优化 💾¶

读写分离:

// loadup-components-database 增强
@Configuration
public class DataSourceConfig {
    @Bean
    public DataSource routingDataSource() {
        // 动态路由数据源
        // 读操作 -> 从库
        // 写操作 -> 主库
    }
}

分库分表:

选择方案:
1. ShardingSphere (推荐)
2. MyBatis-Flex 原生支持
3. 手动分片

实现:
- 创建 loadup-components-sharding 组件
- 支持水平分表
- 支持垂直分库
- 透明化业务代码

多租户支持:

策略:
1. 独立数据库 (隔离性最好)
2. 共享数据库，独立Schema
3. 共享数据库，共享Schema，tenant_id区分

实现:
- TenantContext 租户上下文
- 自动添加 tenant_id 过滤
- 数据权限隔离

3. 缓存策略优化 📦¶

多级缓存:

L1: Caffeine (本地缓存，ms级)
  ↓ Miss
L2: Redis (分布式缓存，10ms级)
  ↓ Miss
L3: Database (持久化，100ms级)

实现:
- 创建 MultiLevelCacheManager
- 缓存同步策略 (Canal/MQ)
- 缓存预热
- 缓存穿透/雪崩/击穿防护

缓存一致性:

// 延迟双删
public void update(User user) {
    cache.delete(key);              // 删除缓存
    database.update(user);          // 更新数据库
    Thread.sleep(500);              // 延迟
    cache.delete(key);              // 再次删除
}

// 订阅 Binlog
canal.subscribe(event -> {
    if (event.isUpdate()) {
        cache.delete(buildKey(event));
    }
});

4.2 性能优化¶

1. 异步化改造 ⚡¶

虚拟线程应用:

spring:
  threads:
    virtual:
      enabled: true  # 启用虚拟线程

# 影响:
# - 每个请求一个虚拟线程
# - 阻塞操作不消耗系统线程
# - 吞吐量提升 10x+

异步编程模式:

// CompletableFuture 异步链
CompletableFuture.supplyAsync(() -> queryUser())
    .thenApplyAsync(user -> enrichUserData(user))
    .thenAcceptAsync(user -> sendNotification(user))
    .exceptionally(ex -> handleError(ex));

// @Async 注解
@Async
public CompletableFuture<User> getUserAsync(String id) {
    return CompletableFuture.completedFuture(userService.getById(id));
}

2. 批量操作优化 📊¶

批量查询:

// 避免 N+1 问题
// Bad
for (Order order : orders) {
    User user = userService.getById(order.getUserId()); // N次查询
}

// Good
Set<String> userIds = orders.stream()
    .map(Order::getUserId)
    .collect(Collectors.toSet());
List<User> users = userService.listByIds(userIds);  // 1次查询
Map<String, User> userMap = users.stream()
    .collect(Collectors.toMap(User::getId, u -> u));

批量写入:

// MyBatis-Flex 批量插入
userMapper.insertBatch(users, 1000);  // 每批1000条

// 优化: 使用 JDBC Batch
jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() {
    @Override
    public void setValues(PreparedStatement ps, int i) {
        // 设置参数
    }
    @Override
    public int getBatchSize() {
        return users.size();
    }
});

3. SQL 优化 🔍¶

慢查询监控:

# application.yml
spring:
  datasource:
    hikari:
      leak-detection-threshold: 60000  # 连接泄漏检测

mybatis-flex:
  configuration:
    log-impl: org.apache.ibatis.logging.slf4j.Slf4jImpl

# Logback 配置慢SQL
<logger name="io.github.loadup" level="DEBUG" />

查询优化:

-- 使用索引
CREATE INDEX idx_user_email ON user(email);
CREATE INDEX idx_user_status_created ON user(status, created_at);

-- 避免 SELECT *
SELECT id, username, email FROM user WHERE status = 1;

-- 分页优化 (深分页)
-- Bad: OFFSET 100000
SELECT * FROM user ORDER BY id LIMIT 100000, 20;

-- Good: 使用上次查询的最大ID
SELECT * FROM user WHERE id > 999980 ORDER BY id LIMIT 20;

4.3 代码质量提升¶

1. 代码规范自动化 ✨¶

增强 Spotless 配置:

<plugin>
    <groupId>com.diffplug.spotless</groupId>
    <artifactId>spotless-maven-plugin</artifactId>
    <configuration>
        <java>
            <!-- Import 顺序 -->
            <importOrder>
                <order>java,javax,org,com,io,</order>
            </importOrder>
            <!-- 移除未使用导入 -->
            <removeUnusedImports/>
            <!-- 自定义格式化规则 -->
            <eclipse>
                <file>${project.basedir}/eclipse-formatter.xml</file>
            </eclipse>
        </java>
    </configuration>
</plugin>

集成 ArchUnit:

// 架构测试
@AnalyzeClasses(packages = "io.github.loadup")
public class ArchitectureTest {

    @ArchTest
    static final ArchRule modules_should_not_depend_on_each_other =
        noClasses()
            .that().resideInAPackage("..modules.upms..")
            .should().dependOnClassesThat()
            .resideInAPackage("..modules.cms..");

    @ArchTest
    static final ArchRule controllers_should_be_in_adapter =
        classes()
            .that().haveSimpleNameEndingWith("Controller")
            .should().resideInAPackage("..adapter..");
}

2. 单元测试增强 🧪¶

测试覆盖率目标:

- 核心业务逻辑: 90%+
- Service 层: 80%+
- Controller 层: 70%+
- Util 工具类: 95%+

Mutation Testing (变异测试):

<plugin>
    <groupId>org.pitest</groupId>
    <artifactId>pitest-maven</artifactId>
    <configuration>
        <targetClasses>
            <param>io.github.loadup.*</param>
        </targetClasses>
        <mutationThreshold>75</mutationThreshold>
    </configuration>
</plugin>

4.4 安全加固 🔒¶

1. API 安全¶

请求签名验证:

// 已有 signature 组件，增强使用
@PostMapping("/api/sensitive")
@RequireSignature(algorithm = "SHA256_WITH_RSA")
public Result operation(@RequestBody @Valid Request req) {
    // 业务逻辑
}

防重放攻击:

@PostMapping("/api/payment")
@PreventReplay(window = 300)  // 5分钟窗口
public Result pay(@RequestBody PaymentRequest req) {
    // timestamp + nonce 验证
}

2. 数据安全¶

敏感数据加密:

// 字段级加密
@EncryptField(algorithm = "AES")
private String idCard;

@EncryptField(algorithm = "SM4")  // 国密
private String bankCard;

数据脱敏:

@JsonSerialize(using = MaskSerializer.class)
@Mask(type = MaskType.PHONE)
private String phone;  // 138****8888

@Mask(type = MaskType.ID_CARD)
private String idCard;  // 110***********1234

5. 通用业务模块规划¶

5.1 优先级排序¶

优先级	模块	业务价值	技术复杂度	预计工期
🔴 P0	Config 配置管理	⭐⭐⭐⭐⭐	⭐⭐	1周
🔴 P0	Log 日志中心	⭐⭐⭐⭐⭐	⭐⭐	1周
🟠 P1	Notification 消息中心	⭐⭐⭐⭐	⭐⭐⭐	2周
🟠 P1	CMS 内容管理	⭐⭐⭐⭐	⭐⭐⭐	3周
🟡 P2	Workflow 工作流	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	4周
🟡 P2	Report 报表中心	⭐⭐⭐	⭐⭐⭐⭐	3周
🟢 P3	Search 搜索服务	⭐⭐⭐	⭐⭐⭐⭐	3周
🟢 P3	Payment 支付中心	⭐⭐⭐	⭐⭐⭐⭐	4周
🟢 P3	Order 订单中心	⭐⭐⭐	⭐⭐⭐⭐	3周

5.2 详细规划¶

5.2.1 Config 配置管理模块 🔴¶

功能范围:

loadup-modules-config/
├─ 系统配置
│  ├─ 系统参数 (key-value)
│  ├─ 业务开关 (feature toggle)
│  └─ 运行时配置
├─ 数据字典
│  ├─ 字典类型管理
│  ├─ 字典项管理
│  └─ 级联字典支持
├─ 配置版本管理
│  ├─ 配置历史
│  ├─ 配置对比
│  └─ 配置回滚
└─ 配置分发
   ├─ 配置推送
   ├─ 配置订阅
   └─ 配置刷新

核心实体:

// 系统配置
ConfigItem {
    String key;           // 配置键
    String value;         // 配置值
    String type;          // 数据类型 (STRING/INT/BOOL/JSON)
    String category;      // 分类
    String description;   // 说明
    Boolean editable;     // 是否可编辑
    Boolean encrypted;    // 是否加密
}

// 数据字典
DictType {
    String code;          // 字典编码
    String name;          // 字典名称
    Integer sort;         // 排序
    Boolean system;       // 是否系统字典
}

DictItem {
    String dictCode;      // 字典编码
    String label;         // 标签
    String value;         // 值
    Integer sort;         // 排序
    String parentValue;   // 父级值(级联)
}

技术实现:

// 配置监听
@Component
public class ConfigChangeListener {
    @EventListener
    public void onConfigChange(ConfigChangeEvent event) {
        // 刷新本地缓存
        // 通知订阅者
    }
}

// 配置客户端
@Configuration
public class AppConfig {
    @ConfigValue("app.max-upload-size")
    private Long maxUploadSize;  // 自动刷新
}

5.2.2 Log 日志中心模块 🔴¶

功能范围:

loadup-modules-log/
├─ 操作日志
│  ├─ 自动记录 (@OperationLog)
│  ├─ 手动记录
│  └─ 异步写入
├─ 访问日志
│  ├─ HTTP 请求日志
│  ├─ RPC 调用日志
│  └─ 性能统计
├─ 审计日志
│  ├─ 敏感操作记录
│  ├─ 数据变更记录
│  └─ 合规审计
└─ 日志查询
   ├─ 多条件检索
   ├─ 全文搜索 (ES)
   └─ 日志导出

核心实体:

Ope              //

href="#__codelineno-24-1">// 操作日志 rationLog { String userId; // 操作人 String module; // 模块 String operation; // 操作类型 (CREATE/UPDATE/DELETE) String description; // 描述 String method; // 方法名 String params; // 请求参数 String result; // 返回结果 Long duration; // 耗时(ms) String ip; // IP地址 String userAgent; // UA LocalDateTime time; // 操作时间 } 审计日志 AuditLog { String userId; String dataType; // 数据类型 String dataId; // 数据ID String action; // 动作 String before; // 变更前(JSON) String after; // 变更后(JSON) String reason; // 变更原因 }

技术实现:

// AOP 自动记录
@Aspect
public class OperationLogAspect {
    @Around("@annotation(OperationLog)")
    public Object around(ProceedingJoinPoint pjp, OperationLog log) {
        // 记录前置信息
        // 执行方法
        // 记录后置信息
        // 异步写入数据库
    }
}

// 审计拦截器
@Component
public class AuditInterceptor extends TableChangeInterceptor {
    @Override
    public void onUpdate(TableChangeEvent event) {
        // 记录数据变更
        auditLogService.save(buildAuditLog(event));
    }
}

5.2.3 Notification 消息中心模块 🟠¶

功能范围:

loadup-modules-notification/
├─ 站内消息
│  ├─ 系统消息
│  ├─ 用户消息
│  └─ 消息分类
├─ 消息订阅
│  ├─ 订阅管理
│  ├─ 订阅规则
│  └─ 推送偏好
├─ 公告管理
│  ├─ 公告发布
│  ├─ 目标用户
│  └─ 公告有效期
└─ 消息推送
   ├─ 实时推送 (WebSocket)
   ├─ 批量推送
   └─ 定时推送

核心实体:

// 消息
Message {
    String title;         // 标题
    String content;       // 内容
    String type;          // 类型 (SYSTEM/USER/NOTICE)
    String level;         // 级别 (INFO/WARNING/ERROR)
    String targetType;    // 目标类型 (USER/ROLE/DEPT/ALL)
    List<String> targets; // 目标列表
    LocalDateTime sentAt; // 发送时间
    LocalDateTime expireAt; // 过期时间
}

// 用户消息
UserMessage {
    String userId;
    String messageId;
    Boolean read;         // 是否已读
    LocalDateTime readAt; // 读取时间
}

// 消息订阅
MessageSubscription {
    String userId;
    String category;      // 订阅分类
    Boolean enabled;      // 是否启用
    Map<String, Object> config; // 推送配置
}

技术实现:

// WebSocket 实时推送
@Component
public class MessagePushService {
    public void pushToUser(String userId, Message msg) {
        WebSocketSession session = sessionManager.getSession(userId);
        if (session != null && session.isOpen()) {
            session.sendMessage(new TextMessage(toJson(msg)));
        } else {
            // 存储离线消息
            messageRepository.save(msg);
        }
    }
}

// 批量推送
public void batchPush(Message msg, List<String> userIds) {
    // 使用虚拟线程并发推送
    userIds.parallelStream().forEach(userId -> {
        pushToUser(userId, msg);
    });
}

5.2.4 CMS 内容管理模块 🟠¶

功能范围:

loadup-modules-cms/
├─ 文章管理
│  ├─ 文章编辑 (Markdown/富文本)
│  ├─ 文章分类
│  ├─ 标签管理
│  └─ 文章状态 (草稿/发布/下架)
├─ 栏目管理
│  ├─ 栏目树
│  ├─ 栏目模板
│  └─ 栏目权限
├─ 媒体管理
│  ├─ 图片上传
│  ├─ 视频上传
│  └─ 附件管理
└─ 内容审核
   ├─ 审核流程
   ├─ 敏感词过滤
   └─ 版权检测

核心实体:

// 文章
Article {
    String title;         // 标题
    String summary;       // 摘要
    String content;       // 内容
    String contentType;   // 内容类型 (MARKDOWN/HTML)
    String categoryId;    // 分类ID
    List<String> tags;    // 标签
    String coverImage;    // 封面图
    String authorId;      // 作者ID
    Integer viewCount;    // 浏览量
    Integer likeCount;    // 点赞数
    String status;        // 状态 (DRAFT/PUBLISHED/ARCHIVED)
    LocalDateTime publishAt; // 发布时间
}

// 分类
Category {
    String name;
    String code;
    String parentId;      // 父分类
    Integer sort;
    String seoKeywords;   // SEO关键词
    String seoDescription;
}

技术实现:

// 全文搜索 (集成 Elasticsearch)
@Service
public class ArticleSearchService {
    public Page<Article> search(String keyword, Pageable pageable) {
        return elasticsearchTemplate.search(
            Query.multiMatch(keyword, "title", "content", "tags"),
            Article.class,
            pageable
        );
    }
}

// 浏览量统计 (异步)
@Async
public void incrementViewCount(String articleId) {
    redisTemplate.opsForValue().increment("article:view:" + articleId);
    // 定时任务批量同步到数据库
}

5.2.5 Workflow 工作流模块 🟡¶

功能范围:

loadup-modules-workflow/
├─ 流程定义
│  ├─ 流程设计器 (BPMN)
│  ├─ 流程模板
│  └─ 流程版本管理
├─ 流程实例
│  ├─ 流程发起
│  ├─ 任务处理
│  ├─ 流程流转
│  └─ 流程撤回
├─ 任务管理
│  ├─ 待办任务
│  ├─ 已办任务
│  ├─ 任务委托
│  └─ 任务转办
└─ 流程监控
   ├─ 流程跟踪
   ├─ 性能分析
   └─ 异常处理

技术选型:

方案一: Flowable (推荐)
- 成熟稳定
- BPMN 2.0标准
- 支持复杂流程

方案二: Camunda
- 轻量级
- 高性能
- 云原生

方案三: Activiti
- 老牌流程引擎
- 社区活跃

核心实体:

// 流程定义
ProcessDefinition {
    String name;
    String key;
    String category;
    String bpmnXml;       // BPMN XML
    Integer version;
    Boolean enabled;
}

// 流程实例
ProcessInstance {
    String definitionId;
    String businessKey;   // 业务键
    String startUserId;
    String currentNode;
    String status;        // RUNNING/COMPLETED/SUSPENDED
    Map<String, Object> variables;
}

// 任务
Task {
    String instanceId;
    String nodeName;
    String assignee;      // 处理人
    LocalDateTime dueDate;
    String status;        // PENDING/COMPLETED
}

5.2.6 其他规划模块¶

Report 报表中心 📊:

- 报表设计器
- SQL/存储过程报表
- 图表报表 (ECharts)
- Excel 导出
- 定时报表
- 报表订阅

Search 搜索服务 🔍:

- Elasticsearch 集成
- 全文检索
- 模糊搜索
- 聚合统计
- 搜索建议
- 热词统计

Payment 支付中心 💰:

- 支付宝/微信支付
- 银行卡支付
- 支付回调
- 退款处理
- 账单查询
- 对账功能

Order 订单中心 🛒:

- 订单创建
- 订单状态机
- 订单拆分
- 订单取消
- 售后处理
- 订单导出

6. 技术演进路线¶

6.1 架构演进（聚焦单体应用优化）¶

阶段一: 基础单体应用 (当前)
Application → Gateway → Modules (UPMS)
                     ↓
              MySQL + Redis

✅ 优点: 架构简单，易于开发和调试
⚠️ 不足: 性能有待优化，缺少监控

阶段二: 优化的单体应用 (3个月内)
Application → Gateway → Modules (UPMS + Config + Log + Notification)
                     ↓
        主从 MySQL (读写分离) + 多级缓存
                     ↓
          Prometheus + Grafana 监控

✅ 优点: 性能提升3-5倍，可观测性强
✅ 适用: 10万+ DAU，覆盖90%企业应用场景

阶段三: 极致性能单体 (6个月内)
Application → Gateway (限流熔断) → Modules (多个业务模块)
                     ↓
         MySQL 集群 (分库分表) + 三级缓存
                     ↓
    OpenTelemetry 全链路监控 + 自动告警

✅ 优点: 性能达到极致，支持100万+ DAU
✅ 适用: 99%企业应用场景

阶段四: 模块化单体 (可选，1年+)
Application → Gateway → 
              ├─ Module 1 (JAR)
              ├─ Module 2 (JAR)
              └─ Module 3 (JAR)

同一 JVM 进程内，模块间通过接口调用，保持单体架构优势

✅ 优点: 模块独立开发，保持单体部署简单性
✅ 适用: 大型团队协作

--------------------------------------------------
分布式架构 (可选扩展，仅在必要时考虑)

阶段五: 微服务架构 (按需，2年+)
仅在以下情况才考虑微服务拆分：
1. 单体应用性能瓶颈无法通过优化解决
2. 团队规模 > 50人
3. 业务复杂度确实需要隔离
4. 有专职运维团队支持

Application → Istio Ingress → Service Mesh
                           ↓
               Service1, Service2, Service3
                           ↓
              Nacos + K8s + Dubbo/gRPC

⚠️ 注意: 微服务带来复杂度，需谨慎评估

6.2 数据架构演进（渐进式优化）¶

阶段一: 单库单表 (当前)
MySQL 单实例
- 适用: 数据量 < 100万，并发 < 1000

✅ 优点: 简单可靠
⚠️ 瓶颈: 单点故障，性能受限

阶段二: 主从复制 + 读写分离 (1个月)
MySQL Master (写) → Slave1, Slave2 (读)
HikariCP 连接池 (写库/读库分离)

✅ 性能提升: 3-5倍
✅ 适用: 数据量 < 500万，并发 < 5000

阶段三: 垂直分库 (按需，3-6个月)
├─ 用户库 (user_db)
├─ 订单库 (order_db)
└─ 内容库 (cms_db)

✅ 适用: 单表数据 > 500万
✅ 好处: 资源隔离，故障隔离

阶段四: 水平分表 (按需，6-12个月)
user_table_00, user_table_01, ..., user_table_99
分片策略: 按 user_id % 100

✅ 适用: 单表数据 > 1000万
⚠️ 复杂度: 需要 ShardingSphere

--------------------------------------------------
多数据源架构 (可选扩展)

阶段五: 多类型数据库 (可选，1年+)
├─ MySQL (事务数据，OLTP)
├─ Redis (缓存 + Session)
├─ MongoDB (文档数据，日志)
├─ Elasticsearch (全文搜索)
└─ ClickHouse (OLAP分析，按需)

⚠️ 注意: 多数据源增加运维成本，按需引入

6.3 缓存架构演进¶

阶段一: Redis 单级缓存 (当前)
Application → Redis → MySQL

阶段二: 两级缓存 (1个月)
L1: Caffeine (本地缓存，ms级)
  ↓ Miss
L2: Redis (分布式缓存，10ms级)
  ↓ Miss
MySQL

✅ 性能提升: 5-10倍
✅ 缓存命中率: 95%+

阶段三: 三级缓存 (3个月)
L1: JVM Heap (热点数据，μs级)
  ↓ Miss
L2: Caffeine (本地缓存，ms级)
  ↓ Miss  
L3: Redis (分布式缓存，10ms级)
  ↓ Miss
MySQL

✅ 性能提升: 10-50倍
✅ 支持极高并发场景

阶段四: 智能缓存 (6个月)
- 自动识别热点数据
- 缓存预热自动化
- 缓存一致性保障
- 缓存穿透/击穿/雪崩防护

6.4 技术债务清理¶

问题	影响	优先级	解决方案	计划时间
测试覆盖率不足	质量风险高	🔴 P0	提升到80%，引入Mutation Testing	Q1 Week 1
缺少监控告警	运维风险高	🔴 P0	集成Prometheus+Grafana	Q1 Week 4-5
静态代码分析缺失	代码质量无保障	🔴 P0	集成SonarQube	Q1 Week 2
文档不完善	上手成本高	🟠 P1	补齐核心文档，录制视频教程	Q2 Week 3
性能基准缺失	优化无依据	🟠 P1	建立性能基准测试	Q2 Week 4
Dubbo 闲置	架构不清晰	🟢 P3	保留但不使用，文档说明	Q3
K8s 配置缺失	部署灵活性差	🟢 P3	Docker优先，K8s可选	Q4

处理原则: - P0 (红色): 立即处理，阻塞发版 - P1 (橙色): 本季度内必须完成 - P2 (黄色): 半年内完成 - P3 (绿色): 一年内或按需处理

7. 行动计划（按优先级）¶

7.1 Q1 2026 (1-3月) - 基础打牢¶

Week 1: 质量门禁建设 🔴 - [x] 配置 JaCoCo 覆盖率检查 - [ ] 集成 Mutation Testing (PIT) - [ ] 编写单元测试提升覆盖率到 60% - [ ] GitHub Actions CI 基础配置

Week 2: 代码质量工具 🔴 - [ ] 集成 SonarQube - [ ] 集成 ArchUnit 架构约束 - [ ] 优化 Spotless 规则 - [ ] OWASP Dependency Check

Week 3: 自动化构建 🔴 - [ ] 完善 GitHub Actions - [ ] Docker 镜像构建优化 - [ ] 自动化测试流水线 - [ ] 发布流程自动化

Week 4-5: 可观测性 🔴 - [ ] Prometheus + Grafana 集成 - [ ] 完善链路追踪 - [ ] 统一日志格式 - [ ] 健康检查端点

Week 6: Config 模块 🔴 - [ ] 系统参数管理 - [ ] 数据字典管理 - [ ] 配置热更新 - [ ] 单元测试

Week 7: Log 模块 🔴 - [ ] 操作日志 AOP - [ ] 审计日志 - [ ] 日志查询 - [ ] 单元测试

Week 8: 数据库优化 🟠 - [ ] HikariCP 调优 - [ ] 慢查询监控 - [ ] 索引优化 - [ ] 批量操作优化

Week 9: 缓存优化 🟠 - [ ] 两级缓存实现 - [ ] 缓存一致性 - [ ] 缓存防护 - [ ] 性能测试

Week 10: Notification 模块 🟠 - [ ] 站内消息 - [ ] WebSocket 推送 - [ ] 消息订阅 - [ ] 单元测试

Week 11-12: 安全加固 🟠 - [ ] API 限流 - [ ] IP 黑白名单 - [ ] 防重放攻击 - [ ] 数据脱敏

Week 12: 测试覆盖率冲刺 🔴 - [ ] 单元测试覆盖率达到 80% - [ ] 集成测试完善 - [ ] 性能基准测试 - [ ] 测试报告生成

7.2 Q2 2026 (4-6月) - 业务扩展¶

业务模块: - [ ] CMS 内容管理 (3周) - [ ] Workflow 工作流 (4周) - [ ] Report 报表中心 (3周)

开发者工具: - [ ] 代码生成器 (2周) - [ ] SQL 审核工具 (1周) - [ ] 文档生成 (1周)

性能优化: - [ ] 读写分离 (1周) - [ ] 三级缓存 (1周) - [ ] 虚拟线程全面应用 (1周) - [ ] 性能基准报告 (1周)

7.3 Q3-Q4 2026 (7-12月) - 平台化¶

平台建设: - [ ] 开发者平台 (8周) - [ ] 运维管理平台 (6周) - [ ] 低代码平台 (8周)

生态建设: - [ ] 插件市场 - [ ] 最佳实践库 - [ ] 开发者社区 - [ ] 视频教程

可选扩展: - [ ] 微服务拆分方案（仅文档） - [ ] 消息队列集成（按需） - [ ] 分布式部署（按需）

8. 成功指标¶

8.1 质量指标（最高优先级）¶

指标	当前	Q1目标	Q2目标	年度目标
单元测试覆盖率	40%	80%	85%	90%
Mutation覆盖率	0%	60%	70%	75%
SonarQube评分	-	B	A	A+
技术债务	未统计	<8h	<4h	<2h
代码重复率	未统计	<5%	<3%	<2%

8.2 性能指标（高优先级）¶

指标	当前	Q1目标	Q2目标	年度目标
API P95响应时间	-	<200ms	<100ms	<50ms
API P99响应时间	-	<500ms	<300ms	<100ms
数据库连接池利用率	-	<70%	<60%	<50%
缓存命中率	-	>90%	>95%	>98%
并发支持	-	1000 QPS	5000 QPS	10000 QPS

8.3 稳定性指标（高优先级）¶

指标	当前	Q1目标	Q2目标	年度目标
应用可用性	-	99%	99.9%	99.95%
错误率	-	<1%	<0.5%	<0.1%
MTTR (平均恢复时间)	-	<1h	<30min	<15min
监控覆盖率	0%	80%	95%	100%

8.4 开发效率指标（中优先级）¶

指标	当前	Q1目标	Q2目标	年度目标
构建时间	-	<5min	<3min	<2min
部署频率	-	周	日	日多次
代码生成覆盖率	0%	30%	50%	70%
文档完成度	60%	90%	95%	100%

8.5 业务指标（中优先级）¶

指标	当前	Q1目标	Q2目标	年度目标
组件数量	15	17	19	22
业务模块	1	3	6	10
最佳实践案例	0	5	15	30
社区贡献者	1	3	5	10

8.6 可选扩展指标（低优先级）¶

仅在启用分布式能力时关注

指标	说明
服务数量	仅在微服务化时统计
服务间调用延迟	仅在启用RPC时统计
分布式事务成功率	仅在使用Seata时统计
服务注册成功率	仅在使用Nacos时统计

9. 架构决策说明¶

9.1 为什么选择"单体应用优先"策略？¶

技术层面¶

1. 单体应用的优势 - ✅ 部署简单: 一个 JAR 包搞定，无需复杂的服务编排 - ✅ 调试方便: 本地 IDE 直接启动，断点调试无障碍 - ✅ 性能更好: 进程内方法调用，无网络开销 - ✅ 事务简单: 本地事务即可，无需分布式事务 - ✅ 运维成本低: 一个进程监控，日志集中在一起

2. 微服务的代价 - ❌ 复杂度高: 需要服务注册、配置中心、网关、链路追踪等一整套基础设施 - ❌ 运维成本高: 多个服务部署、监控、日志收集 - ❌ 分布式事务难: CAP 定理的取舍，最终一致性的复杂度 - ❌ 网络延迟: 服务间调用增加网络延迟 - ❌ 调试困难: 问题排查需要跨多个服务

业务层面¶

3. 实际业务需求分析

99% 的企业应用：
- DAU < 100万
- 并发 < 10000 QPS
- 团队 < 50人
- 业务复杂度：中等

结论：单体应用完全够用！

4. 过早微服务化的风险 - 🔴 过度设计: 为了微服务而微服务，增加不必要的复杂度 - 🔴 效率降低: 开发效率、调试效率、部署效率都会下降 - 🔴 团队负担: 小团队难以驾驭微服务的复杂度 - 🔴 资源浪费: 多个服务占用更多内存和CPU

9.2 什么时候才需要微服务？¶

真正需要微服务的场景¶

只有满足以下至少3个条件，才考虑微服务化：

性能瓶颈 🔴
单体应用优化到极致仍无法满足性能要求
例如：DAU > 100万，并发 > 10000 QPS
团队规模 🔴
团队规模 > 50人
多个团队并行开发同一个系统
组织结构需要康威定律支持
业务隔离 🟠
不同业务模块的发布周期差异很大
某些模块需要独立扩缩容
业务域边界清晰且稳定
技术异构 🟡
不同模块需要不同的技术栈
例如：核心业务用 Java，推荐系统用 Python
运维团队 🟡
有专职的运维团队（至少5人）
具备 K8s、监控、日志等全套基础设施运维能力

9.3 单体应用的性能极限¶

优化后的单体应用可以支持:

指标	优化前	优化后	说明
并发 QPS	1000	10000+	通过缓存、异步、批量优化
响应时间	500ms	50ms	多级缓存 + 数据库优化
DAU	10万	100万+	读写分离 + 缓存优化
数据量	100万	1亿+	分库分表 (仍然是单体部署)

真实案例: - Stack Overflow: 单体应用支持 1300万+ DAU - Shopify: 早期单体应用支持数万商家 - GitHub: 2018年前一直是单体应用

9.4 我们的渐进式架构路径¶

第一阶段 (0-6个月):
├─ 完善单体应用
├─ 提升代码质量
├─ 建立监控体系
└─ 性能优化

第二阶段 (6-12个月):
├─ 模块化单体 (Modular Monolith)
├─ 模块边界清晰化
├─ 模块独立测试
└─ 为拆分做准备

第三阶段 (12-24个月):
├─ 评估是否真正需要微服务
├─ 如需要：渐进式拆分
│   ├─ 边缘服务先拆 (如报表)
│   ├─ 核心服务后拆 (如用户)
│   └─ 保持数据库单体 (延迟拆分)
└─ 如不需要：持续优化单体

原则：
✅ 能用单体解决的，绝不拆分
✅ 架构随业务演进，而非提前设计
✅ 保持简单，直到复杂度不可避免

9.5 保留分布式能力的理由¶

虽然当前优先单体，但保留分布式能力是为了：

技术预研: 了解分布式技术，为未来做准备
可选扩展: 某些大客户可能需要分布式部署
人才储备: 团队成员学习分布式架构
灵活切换: 业务突然爆发时，可以快速切换

实现方式: - Dubbo: 集成但默认不启用，保留 RPC 调用能力 - Nacos: 提供集成文档，需要时一键启用 - MQ: 组件化设计，需要时引入依赖即可 - K8s: Dockerfile 和 Helm Charts 准备好，需要时部署

9.6 给团队的建议¶

对开发者: - 先把单体应用代码写好，遵循 SOLID 原则 - 模块边界清晰，低耦合高内聚 - 充分的单元测试和集成测试 - 性能优化优先于架构拆分

对架构师: - 不要为了炫技而过度设计 - 架构演进要跟随业务发展 - 保持 KISS 原则 (Keep It Simple, Stupid) - 监控指标驱动架构决策

对管理者: - 理解微服务不是银弹 - 单体应用不等于技术落后 - 性能问题优先考虑优化而非拆分 - 团队能力是架构选择的关键因素

附录¶

A. 参考资源¶

B. 相关文档¶

C. 变更历史¶

版本	日期	变更内容
0.1.0	2026-02-28	初始版本，完整规划路线图