企业官网建设流程全解析

MyBatis-Plus 整合 Spring Boot 管理 LoRA 脚本任务队列

在 AI 模型微调日益普及的今天，LoRA（Low-Rank Adaptation）因其轻量高效、资源消耗低的特点，成为 Stable Diffusion 图像生成和大语言模型垂直领域适配的首选方案。然而，尽管训练过程本身可以跑在消费级显卡上，实际落地时却面临一个更棘手的问题：如何让非技术用户也能安全、可控地发起训练任务？又该如何在一个团队或平台中统一管理成百上千个异步训练作业？

这时候，单纯依赖命令行脚本就显得捉襟见肘了。我们需要的是一个具备状态追踪、并发控制、错误恢复能力的任务管理系统——而这正是 Java 企业生态最擅长的领域。

于是，将lora-scripts这类 Python 训练工具与 Spring Boot 后端服务打通，并通过 MyBatis-Plus 实现任务持久化，就成了构建 AI 工程化平台的关键一步。

为什么需要把 AI 脚本纳入后端管理？

很多人可能会问：“既然lora-scripts已经封装好了训练流程，为什么不直接写个 shell 脚本批量运行？”
这确实可行，但在生产环境中很快会遇到瓶颈：

• 无法追溯历史：谁什么时候跑了什么任务？参数是什么？失败原因在哪？
• 缺乏隔离机制：多个任务共用目录或配置容易冲突，尤其在多用户场景下。
• 前端无法集成：没有 API 接口，没法做可视化控制台或接入自动化流水线。
• 容错能力差：进程崩溃后难以自动恢复，也无法实现断点续训的状态同步。

而这些问题，恰恰是 Spring Boot + 数据库这套组合拳最拿手的地方。我们不需要重新造轮子，只需把 AI 工具当作“外部执行器”，由 Java 服务来调度它、监控它、记录它。

lora-scripts 是什么？它是怎么工作的？

简单来说，lora-scripts是一套面向 LoRA 微调的开箱即用训练框架，支持图像生成（如 Stable Diffusion）和文本生成（如 LLaMA、ChatGLM）。它的核心设计哲学是“配置驱动 + 流程自动化”。

整个训练流程被标准化为几个关键步骤：

1. 准备数据集并组织成特定结构；
2. 使用自动标注工具生成 metadata.csv 文件（包含每张图的 prompt 描述）；
3. 编写 YAML 配置文件，定义基础模型、LoRA 秩、学习率等超参数；
4. 执行python train.py --config config.yaml启动训练；
5. 系统自动完成模型加载、LoRA 注入、训练循环、权重保存等操作；
6. 输出.safetensors格式的 LoRA 权重文件供推理使用。

这种“声明式”接口极大降低了使用门槛。哪怕你不熟悉 PyTorch 的训练逻辑，只要改配置就能跑通一次完整训练。

# train.py 示例片段（伪代码） import yaml import torch from models import load_base_model, add_lora_adapter from datasets import build_dataloader from trainer import LoRATrainer def main(config_path): with open(config_path, 'r') as f: config = yaml.safe_load(f) model = load_base_model(config['base_model']) model = add_lora_adapter(model, rank=config['lora_rank']) dataloader = build_dataloader(config['train_data_dir'], config['metadata_path']) optimizer = torch.optim.AdamW(model.parameters(), lr=config['learning_rate']) trainer = LoRATrainer( model=model, dataloader=dataloader, optimizer=optimizer, epochs=config['epochs'], output_dir=config['output_dir'] ) trainer.train() if __name__ == "__main__": import argparse parser = argparse.ArgumentParser() parser.add_argument("--config", type=str, required=True) args = parser.parse_args() main(args.config)

这个脚本的设计非常干净：所有可变因素都从外部注入，主流程高度模块化。这也为我们后续通过 Java 动态生成配置、调用训练提供了可能。

如何用 Spring Boot 构建任务管理系统？

我们的目标很明确：让用户通过 Web 页面提交训练请求，系统自动创建任务、生成配置、启动训练、更新状态，并提供查询接口。

为此，我们采用经典的三层架构：

数据层：MyBatis-Plus 提升开发效率

相比原生 MyBatis，MyBatis-Plus 提供了大量便利特性：

• 注解式映射（@TableName,@TableId），无需 XML；
• 继承BaseMapper<T>即获得通用 CRUD 方法；
• 强大的QueryWrapper支持复杂条件查询；
• 内置分页插件，兼容多种数据库方言。

我们定义一个LoraTask实体类，对应数据库表t_lora_task：

