独立承担后端架构设计与核心编码，搭建一套多模型调度的个性化学习资源推荐平台，实现智能对话问答、知识库管理、个性化资源推荐等业务，重点解决多模型调用容错、接口响应慢、业务数据闭环等问题。

项目背景与目标

学习场景需要按任务特点选择不同大模型，而多模型分散调用带来的单点故障会影响整个业务；长耗时 AI 响应让前端白屏等待，反复调用又持续消耗 Token。项目目标是把模型调用收口、把响应变流式、把重复调用降下去。

  • 多模型按业务场景分流（DeepSeek / Kimi / Qwen），实现单模型故障隔离。
  • 长耗时响应流式输出，避免前端白屏。
  • AI 重复调用量下降 42%，数据库压力显著降低。

技术架构与选型思考

基于 Spring AI Alibaba 封装统一 AiChatClient，按业务场景路由不同模型，新增模型仅需调整配置；输出侧用 SseEmitter 做流式推送，数据侧用 Cache Aside 策略管理缓存。

  • 调用层：统一 AiChatClient 场景路由 + 全局异常处理 + 统一 Result 封装 + 失败重试机制。
  • 输出层：SseEmitter + 异步线程池实现流式推送，逐字输出。
  • 数据层：Cache Aside 更新策略与 Redis 差异化缓存，结合 MyBatis-Plus、数据库 sequence 与事务控制实现节点状态自动流转及缓存联动失效。

核心难点与解决方案

难点一：多模型调用分散、单点故障影响业务

基于 Spring AI Alibaba 封装统一 AiChatClient，按业务场景路由不同模型，结合全局异常处理、统一 Result 封装与失败重试机制，实现单模型故障隔离，后端接口稳定性明显提升。

难点二：长耗时响应导致前端白屏、AI 返回 JSON 被 Markdown 包裹

基于 SseEmitter + 异步线程池实现流式推送，通过自定义解析链路与超时异常处理，实现逐字输出，非标准返回解析成功率由 71% 提升至 85%。

难点三：AI 重复调用消耗 Token、统计查询频繁读库

基于 Cache Aside 更新策略与 Redis 实现差异化缓存，结合 MyBatis-Plus、数据库 sequence 与事务控制实现节点状态自动流转及缓存联动失效，AI 重复调用量下降 42%，数据库压力显著降低。

项目成果与个人收获

  1. 多模型分流与故障隔离落地，单模型故障不再影响整体业务，后端接口稳定性明显提升。
  2. 流式输出 + 解析容错，非标准返回解析成功率由 71% 提升至 85%。
  3. AI 重复调用量下降 42%，数据库压力显著降低。

相关链接

项目已作为课程与个人作品沉淀，源码与演示地址暂不对外公开。