从单体到微服务：Redis 协同 MySQL、Milvus、MinIO 搭建企业级RAG/AI Agent脚手架架构

前言

最近在落地多套Java后端RAG、AI Agent中台脚手架时，身边不少后端、AI开发同学都会有几个共性疑问：

1. 小型AI项目初期有必要直接上微服务拆分吗？单体不能满足需求吗？
2. Redis仅仅只是缓存工具？在AI向量架构里它的核心定位到底是什么？
3. MySQL、Redis、Milvus、MinIO四件套为什么是AI项目标配？各自分工、数据流转逻辑是什么？

本文结合真实生产级AI知识库脚手架设计思路，从软件架构演进脉络切入，逐层拆解单体→分布式→微服务的适用场景与痛点，重点梳理四大存储组件的职责边界、协同流程，整套架构可直接作为Java微服务、RAG智能体项目的标准架构参考方案。

一、软件架构三大演进阶段

所有业务系统的架构迭代都遵循一套通用路径，三者不存在完全替代关系，是业务体量、并发规模、业务复杂度驱动下的渐进式升级：

1.1 第一阶段：单体架构（Monolithic）

绝大多数初学者、毕业设计、初创MVP产品使用的SpringBoot项目，本质都是单体架构。

架构形态

整个业务仅一个工程包，所有业务模块、数据库交互、文件处理、AI能力耦合在同一个JVM进程内：

AI脚手架单体工程
├── 用户登录权限模块
├── AI对话Chat模块
├── Embedding向量化模块
├── 知识库解析模块
├── 文件上传处理模块
└── 统一MySQL数据源

部署方式极简：打包单一Jar包，单端口启动（如8080），所有HTTP请求统一接入当前服务。

核心优势

1. 开发门槛极低，无需服务注册、网关、远程调用等中间件；
2. 部署、调试简单，单应用运维成本几乎为零；
3. 适合小流量、短期验证类项目、演示Demo。

致命短板（AI项目痛点尤为明显）

所有模块共享服务器CPU、内存、IO资源，存在一崩全崩的耦合问题：
AI对话并发突增占用满CPU → 登录接口响应超时 → 文件上传、知识库解析全部阻塞。
一旦AI推理、向量解析等高消耗业务流量上涨，整体系统可用性直接归零，无法单独扩容高负载模块。

1.2 第二阶段：分布式架构（Distributed）

当用户量、AI对话请求量持续上涨，单体资源瓶颈无法解决，第一步改造思路就是拆分服务器资源，把不同业务部署在独立节点。

架构形态

通过网关统一入口，业务按大领域拆分，每块业务独占服务器：

不同服务运行在不同IP节点，服务之间通过HTTP/RPC远程调用通信。

核心特性

拆分维度是业务大模块+物理服务器，单个服务故障不会拖垮全系统；AI服务负载高时，仅针对AI节点扩容，不影响用户、文件业务。

局限性

模块粒度依旧粗糙，AI综合服务内部包含对话、向量化、文档解析、模型调用等多重逻辑，内部依旧耦合，无法针对Embedding这类高频接口单独弹性扩缩容。

1.3 第三阶段：微服务架构（MicroService）

微服务是分布式架构的精细化升级，拆分粒度下沉到单一业务能力，一个大领域拆分为多个独立微服务，每个服务只负责一件事。
以AI模块举例，分布式架构中统一的AI综合服务，在微服务架构下拆分为：

• ChatService：AI对话交互服务
• EmbeddingService：文本向量化服务
• KnowledgeService：知识库元数据管理服务
• DocParseService：文档解析、OCR服务
• ModelProxyService：大模型调用代理服务

核心优势

1. 独立开发、独立打包、独立部署、独立扩容：Embedding请求峰值时，仅多启动N个Embedding服务实例即可，对话服务无需扩容；
2. 技术栈隔离：不同服务可按需选用适配技术，互不干扰；
3. 故障隔离：单个向量服务宕机，对话、文件业务不受影响；
4. 适配企业级持续迭代、多人团队协作开发。

二、脚手架Base公共基础模块设计思路

搭建微服务AI项目时，标准化脚手架必须抽离base公共基础模块，作为全系统统一基础设施，避免每个微服务重复编写中间件连接、工具类、配置代码。

Base模块职责（不承载任何业务逻辑）

base通用基座模块
├── Redis统一配置、工具封装
├── MySQL MyBatis-Plus通用封装
├── MinIO对象存储工具类
├── Milvus向量数据库连接工具
├── 全局日志、异常处理器
├── 统一返回体、分页工具、加解密工具
├── 全局公共常量、AI Prompt模板工具
└── Docker镜像统一打包配置

依赖关系

所有业务微服务统一依赖Base模块：ChatService、KnowledgeService、DocParseService仅需要引入Base，即可开箱使用Redis、向量库、文件存储能力，全局配置统一管控，大幅降低多服务维护成本。

三、Redis在AI微服务架构中的核心定位

很多开发者对Redis认知局限于“缓存”，但在RAG、AI Agent架构中，Redis是整个系统的高速数据高速公路。

层级定位类比

• Redis = 计算机CPU一级缓存（低延迟、高吞吐、临时/热点数据）
• MySQL = 机械硬盘（永久持久化、结构化业务数据）
  请求流转链路：
  前端请求 → API网关 → 业务微服务 → Redis（优先读取） → MySQL（兜底持久层）