@TableName("t_lora_task") @Data public class LoraTask { @TableId(type = IdType.AUTO) private Long id; private String taskName; private String dataDir; private String metadataPath; private String baseModel; private Integer loraRank; private Integer batchSize; private Integer epochs; private Double learningRate; private String outputPath; private String status; // PENDING, RUNNING, SUCCESS, FAILED private String logPath; private LocalDateTime createTime; private LocalDateTime updateTime; }

对应的 Mapper 接口极为简洁：

public interface LoraTaskMapper extends BaseMapper<LoraTask> { }

就这么一行代码，就已经拥有了 insert、update、selectById、delete 等全套操作能力。

业务层：异步执行与状态同步

真正的核心逻辑在 Service 层。这里最关键的一点是：不能阻塞主线程。训练可能持续数小时，我们必须将其放入独立线程中执行。

Spring 提供了@Async注解来轻松实现异步调用。只需在方法上加上该注解，并确保主类启用了@EnableAsync，即可开启异步支持。

@Service public class LoraTaskService { @Autowired private LoraTaskMapper taskMapper; @Async public void startTraining(LoraTask task) { // 1. 更新状态为 RUNNING task.setStatus("RUNNING"); task.setUpdateTime(LocalDateTime.now()); taskMapper.updateById(task); // 2. 生成 YAML 配置文件 generateConfigYaml(task); // 3. 构建并执行 Python 命令 ProcessBuilder pb = new ProcessBuilder( "python", "train.py", "--config", task.getConfigPath() ); pb.directory(new File("/opt/lora-scripts")); // 设置工作目录 pb.redirectOutput(new File(task.getLogPath())); // 重定向日志 pb.redirectErrorStream(true); try { Process process = pb.start(); int exitCode = process.waitFor(); // 4. 根据退出码更新状态 if (exitCode == 0) { task.setStatus("SUCCESS"); } else { task.setStatus("FAILED"); } } catch (Exception e) { task.setStatus("FAILED"); log.error("训练任务执行失败", e); } finally { task.setUpdateTime(LocalDateTime.now()); taskMapper.updateById(task); } } private void generateConfigYaml(LoraTask task) { Yaml yaml = new Yaml(); Map<String, Object> config = new HashMap<>(); config.put("train_data_dir", task.getDataDir()); config.put("metadata_path", task.getMetadataPath()); config.put("base_model", task.getBaseModel()); config.put("lora_rank", task.getLoraRank()); config.put("batch_size", task.getBatchSize()); config.put("epochs", task.getEpochs()); config.put("learning_rate", task.getLearningRate()); config.put("output_dir", task.getOutputPath()); try (FileWriter writer = new FileWriter(task.getConfigPath())) { yaml.dump(config, writer); } ) { throw new RuntimeException("生成配置文件失败", e); } } }

几点值得注意的细节：

• 日志重定向：将 Python 脚本的标准输出写入指定日志文件，便于后续查看；
• 异常兜底：即使抛出异常也确保状态能更新为 FAILED，避免任务“卡住”；
• 配置安全生成：不拼接字符串，而是通过 Map 构建 YAML，防止注入攻击；
• 路径隔离：每个任务使用独立的输出目录和日志路径，避免冲突。

整体架构与工作流程

系统的整体结构如下：

+------------------+ +-----------------------+ | Web Frontend |<----->| Spring Boot Server | +------------------+ +-----------+-----------+ | +--------------------v--------------------+ | MySQL (t_lora_task) | +-----------------------------------------+ +-----------------------------------------+ | lora-scripts (Python) | | - train.py | | - configs/my_lora_config.yaml | | - logs/train.log | +-----------------------------------------+

典型的工作流程包括五个阶段：

1. 任务创建
   用户填写表单（任务名、数据路径、基础模型、LoRA 秩等）并通过/api/tasks提交。

2. 任务入库
   后端校验参数合法性，插入数据库记录，初始状态设为PENDING，返回任务 ID。

3. 异步执行
   触发@Async方法，动态生成 YAML 配置文件，调用ProcessBuilder启动 Python 脚本。

4. 状态同步
   监听进程退出码，更新最终状态；若需实时进度，可额外开启线程读取日志中的 loss、step 等信息。

5. 结果查看
   前端定期轮询/api/tasks/{id}获取最新状态，点击可查看完整日志或下载生成的.safetensors权重。

实际痛点与应对策略

此外，在工程实践中还需考虑以下设计要点：

• 安全性：禁止用户直接输入命令行参数，防止命令注入漏洞；
• 可观测性：结合 ELK 或 Prometheus + Grafana 实现日志聚合与指标监控；
• 可伸缩性：未来可替换本地进程调用为 Docker 容器或 Kubernetes Job，实现资源隔离与弹性调度；
• 模板化配置：预置常用训练模板（如“赛博朋克风格绘画”、“医疗问答微调”），降低使用门槛；
• 失败重试机制：对临时性错误（如磁盘满、网络抖动）支持自动重试。

更进一步：从本地执行到容器化调度

目前我们使用ProcessBuilder调用本地 Python 环境，适合小规模部署。但随着任务量增长，这种方式存在明显局限：

• 资源难以隔离：多个任务共享同一 GPU，容易互相影响；
• 扩展性差：无法跨机器调度，也不能根据负载动态扩容；
• 环境一致性难保证：不同节点的 Python 版本、依赖包可能不一致。

因此，下一阶段演进方向是容器化：

1. 将lora-scripts打包为 Docker 镜像，内置训练环境；
2. Spring Boot 不再直接调用本地脚本，而是向 Kubernetes 提交 Job；
3. 每个训练任务运行在一个独立 Pod 中，独占 GPU 资源；
4. 通过 ServiceAccount 控制权限，保障集群安全；
5. 利用 K8s 的重启策略、资源限制、健康检查等特性提升稳定性。

这样一来，系统就真正具备了高可用、易扩展的企业级能力。

结语

将lora-scripts与 Spring Boot + MyBatis-Plus 结合，看似只是“Java 调了个 Python 脚本”，实则完成了一次重要的工程跃迁：把原本散落在个人电脑上的 AI 实验，变成了可管理、可追踪、可复用的平台级能力。

这不仅是技术整合，更是思维方式的转变——AI 不应只属于算法工程师，它应该像数据库、缓存一样，成为整个系统可调用的服务组件。

而这样的融合路径，也正是当前 AI 工程化的大势所趋。