最近在做一个智能客服系统的项目从零开始踩了不少坑也积累了一些经验。今天就来聊聊如何用 Spring Boot 搭建一个能扛住高并发的智能客服系统从架构设计到最终上线希望能给有同样需求的同学一些参考。1. 为什么需要重构聊聊传统客服的痛点最开始我们接手的是一个老系统用的是最传统的同步请求-响应模式。用户发消息后端直接调用 AI 接口等 AI 返回结果后再回复给用户。听起来很简单对吧但问题很快就暴露了。最头疼的就是同步阻塞。当用户量稍微上来一点比如 QPS每秒查询率超过 50系统响应时间就开始飙升从几百毫秒直接跳到几秒。因为每个请求都在等 AI 模型处理线程被大量占用新用户根本进不来。这就像只有一个收银台的超市高峰期排长队是必然的。其次是扩展性差。业务逻辑、用户状态、对话管理全耦合在一起想加个新功能比如文件上传、满意度评价都像在拆炸弹牵一发而动全身。而且系统状态都放在内存里服务一重启所有用户的对话上下文全丢了用户体验极差。所以我们的目标很明确构建一个高可用、易扩展、能支撑高并发的智能客服系统。下面就来分享我们的实现方案。2. 技术选型为什么是 Spring Boot WebSocket Redis市面上微服务的方案很多比如 Spring Cloud 全家桶或者追求极致性能的 gRPC。但我们最终选择了相对轻量级的 Spring Boot 作为核心框架主要基于以下几点考虑Spring Boot生态成熟开箱即用能快速搭建 RESTful API 和 WebSocket 服务非常适合我们这种需要快速迭代验证的业务场景。WebSocket这是实现实时对话的关键。相比 HTTP 轮询WebSocket 能建立全双工的长连接消息可以主动推送延迟极低非常适合聊天这种交互。Redis我们需要一个高性能的缓存和会话存储中心。Redis 的丰富数据结构如 String, Hash, List非常适合存储用户状态、对话历史和限流信息而且读写速度极快。为什么不直接用 Spring Cloud因为我们初期业务复杂度还没到需要服务注册发现、配置中心的地步Spring Boot 的单体应用足够支撑后期如果需要再向微服务演进也不迟。gRPC 虽然性能好但对前端Web支持不如 WebSocket 友好开发调试成本也更高。所以Spring Boot WebSocket Redis这个组合在开发效率、性能和维护成本上取得了很好的平衡。3. 核心实现三层架构与关键代码我们采用了经典的分层架构将系统划分为接入层、业务层和 AI 层职责清晰便于维护和扩展。接入层负责与客户端Web、App建立并维护 WebSocket 连接处理最基础的消息收发和连接管理。业务层这是核心负责对话逻辑、用户状态管理、消息路由、敏感词过滤等所有业务规则。AI 层专门负责与第三方 NLP自然语言处理服务或自研模型进行交互处理意图识别和回复生成。下面看看几个关键点的代码实现。1. JWT 鉴权实现用户连接 WebSocket 时需要先通过 HTTP 接口登录获取 Token连接时携带 Token 进行验证。Component public class JwtTokenProvider { // 密钥应从配置中心读取 private String secretKey your-secret-key; // 生成Token public String generateToken(String username) { Date now new Date(); Date validity new Date(now.getTime() 3600000); // 1小时有效期 return Jwts.builder() .setSubject(username) .setIssuedAt(now) .setExpiration(validity) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); } // 验证Token public boolean validateToken(String token) { try { Jwts.parser().setSigningKey(secretKey).parseClaimsJws(token); return true; } catch (JwtException | IllegalArgumentException e) { // 记录日志Token无效或过期 return false; } } // 从Token中获取用户名 public String getUsername(String token) { Claims claims Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token) .getBody(); return claims.getSubject(); } }在 WebSocket 握手拦截器中我们校验这个 Token确保连接安全。2. 消息队列削峰与异步处理为了避免 AI 服务响应慢拖垮整个系统我们引入了消息队列这里用 Redis 的 List 模拟进行削峰填谷。用户消息先入队由独立的消费者线程池异步处理。Service public class MessageQueueService { Autowired private StringRedisTemplate redisTemplate; private static final String MESSAGE_QUEUE_KEY chat:msg:queue; // 生产者用户消息入队 public void pushMessage(ChatMessage message) { String msgJson JSON.toJSONString(message); // 使用Fastjson或Jackson redisTemplate.opsForList().rightPush(MESSAGE_QUEUE_KEY, msgJson); } // 消费者从队列中取出消息处理通常由Scheduled或独立线程执行 Scheduled(fixedDelay 100) // 每100毫秒尝试消费一次 public void consumeMessage() { String msgJson redisTemplate.opsForList().leftPop(MESSAGE_QUEUE_KEY); if (msgJson ! null) { ChatMessage message JSON.parseObject(msgJson, ChatMessage.class); // 调用业务层处理消息如调用AI服务、保存记录等 processMessageAsync(message); } } Async // 使用Spring的Async实现异步调用 public void processMessageAsync(ChatMessage message) { // 具体的消息处理逻辑 } }这样即使瞬间涌入大量消息也会在队列中排队由后台线程按处理能力消费实现了背压机制保护了核心业务逻辑。3. 对话状态机设计为了管理复杂的对话流程比如转人工、满意度调查我们设计了一个简单的状态机。public enum ConversationState { INIT, // 初始状态 CHATTING_WITH_AI, // 与AI对话中 WAITING_FOR_AGENT, // 等待人工客服 CHATTING_WITH_AGENT, // 与人工对话中 SURVEY // 满意度调查中 } Service public class ConversationStateService { Autowired private StringRedisTemplate redisTemplate; // 获取或初始化用户对话状态 public ConversationState getOrInitState(String sessionId) { String key chat:session: sessionId :state; String stateStr redisTemplate.opsForValue().get(key); if (stateStr null) { // 初始状态为与AI对话 redisTemplate.opsForValue().set(key, ConversationState.CHATTING_WITH_AI.name()); return ConversationState.CHATTING_WITH_AI; } return ConversationState.valueOf(stateStr); } // 状态转移 public boolean transferState(String sessionId, ConversationState from, ConversationState to) { String key chat:session: sessionId :state; // 使用Redis的CAS操作确保状态转移的原子性 return redisTemplate.execute((RedisCallbackBoolean) connection - { connection.watch(key.getBytes()); String currentState new String(connection.get(key.getBytes())); if (from.name().equals(currentState)) { connection.multi(); connection.set(key.getBytes(), to.name().getBytes()); ListObject results connection.exec(); return results ! null !results.isEmpty(); } connection.unwatch(); return false; }); } }通过状态机我们能清晰地控制对话流程避免逻辑混乱。4. 性能优化让系统跑得更快更稳高并发下每一个细节的优化都可能带来显著的性能提升。Redis管道Pipeline技术在需要批量操作 Redis 的场景比如一次性获取多个用户的最后活跃时间使用管道可以大幅减少网络往返时间RTT。public ListObject batchGetUserStatus(ListString userIds) { return redisTemplate.executePipelined((RedisCallbackObject) connection - { for (String userId : userIds) { String key user:status: userId; connection.get(key.getBytes()); } return null; // 返回值在回调中不使用 }); }数据库连接池配置详解数据库连接是宝贵资源配置不当容易成为瓶颈。以 HikariCP 为例生产环境需要仔细调优。spring: datasource: hikari: maximum-pool-size: 20 # 根据数据库和服务器配置调整通常建议CPU核心数 * 2 有效磁盘数 minimum-idle: 10 # 最小空闲连接数可设置为maximum-pool-size的一半 connection-timeout: 30000 # 连接超时时间(ms)网络不好可适当调大 idle-timeout: 600000 # 空闲连接存活时间(ms)10分钟 max-lifetime: 1800000 # 连接最大生命周期(ms)30分钟避免数据库端连接僵死 connection-test-query: SELECT 1 # 连接测试查询语句关键是要监控连接池的使用情况避免连接泄露或耗尽。5. 避坑指南那些我们踩过的“坑”对话上下文丢失问题这是智能客服的“灵魂”。我们最初把上下文存在服务器的 Map 里重启就没了。解决方案是将会话上下文最近N轮对话序列化后存入 Redis并设置合理的过期时间如30分钟。每次用户新消息到来时先加载上下文处理完后再更新回去。注意保证读写上下文的原子性避免并发问题。敏感词过滤优化简单的循环匹配在长文本下效率很低。我们优化为使用DFA确定有限状态自动机算法构建敏感词树实现一次扫描完成多模式匹配效率极高。对于特别复杂的模式可以结合正则表达式但要对正则进行预编译避免每次匹配都编译。Component public class SensitiveWordFilter { private Map sensitiveWordMap; // 初始化好的DFA词库 public String filter(String text) { // DFA匹配逻辑... // 将匹配到的词替换为* return processedText; } }6. 生产环境部署检查清单系统上线前这些检查项必不可少。健康检查接口除了 Spring Boot Actuator 提供的/actuator/health我们自定义了一个深度健康检查接口/health/detail检查核心依赖状态。RestController RequestMapping(/health) public class HealthCheckController { Autowired private RedisTemplate redisTemplate; Autowired private DataSource dataSource; GetMapping(/detail) public MapString, String detailHealthCheck() { MapString, String health new HashMap(); // 检查Redis try { redisTemplate.getConnectionFactory().getConnection().ping(); health.put(redis, UP); } catch (Exception e) { health.put(redis, DOWN - e.getMessage()); } // 检查数据库 try (Connection conn dataSource.getConnection()) { health.put(database, UP); } catch (Exception e) { health.put(database, DOWN - e.getMessage()); } // 检查磁盘空间、内存等... return health; } }Prometheus 监控指标埋点使用 Micrometer 集成 Prometheus监控关键指标。在pom.xml中引入micrometer-registry-prometheus依赖。配置应用暴露/actuator/prometheus端点。在代码中埋点例如记录消息处理耗时和数量Service public class MessageService { // 定义计数器处理的消息总数 private final Counter messageCounter Metrics.counter(chat.message.processed.total); // 定义计时器消息处理耗时 private final Timer messageProcessTimer Metrics.timer(chat.message.process.duration); public void processMessage(Message msg) { // 使用计时器记录处理时间 messageProcessTimer.record(() - { // 实际处理逻辑 // ... // 处理成功计数器1 messageCounter.increment(); }); } }这样就能在 Grafana 中绘制出漂亮的图表实时观察系统状态。写在最后通过这一套组合拳下来我们的智能客服系统终于能平稳应对日常的流量高峰了。从架构设计到代码实现再到性能调优和生产部署每一步都需要仔细考量。技术选型没有银弹适合自己的才是最好的。最后留一个开放性问题给大家思考我们目前的设计是基于单一渠道比如Web的会话保持。如果要设计一个跨渠道例如用户从Web端咨询到一半又切换到手机App的会话保持方案该如何设计呢需要考虑用户身份的统一识别、上下文数据的同步、以及各端连接状态的管理这又是一个有趣的挑战。欢迎大家在评论区分享你的想法。