四、Redis与MySQL协同：解决AI业务数据库压力

标准读写流程

1. 查询流程：前端请求 → 优先查询Redis
   • 缓存命中：直接返回数据，不访问MySQL；
   • 缓存未命中（Cache Miss）：查询MySQL持久数据，同步写入Redis后返回结果。
2. 更新流程：修改业务数据时，先更新MySQL，再删除/更新Redis缓存，保证数据一致性。

AI项目适配缓存数据

AI场景下读多写少的数据，全部存入Redis缓解数据库压力：

• 用户登录信息、权限Token、会话上下文
• Agent智能体配置、系统Prompt模板
• 大模型参数配置、知识库基础元数据
• 高频访问的对话历史、热门知识库信息

性能收益

Redis读取延迟仅几百微秒，MySQL查询通常几毫秒~几十毫秒；热点数据缓存后，MySQL查询压力可降低90%以上，有效避免向量查询、高并发对话拖垮数据库。

五、Redis在AI微服务中的五大核心应用场景

5.1 热点数据缓存（最基础能力）

缓存用户信息、菜单、AI模型配置、Prompt模板等低频变更、高频读取数据。

5.2 分布式Session登录共享

多微服务场景下，用户登录态无法单独存储在单个服务内存，统一将Token、用户会话信息存入Redis，所有服务统一校验登录权限，实现全系统单点登录。

5.3 异步消息队列（文档处理流水线）

利用Redis发布订阅/List队列实现AI离线任务异步化，典型文件解析流程：
前端上传PDF → FileService写入MinIO → Redis推送任务消息 → Embedding服务消费消息 → 自动向量化存入Milvus
同步转异步，避免前端长时间阻塞等待文档解析、向量生成。

5.4 分布式锁，保障AI任务数据安全

多服务多实例并发修改Agent配置、知识库、文档解析任务时，通过Redis SETNX实现分布式锁，同一时间仅一个线程执行更新操作，杜绝并发脏数据。

5.5 任务状态、对话上下文临时存储

文档上传解析进度、AI长对话上下文、向量构建任务执行状态全部存入Redis，前端轮询读取实时进度，实现“解析中/向量化完成”动态页面提示。

六、Redis、Milvus协同分工：业务数据与向量数据解耦

不少新手疑惑：已经有向量数据库Milvus，为什么还要搭配Redis？核心原因是二者存储的数据类型完全隔离，各司其职、互补协作。

Redis存储内容（高速业务临时数据）

Token登录态、对话上下文、任务执行状态、热点业务缓存、分布式锁、消息队列任务。

Milvus存储内容（向量专用数据库）

文档切片Embedding向量、图片多模态向量、知识库语义检索向量，仅负责向量相似度查询。

简单区分：Redis管业务运行状态，Milvus管AI语义检索，不存在功能重叠，缺一不可。

七、Redis、MinIO协同：文件全生命周期状态管控

MinIO仅负责存储PDF、Word、图片、音视频等原始二进制文件，无法记录文件解析进度，完整文件处理链路：

1. 前端上传文档 → FileService将原始文件存入MinIO，返回文件唯一标识；
2. 服务向Redis写入任务状态键：upload:fileId:processing；
3. 消费端完成文档解析、OCR、向量化后，更新Redis状态为success；
4. 前端轮询Redis状态，实时展示「解析中→向量化中→完成」进度。

文件本体永久存在MinIO，流转状态、进度交由Redis高速维护，用户交互体验流畅无阻塞。

八、四大存储组件完整协同架构图

四大组件职责对比表

组件	核心定位	存储数据类型	AI项目核心作用
MySQL	结构化持久数据库	用户、知识库元数据、Agent配置、订单等业务结构化数据	保证业务数据落地持久，支持复杂事务、多条件查询
Redis	内存高速中间件	Token、会话上下文、任务状态、缓存、消息队列、分布式锁	降低DB压力、异步任务、分布式协同、低延迟交互
MinIO	分布式对象存储	PDF、Word、图片、音视频、附件等二进制文件	海量文件持久存储，支持文件分片、预览、权限管理
Milvus	专用向量数据库	文本Embedding、多模态图片向量、知识库切片向量	高效向量相似度检索，支撑RAG语义问答核心能力

九、总结

1. 架构演进逻辑：单体架构适合小型Demo，分布式架构解决资源隔离，微服务架构适配企业级高并发AI项目，三者按需选择，无需盲目过度拆分；
2. 脚手架标准化设计：抽离Base公共模块统一封装Redis/MySQL/Milvus/MinIO，降低多微服务开发、维护成本；
3. 四大存储分层设计是AI RAG/Agent项目最优实践：
   • MySQL承载稳定持久的结构化业务数据；
   • Redis作为全系统高速内存枢纽，承接缓存、异步、分布式协同能力；
   • MinIO统一管理项目所有非结构化文件资源；
   • Milvus专注向量存储与语义检索，支撑RAG核心问答能力；
4. 优秀架构的核心原则：不盲目堆砌中间件，每个组件只承担自身最擅长的工作，通过清晰的数据流转、职责边界，实现系统高性能、高可用、易扩展。

---