最近在做一个AI智能客服系统的项目刚好结合了Spring Boot和Vue.js还集成了DeepSeek的AI能力。整个过程踩了不少坑也积累了一些经验今天就来和大家分享一下从架构设计到最终部署上线的完整实战过程。1. 项目背景与痛点分析最开始接触这个需求是因为公司原有的客服系统问题越来越明显。传统的规则匹配或简单关键词回复在应对复杂、开放的客户咨询时显得力不从心。并发处理能力弱遇到促销活动大量用户同时涌入系统响应延迟飙升甚至直接宕机严重影响用户体验。意图识别准确率低用户的问题千变万化同一种意图可能有几十种问法。传统系统依赖人工维护的规则库覆盖不全导致大量问题无法被正确理解需要转人工成本高。缺乏上下文理解多轮对话用户经常需要连续追问。比如先问“我的订单发货了吗”接着问“那预计什么时候到”。老系统无法关联上下文每次都要用户重复信息对话体验非常割裂。扩展和维护困难业务逻辑和对话逻辑耦合严重每增加一个新业务比如退货政策查询就需要开发人员修改大量代码上线周期长。正是这些痛点促使我们决定用现代技术栈和AI能力重构整个客服系统。2. 技术选型背后的思考技术选型是项目的地基我们花了相当多的时间进行对比和验证。为什么是Spring BootJava生态成熟稳定团队熟悉度高是首要原因。我们对比了传统的Spring MVC和新兴的Quarkus、Micronaut。Spring MVC配置繁琐需要大量XML或注解启动速度在微服务场景下偏慢。Quarkus/Micronaut主打云原生、启动快、内存占用小但生态相对较新某些中间件集成可能不如Spring Boot成熟团队学习成本较高。Spring Boot最终胜出。它“约定大于配置”的理念极大地简化了开发。内嵌Tomcat/Jetty一键启动。最重要的是其庞大的社区和丰富的Starter如Spring Security, Spring Data, Spring Cloud让我们在实现安全、数据访问、服务治理等功能时几乎可以“开箱即用”能快速搭建出健壮的后端服务。为什么是Vue.js前端框架在React和Vue之间选择。两者都是优秀的选择。React生态更庞大灵活性极高但学习曲线相对陡峭对于需要快速上手、开发管理后台这类中后台应用的项目来说心智负担稍重。Vue.js其渐进式框架的特性和清晰的单文件组件.vue结构对开发者非常友好。模板语法直观易于理解和上手。特别是其响应式系统和Composition API在构建复杂的、需要维护大量状态的对话界面时状态管理变得清晰可控。Vue生态的Vue Router、Pinia状态管理也足够成熟能很好地支撑我们的应用。AI能力核心为什么选择DeepSeek市面上大模型API很多我们主要对比了OpenAI GPT系列、国内的一些大厂模型和DeepSeek。成本与性能平衡DeepSeek在保持相当高推理能力尤其在中文场景的同时API调用成本具有显著优势这对于需要处理海量对话的客服系统至关重要。API友好度其API设计简洁明了文档清晰提供了完善的对话、上下文管理等接口与我们需要的功能匹配度高。合规与可控性从数据安全和合规角度考虑也需要评估供应商的稳定性。3. 核心架构设计与拆解我们采用了领域驱动设计DDD的思想来划分微服务并结合前后端分离架构。微服务边界划分DDD用户会话服务 (Session Service)核心领域。负责会话生命周期的管理创建、保持、销毁维护对话上下文。这是与AI交互的基石。对话引擎服务 (Dialogue Engine Service)核心领域。接收用户输入调用意图识别服务管理多轮对话逻辑并最终调用AI服务或知识库服务生成回复。它是系统的“大脑”。AI网关服务 (AI Gateway Service)关键支撑。作为统一适配层封装对DeepSeek API的调用实现鉴权、参数组装、响应解析、重试、熔断等通用逻辑。其他服务通过它来使用AI能力实现了解耦。知识库服务 (Knowledge Base Service)支撑领域。管理公司的产品文档、常见问题FAQ等结构化/非结构化知识为AI提供检索增强生成RAG的能力确保回答的准确性。管理后台服务 (Admin Service)支撑领域。提供对话日志查看、知识库管理、系统监控等功能。通信协议与API设计RESTful API用于管理类、配置类等请求-响应模式的交互如获取历史会话、更新知识库。我们遵循统一的规范如使用HTTP动词GET/POST/PUT/DELETE返回标准化的JSON响应体包含code, data, message。WebSocket用于核心的实时对话。前端建立WebSocket连接后可以持续发送消息和接收AI的流式回复实现类似聊天软件的流畅体验。这比HTTP轮询或长轮询高效得多。集成DeepSeek的适配层设计这是确保AI能力稳定可用的关键。我们设计了一个AiGatewayService它主要做以下几件事统一客户端使用Feign Client或RestTemplate封装DeepSeek的HTTP请求。参数标准化将内部统一的对话请求对象转换为DeepSeek API所需的特定格式包括模型选择、温度、最大token等参数。响应解析与归一化将DeepSeek返回的响应解析成内部通用的对话响应对象处理可能的消息格式如纯文本、JSON等。核心容错机制这是下一节代码示例的重点。4. 关键代码实现与解析4.1 Spring Boot后端AI服务调用的重试与熔断直接调用外部API是不稳定的网络抖动、服务端限流都可能导致失败。我们必须增加容错能力。import org.springframework.retry.annotation.Backoff; import org.springframework.retry.annotation.Retryable; import org.springframework.cloud.client.circuitbreaker.CircuitBreakerFactory; import org.springframework.stereotype.Service; import lombok.extern.slf4j.Slf4j; Slf4j Service public class AiGatewayServiceImpl implements AiGatewayService { private final DeepSeekClient deepSeekClient; // 封装的Feign Client private final CircuitBreakerFactory circuitBreakerFactory; // 使用Spring Retry实现重试机制 Retryable( value {RuntimeException.class}, // 对哪些异常进行重试 maxAttempts 3, // 最大重试次数不含第一次 backoff Backoff(delay 1000, multiplier 2) // 退避策略首次延迟1秒后续乘2 ) Override public String callDeepSeekForCompletion(String prompt) { log.info(尝试调用DeepSeek API提示词长度{}, prompt.length()); // 这里是实际的API调用 DeepSeekResponse response deepSeekClient.createCompletion(buildRequest(prompt)); return response.getChoices().get(0).getMessage().getContent(); } // 使用Resilience4j或Spring Cloud CircuitBreaker实现熔断 public String callDeepSeekWithCircuitBreaker(String prompt) { // 获取一个名为“deepSeekApi”的熔断器 return circuitBreakerFactory.create(deepSeekApi).run( () - { // 这是受保护的主要逻辑 return callDeepSeekForCompletion(prompt); }, throwable - { // 这是降级逻辑fallback当熔断器打开或调用失败时执行 log.error(调用DeepSeek API失败启用降级回复, throwable); return 抱歉AI服务暂时不可用请稍后再试。您也可以尝试联系人工客服。; } ); } }代码解读Retryable让方法在遇到RuntimeException时自动重试最多3次。Backoff定义了指数退避避免失败后立即重试加重对方服务压力。CircuitBreaker熔断器。当失败率达到阈值时熔断器会“打开”短时间内直接执行降级逻辑不再调用真实服务给下游服务恢复的时间。一段时间后进入“半开”状态试探成功则关闭熔断。这防止了因一个服务不稳定导致整个系统雪崩。4.2 Vue.js前端对话组件的状态管理前端需要维护复杂的对话状态。我们使用PiniaVue的官方状态管理库来集中管理。// stores/chatStore.js import { defineStore } from pinia import { ref, computed } from vue import { sendMessageApi } from /api/chat export const useChatStore defineStore(chat, () { // 状态 const sessionId ref(null) // 当前会话ID const messageList ref([]) // 消息列表每一项包含 {id, role: user|assistant, content, timestamp} const isLoading ref(false) // 是否正在加载AI回复 const socket ref(null) // WebSocket实例 // Getter (计算属性) const lastUserMessage computed(() { const userMessages messageList.value.filter(m m.role user) return userMessages[userMessages.length - 1] }) // Actions (操作方法) function initializeSession() { // 调用后端API创建新会话获取sessionId // ... 省略代码 sessionId.value newSessionId connectWebSocket() // 创建WebSocket连接 } function connectWebSocket() { const wsUrl ws://your-api.com/chat/ws?sessionId${sessionId.value} socket.value new WebSocket(wsUrl) socket.value.onmessage (event) { const data JSON.parse(event.data) if (data.type partial) { // 流式输出更新最后一条助手消息的内容 updateLastAssistantMessage(data.content) } else if (data.type final) { // 最终输出标记消息完成停止加载动画 isLoading.value false finalizeLastAssistantMessage(data.content) } } socket.value.onopen () { console.log(WebSocket连接已建立) // 可以发送历史消息给服务器以恢复上下文 } } async function sendUserMessage(content) { if (!content.trim() || isLoading.value) return // 1. 添加用户消息到列表 const userMsg { id: Date.now(), role: user, content, timestamp: new Date() } messageList.value.push(userMsg) // 2. 添加一个占位的助手消息用于流式显示 const assistantMsgId Date.now() 1 messageList.value.push({ id: assistantMsgId, role: assistant, content: , timestamp: new Date() }) // 3. 设置加载状态 isLoading.value true // 4. 通过WebSocket发送消息 if (socket.value?.readyState WebSocket.OPEN) { socket.value.send(JSON.stringify({ content, sessionId: sessionId.value })) } else { // 降级为HTTP请求 const response await sendMessageApi({ sessionId: sessionId.value, content }) isLoading.value false // 更新最后一条助手消息 updateLastAssistantMessage(response.content) } } function updateLastAssistantMessage(newContent) { const lastMsg messageList.value[messageList.value.length - 1] if (lastMsg lastMsg.role assistant) { lastMsg.content newContent // 流式追加 } } function finalizeLastAssistantMessage(finalContent) { const lastMsg messageList.value[messageList.value.length - 1] if (lastMsg lastMsg.role assistant) { lastMsg.content finalContent // 设置为最终内容 } } return { sessionId, messageList, isLoading, lastUserMessage, initializeSession, sendUserMessage } })代码解读状态集中化所有与聊天相关的数据消息列表、加载状态、连接都存储在Pinia Store中任何组件都可以方便地访问和修改。响应式更新利用Vue的响应式系统ref,computed状态变化会自动更新依赖它们的UI组件。流式处理通过WebSocket接收partial消息并实时追加到UI实现了打字机效果用户体验更好。同时处理了final消息用于最终确认。优雅降级在sendUserMessage中如果WebSocket不可用会自动降级到HTTP API保证了基本功能。4.3 基于Redis的会话上下文缓存AI模型如DeepSeek通常有上下文长度限制。我们需要在服务端维护一个高效的会话上下文缓存。import org.springframework.data.redis.core.RedisTemplate; import org.springframework.stereotype.Service; import java.util.concurrent.TimeUnit; import java.util.List; import java.util.ArrayList; Service public class SessionContextCacheService { private final RedisTemplateString, Object redisTemplate; private static final String SESSION_KEY_PREFIX chat:session:; private static final long SESSION_TTL_HOURS 24; // 会话保存24小时 /** * 将用户和AI的对话消息追加到指定会话的上下文中 * param sessionId 会话ID * param role 角色user 或 assistant * param content 消息内容 */ public void appendMessageToContext(String sessionId, String role, String content) { String key SESSION_KEY_PREFIX sessionId; ChatMessage message new ChatMessage(role, content); // 使用Redis的List数据结构存储消息序列 redisTemplate.opsForList().rightPush(key, message); // 每次访问都刷新过期时间 redisTemplate.expire(key, SESSION_TTL_HOURS, TimeUnit.HOURS); // 可选控制上下文长度避免超出模型限制 trimContextIfNeeded(key); } /** * 获取会话最近的N条消息用于构建AI提示词 * param sessionId 会话ID * param maxMessages 最大消息数 * return 消息列表 */ public ListChatMessage getRecentContext(String sessionId, int maxMessages) { String key SESSION_KEY_PREFIX sessionId; // 获取List最后N个元素 long totalSize redisTemplate.opsForList().size(key); long start Math.max(0, totalSize - maxMessages); ListObject messages redisTemplate.opsForList().range(key, start, -1); ListChatMessage result new ArrayList(); if (messages ! null) { for (Object obj : messages) { if (obj instanceof ChatMessage) { result.add((ChatMessage) obj); } } } return result; } private void trimContextIfNeeded(String key) { // 假设模型最大支持20轮对话40条消息 final long MAX_CONTEXT_LENGTH 40; Long size redisTemplate.opsForList().size(key); if (size ! null size MAX_CONTEXT_LENGTH) { // 移除最旧的消息只保留最新的 MAX_CONTEXT_LENGTH 条 redisTemplate.opsForList().trim(key, size - MAX_CONTEXT_LENGTH, -1); } } // 简单的消息内部类 Data // Lombok注解生成getter/setter等 AllArgsConstructor private static class ChatMessage implements Serializable { private String role; private String content; } }代码解读数据结构选择使用Redis的List非常适合按顺序存储和获取消息序列。rightPush追加新消息range获取最近消息。自动过期通过expire设置键的生存时间TTL自动清理过期会话节省内存。上下文窗口管理trimContextIfNeeded方法确保上下文长度不超过AI模型的最大限制避免API调用失败或成本过高。高性能所有操作都在内存中完成速度极快能支撑高并发下的会话状态读取。5. 性能优化实战系统上线前我们进行了全面的压力测试和优化。负载测试方案与工具工具采用JMeter。模拟从用户打开页面、建立WebSocket连接到连续发送消息的完整场景。场景设计基准测试模拟100个用户持续10分钟评估平均响应时间和资源使用。压力测试逐步增加并发用户至1000观察系统瓶颈CPU、内存、数据库连接、Redis。稳定性测试用500并发持续运行8小时检查内存泄漏和响应时间是否稳定。监控指标应用服务器CPU、内存、GC、数据库连接数、慢查询、Redis内存、命中率、网络带宽。关键性能指标与优化结果对话响应时间 (P95/P99)这是核心体验指标。我们关注第95和第99百分位数。优化前P95约2.5秒P99可能达到5秒以上受AI API延迟影响。优化后通过以下措施P95控制在1.2秒内P99在2.5秒内。AI响应异步化对于可能超过3秒的复杂查询改为异步处理。前端发送消息后立即返回“正在思考…”后端通过WebSocket或轮询在准备好后推送结果。Redis缓存预热将高频的FAQ知识向量提前加载到Redis减少AI生成前的检索时间。数据库查询优化对会话表、日志表建立合适索引避免全表扫描。JVM调优根据负载测试结果调整堆内存大小和GC策略如使用G1垃圾收集器。异步处理长耗时AI任务当用户问题需要深度思考或复杂检索时同步等待不可取。Service public class AsyncDialogueService { Async // 使用Spring的Async注解方法将在独立线程池中执行 public CompletableFutureString handleComplexQuery(String sessionId, String query) { // 1. 进行复杂的知识库检索可能较慢 ListKnowledge relevantKnowledge knowledgeService.deepSearch(query); // 2. 构建更复杂的提示词给AI String enhancedPrompt buildEnhancedPrompt(query, relevantKnowledge); // 3. 调用AI String aiResponse aiGatewayService.callDeepSeekWithCircuitBreaker(enhancedPrompt); // 4. 将最终结果通过WebSocket推送给前端这里需要维护session到连接的映射 websocketService.sendMessageToSession(sessionId, aiResponse); return CompletableFuture.completedFuture(处理完成); } }前端在发送消息后会收到一个taskId然后通过另一个WebSocket频道或轮询接口GET /task/status/{taskId}来获取处理进度和最终结果。6. 生产环境部署指南将系统平稳地运行在生产环境需要关注安全、稳定和可维护性。敏感信息过滤与脱敏输入过滤在对话引擎服务收到用户消息后立即进行敏感词过滤。可以使用AC自动机等高效算法匹配关键词如手机号、身份证号、银行卡号正则模式并进行替换如[电话]或直接拒绝回答。日志脱敏这是重中之重所有写入日志文件或日志系统如ELK的对话内容必须经过脱敏处理。我们使用Logback或Log4j2的Converter机制在日志事件输出前对message字段中匹配的敏感模式进行替换。// 示例一个简单的日志脱敏PatternLayout public class SensitiveDataConverter extends ClassicConverter { private static final Pattern PHONE_PATTERN Pattern.compile((1[3-9]\\d{9})); Override public String convert(ILoggingEvent event) { String message event.getFormattedMessage(); // 对手机号进行脱敏 Matcher matcher PHONE_PATTERN.matcher(message); StringBuffer sb new StringBuffer(); while (matcher.find()) { String phone matcher.group(1); matcher.appendReplacement(sb, phone.substring(0,3) **** phone.substring(7)); } matcher.appendTail(sb); return sb.toString(); } }Kubernetes部署资源配置建议微服务Pod资源请求/限制resources: requests: memory: 512Mi cpu: 250m limits: memory: 1Gi cpu: 500m对话引擎服务CPU请求可设高一些如500m因为它处理逻辑多。AI网关服务内存限制可以适当调高因为它要处理JSON序列化和HTTP连接池。健康检查必须配置livenessProbe和readinessProbe让K8s能感知Pod状态并自动重启或摘除流量。水平扩缩容 (HPA)为对话引擎服务和AI网关服务设置基于CPU利用率的自动扩缩容例如CPU平均使用率超过70%时开始扩容。配置管理将数据库连接串、Redis地址、DeepSeek API Key等敏感配置存入K8sSecret通过环境变量或卷挂载注入切勿写在代码或配置文件中。7. 总结与未来展望通过这个项目我们成功构建了一个响应迅速、理解准确、能够处理复杂对话的AI智能客服系统。Spring Boot和Vue.js的组合提供了高效、稳定的开发体验而DeepSeek的AI能力则是系统的“智能引擎”。未来可以探索的方向多模态交互这是非常有趣的方向。除了文字是否可以支持用户上传图片如产品故障图、语音输入后端需要集成视觉模型如CLIP和语音识别ASR、语音合成TTS服务。架构上需要新增文件上传服务、语音处理服务前端也需要适配新的交互组件。情感识别与应对通过分析用户对话文本的情感倾向积极、消极、愤怒让AI客服能调整回复语气甚至在识别到用户极度不满时自动转接人工提升服务温度。持续学习与知识库自进化系统能否从历史对话中自动挖掘新的QA对经过人工审核后自动补充到知识库或者分析AI回答被用户“踩”的次数自动优化提示词Prompt这需要构建一个模型反馈闭环系统。最后留几个开放性问题供大家思考在微服务架构下如何设计一个全局的、低延迟的会话状态同步机制确保用户在不同服务实例间切换时对话上下文不丢失当集成多个AI模型如DeepSeek用于通用对话专用小模型用于客服领域时如何设计一个智能的路由或调度层根据问题类型选择最合适、最经济的模型对于需要严格合规的行业如金融、医疗AI生成的内容如何实现可审计、可追溯甚至做到“事前拦截”可能不合规的回复