大家好我是小陈一个在智能客服领域摸爬滚打了三年的后端工程师。今天想和大家聊聊一个智能客服系统从“能用”到“好用”再到“扛得住”的实战升级之路。相信很多朋友在项目初期系统跑得挺欢一旦用户量上来各种幺蛾子就出来了消息延迟、会话丢失、客服端卡顿…… 这些问题我都踩过坑今天就把这几年的架构优化和避坑经验掰开揉碎了分享给大家。1. 背景痛点当用户涌进来时系统为何“掉链子”刚开始做智能客服时我们用的是最经典的 HTTP 轮询。用户端每隔几秒就问一次服务器“有我的新消息吗” 服务器说“没有。” 如此循环。用户少的时候一切安好。但当在线用户从几百涨到几千、上万时问题就暴露无遗了。响应延迟飙升想象一下每秒有成千上万个“无效”的请求在问“有新消息吗”服务器大部分时间都在处理这些“无效询问”真正需要推送消息时资源可能已经被占满导致消息推送严重延迟。用户感觉就是“我发了消息半天才显示已读”。会话状态管理混乱早期我们把会话状态比如用户和哪个客服在聊天、聊到哪了存在单机内存里。一旦这台机器重启或者负载均衡把用户请求打到另一台机器用户的聊天上下文就全丢了体验极差。资源浪费严重大量的轮询请求即使没有数据也消耗着网络带宽、CPU和连接数。QPS每秒查询率看着很高但有效业务请求占比很低性价比太差。2. 技术选型为什么是 WebSocket 和事件驱动为了解决轮询的弊端我们调研了几种方案短轮询简单粗暴但延迟高、资源浪费大直接Pass。长轮询比短轮询好一些服务器在有数据时才响应但每个请求仍然要建立和断开HTTP连接开销不小且连接保持时间有限。WebSocket浏览器与服务器之间建立一条全双工、长连接的通道。连接建立后双方可以随时主动发送数据无需频繁握手。这才是实时通信的“亲儿子”。我们做了简单的压测对比单机4核8G环境短轮询1秒一次支撑约 1500 并发用户时CPU占用率已超70%平均响应时间 2秒。长轮询30秒超时支撑约 3000 并发用户但连接管理复杂容易出现超时重连风暴。WebSocket支撑约8000持久连接消息推送延迟稳定在50ms以内CPU占用率约40%。数据说明一切。事件驱动架构自然成为我们的选择。核心思想是连接即事件消息即事件。系统不再被动轮询而是基于连接事件建立、关闭和消息事件进行响应资源利用率高实时性极佳。3. 核心实现从单机到分布式的关键代码3.1 Spring Boot WebSocket 双向通信Spring 提供了强大的 WebSocket 支持集成起来非常方便。首先引入依赖dependency groupIdorg.springframework.boot/groupId groupIdspring-boot-starter-websocket/groupId /dependency然后配置 WebSocket 端点import org.springframework.context.annotation.Configuration; import org.springframework.web.socket.config.annotation.EnableWebSocket; import org.springframework.web.socket.config.annotation.WebSocketConfigurer; import org.springframework.web.socket.config.annotation.WebSocketHandlerRegistry; Configuration EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { // 注册处理器并指定连接路径。setAllowedOrigins(“*”) 生产环境请替换为具体域名 registry.addHandler(myWebSocketHandler(), “/ws/chat”) .setAllowedOrigins(“*”); } Bean public MyWebSocketHandler myWebSocketHandler() { return new MyWebSocketHandler(); } }接下来是核心的消息处理器。这里我们使用MessageMapping注解它类似于 Spring MVC 的RequestMapping用于处理客户端发送来的消息。import org.springframework.messaging.handler.annotation.MessageMapping; import org.springframework.messaging.handler.annotation.Payload; import org.springframework.messaging.simp.SimpMessagingTemplate; import org.springframework.stereotype.Controller; import lombok.extern.slf4j.Slf4j; import javax.annotation.Resource; /** * WebSocket message controller * WebSocket 消息控制器 */ Controller Slf4j public class ChatController { Resource private SimpMessagingTemplate messagingTemplate; /** * Handle message sent from client to a specific destination (e.g., /app/chat) * 处理从客户端发送到特定目的地如 /app/chat的消息 * param chatMessage the message payload 消息载荷 */ MessageMapping(“/chat”) public void handleChatMessage(Payload ChatMessage chatMessage) { log.info(“Received message: {} from user: {}”, chatMessage.getContent(), chatMessage.getSenderId()); // Business logic: save to DB, assign to agent, etc. // 业务逻辑保存到数据库分配给客服等 // Send message to the specific user‘s subscription channel // 将消息发送到特定用户订阅的频道 String destination “/topic/user/” chatMessage.getReceiverId(); messagingTemplate.convertAndSend(destination, chatMessage); } }前端连接示例JavaScript:const socket new WebSocket(‘ws://your-domain/ws/chat’); socket.onopen function() { console.log(‘连接已建立’); }; socket.onmessage function(event) { console.log(‘收到消息:’, event.data); }; // 发送消息注意Spring MessageMapping 需要消息体符合STOMP格式或自定义协议 // 通常我们会使用SockJS和STOMP客户端库来简化3.2 分布式会话状态保持Redis 来帮忙单机内存存储会话状态是死路一条。我们选择用Redis作为分布式会话存储。关键不是存而是设计存储结构。用户-连接映射快速找到用户当前的 WebSocket 连接在哪台服务器上。Key:ws:user:session:{userId}Value:{“serverId”: “app-server-01”, “sessionId”: “abc123”}TTL: 设置比心跳超时时间稍长比如 5 分钟。会话上下文存储保存当前对话的上下文用于智能客服的意图理解或人工客服的聊天记录快照。Key:chat:context:{sessionId}Value:JSON 对象包含最近N条消息、用户信息、客服ID、状态等TTL: 根据会话生命周期设置例如闲置30分钟后过期。当消息需要推送给某个用户时系统先查 Redis 中的ws:user:session:{userId}得到该用户连接所在的服务器ID (serverId)。如果本机就是那台服务器直接通过本地SimpMessagingTemplate推送如果不是则需要通过内部 RPC 或消息队列如 RabbitMQ/Kafka将消息转发到目标服务器上去推送。这就是所谓的“有状态连接路由”。4. 性能优化压测与调优架构搭好了不代表高枕无忧。性能是调优出来的。压力测试数据JMeter 我们使用 JMeter 模拟了 10000 个用户建立 WebSocket 连接并持续发送和接收小消息1KB以内的场景。优化前默认Tomcat配置Redis 单节点连接建立阶段大量超时建立完成后平均消息往返延迟 120ms95% 线在 300ms。优化后调优后配置Redis 集群连接建立成功率达 99.5%平均消息往返延迟35ms95% 线在80ms以内。连接池与线程池参数调优建议Tomcat (Spring Boot 内嵌)在application.yml中调整。server: tomcat: max-connections: 10000 # 最大连接数 max-threads: 200 # 处理请求的最大线程数不宜过大 min-spare-threads: 10WebSocket 子协议缓冲区适当增大避免频繁扩容。spring: websocket: send-buffer-size: 81920 # 发送缓冲区大小 receive-buffer-size: 81920 # 接收缓冲区大小Redis 连接池 (Lettuce)spring: redis: lettuce: pool: max-active: 16 # 根据应用服务器数量调整 max-idle: 8 min-idle: 25. 避坑指南那些年我们踩过的“坑”心跳机制配置误区 WebSocket 需要心跳来保活并探测连接健康度。误区是只在客户端发心跳服务器不回应。正确做法是双向心跳。服务器端也要定时检查连接对于超时未收到任何心跳或数据的连接主动关闭并清理 Redis 中的会话映射。我们用的是每 30 秒一次心跳超时 90 秒断开。消息幂等性处理 网络不稳定可能导致客户端重复发送同一条消息。如果消息是“下单”、“支付”这类指令重复处理就出大事了。我们的方案是客户端为每条业务消息生成一个唯一msgId服务器端用 Redis Set 或 String设置短TTL记录最近几分钟处理过的msgId。收到消息时先查重已处理则直接返回成功不做业务处理。Nginx 反向代理的 WebSocket 超时设置 Nginx 默认的proxy_read_timeout是 60s对于长连接的 WebSocket 可能不够。必须显式配置location /ws/ { proxy_pass http://backend_server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection “upgrade”; # 关键设置长连接超时时间 proxy_read_timeout 3600s; # 1小时 proxy_send_timeout 3600s; }否则连接会在闲置一分钟后被 Nginx 无情切断。6. 总结与展望经过这一系列的架构改造和优化我们的智能客服系统终于能够从容应对每天数十万的活跃用户和高峰期的并发冲击。从轮询到 WebSocket从单机状态到 Redis 分布式会话从默认配置到精细化调优每一步都是对系统稳定性和用户体验的深入思考。当然技术没有终点。随着业务发展我们又开始面临新的挑战比如用户可能在网页、APP、小程序等多个渠道间切换如何设计一个跨渠道的、无缝的会话上下文同步方案保证用户无论从哪里进来客服都能看到完整的对话历史这是一个很有意思的架构设计问题涉及到更复杂的状态同步、消息队列和最终一致性保障。抛砖引玉我的初步思路是建立一个以userId为核心的全局会话上下文服务所有渠道的消息都汇聚于此并通过事件总线同步到各个渠道的在线连接上。但这其中消息顺序、冲突解决、性能开销都是需要仔细权衡的点。你有什么好的想法或实践经验吗欢迎一起讨论。参考资料可搜索“分布式会话管理”、“CQRS模式”、“事件溯源”等关键词或许能带来灵感。