今天想和大家聊聊智能客服系统的架构实战。我们团队最近刚把一个老的单体客服系统重构为微服务架构主要就是为了应对大促期间的高并发访问。整个过程踩了不少坑也积累了一些经验在这里做个梳理和分享。先说说我们遇到的痛点。原来的系统一到流量高峰响应就变得特别慢用户排队等待时间长体验很差。这背后主要是几个问题一是所有请求都挤在一个应用里数据库连接很快被耗尽二是用户和客服的会话状态都放在应用内存里一旦重启就全丢了三是AI意图识别的模型推理比较耗时会阻塞整个请求链路。所以我们的核心目标就是构建一个高可用、可水平扩展、低延迟的智能客服系统。基于这些目标我们设计了一套分层微服务架构。整个架构图可以清晰地分为四层接入层这是流量的入口我们使用了Nginx做反向代理和负载均衡。为了处理海量的WebSocket长连接用于实时消息我们引入了Netty集群。这一层主要负责协议的转换、连接的保持以及初步的限流和鉴权。业务逻辑层这是核心的微服务群。我们拆分了几个关键服务会话管理服务负责会话生命周期的管理包括创建、查询、转移和关闭。这是状态管理的核心。消息路由服务接收用户消息根据会话状态和路由规则决定将消息分发给在线客服、机器人或者留言队列。用户/客服信息服务管理用户和客服的基本信息、状态在线、忙碌、离线等。AI引擎层专门处理智能化的部分。我们部署了独立的服务来调用NLP模型进行意图识别和情感分析还有一个知识库检索服务用于从FAQ库中快速匹配答案。这一层与业务层通过RPC或异步消息解耦避免阻塞主流程。数据层数据存储也做了拆分。会话和消息记录这类写多读多的数据我们放到了MongoDB利用其文档模型的灵活性。用户关系、配置信息等结构化数据依然用MySQL。缓存方面Redis是绝对的主力用于存储会话状态、热点数据和分布式锁。在组件选型上消息队列的选择让我们纠结了一阵主要是在Kafka和RabbitMQ之间。最终我们根据场景做了混合使用Kafka用于处理日志型、吞吐量要求极高的数据流。比如所有用户消息的持久化、操作日志的收集我们都会发到Kafka由下游的分析服务消费。它的高吞吐和持久化能力非常适合这种场景。RabbitMQ用于处理业务逻辑型的消息分发。比如当消息路由服务判定一条消息需要分配给某个特定的客服坐席时就会向该客服专属的队列发送消息。RabbitMQ的灵活路由Exchange、Queue绑定、消息确认机制和相对易用的特性在这里更合适。接下来看看几个核心的实现细节。首先是会话状态管理我们用Spring Cloud微服务来实现。关键是如何在分布式环境下保证一个会话的状态一致。我们定义了一个Session实体核心状态如sessionId、userId、agentId分配的客服、status进行中、等待中、已结束等会持久化到MongoDB。但同时为了提高实时查询效率会话的简要状态如sessionId - agentId的映射会缓存到Redis并设置合理的过期时间。// 会话管理服务关键代码示例 Service Slf4j public class SessionServiceImpl implements SessionService { Autowired private RedisTemplateString, String redisTemplate; Autowired private MongoTemplate mongoTemplate; private static final String SESSION_KEY_PREFIX session:active:; private static final long SESSION_TTL_SECONDS 3600L; // 1小时 Override public Session createSession(String userId) { String sessionId generateSessionId(); Session session new Session(sessionId, userId, SessionStatus.WAITING); // 1. 持久化到MongoDB mongoTemplate.save(session); // 2. 关键状态写入Redis缓存设置TTL String cacheKey SESSION_KEY_PREFIX sessionId; MapString, String cacheMap new HashMap(); cacheMap.put(userId, userId); cacheMap.put(status, session.getStatus().name()); redisTemplate.opsForHash().putAll(cacheKey, cacheMap); redisTemplate.expire(cacheKey, SESSION_TTL_SECONDS, TimeUnit.SECONDS); log.info(Session created: {}, sessionId); return session; } Override public Session getSession(String sessionId) { // 优先从缓存查询 String cacheKey SESSION_KEY_PREFIX sessionId; MapObject, Object cacheEntries redisTemplate.opsForHash().entries(cacheKey); if (!cacheEntries.isEmpty()) { // 缓存命中构建对象返回 (简化) return buildSessionFromCache(sessionId, cacheEntries); } // 缓存未命中回源查数据库 return mongoTemplate.findById(sessionId, Session.class); } }在高并发下同一个用户短时间内可能发起多次创建会话的请求。为了避免创建出多个重复会话我们需要使用分布式锁来保证操作的原子性。// 使用Redis实现分布式锁确保会话创建幂等 public Session createSessionWithLock(String userId) { String lockKey lock:create_session: userId; String requestId UUID.randomUUID().toString(); // 唯一标识本次请求用于安全释放锁 long expireTime 3000L; // 锁持有时间3秒 try { // 尝试获取锁使用SET NX EX命令保证原子性 Boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, requestId, expireTime, TimeUnit.MILLISECONDS); if (Boolean.TRUE.equals(locked)) { // 获取锁成功执行核心业务逻辑 // 再次检查是否已存在活跃会话双重检查 Session existing findActiveSessionByUser(userId); if (existing ! null) { return existing; } return createSession(userId); } else { // 获取锁失败说明有其他请求正在处理可等待重试或直接返回“操作频繁”提示 throw new BusinessException(请求过于频繁请稍后再试); } } finally { // 释放锁时使用Lua脚本保证判断请求标识和删除的原子性避免误删其他请求的锁 String luaScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; DefaultRedisScriptLong redisScript new DefaultRedisScript(luaScript, Long.class); redisTemplate.execute(redisScript, Collections.singletonList(lockKey), requestId); } }架构搭好了代码写完了性能优化才是真正考验人的地方。我们主要从以下几个方面入手连接池优化数据库MySQL、MongoDB和Redis的连接池参数必须精心调优。我们根据压测结果设置了合适的最大连接数、最小空闲连接数和获取连接的超时时间避免连接数不足导致等待或过多连接拖垮数据库。缓存策略深化除了会话状态我们将客服的繁忙状态、常用问答对、路由规则等都放入了Redis。并且采用了不同的过期策略会话状态是短期热点设置较短TTL静态规则可以设置较长TTL或不过期。同时注意缓存穿透用空值缓存和雪崩过期时间加随机值问题。全链路异步化这是降低响应延迟的关键。用户发送消息后接入层立刻ACK消息被放入RabbitMQ。消息路由服务异步消费处理路由逻辑。如果需要调用AI引擎也是通过异步RPC或消息队列绝不阻塞主线程。整个流程通过唯一的traceId串联日志方便追踪。压测是优化效果的试金石。我们使用JMeter模拟了从几千到上万用户同时在线咨询的场景。通过调整线程池大小、JVM堆内存、GC参数以及观察微服务的CPU、内存和GC日志逐步将平均响应时间从最初的几百毫秒优化到了50毫秒以内。监控告警体系也随之建立对API响应时间、错误率、队列堆积长度等关键指标进行实时监控。最后分享几个我们踩过的“坑”希望大家能避开会话超时处理不要只在客户端做超时判断。我们最初只在浏览器端设置30分钟无操作断开结果网络波动导致心跳失败服务端会话还活着状态就错乱了。后来改为客户端心跳 服务端定时扫描双重机制。服务端用一个定时任务定期检查Redis中会话的最后活跃时间超时的会话执行清理逻辑如保存记录、通知用户。分布式幂等性消息队列消费、接口重试都可能带来重复请求。我们要求所有写操作创建会话、分配客服、更新状态的接口都必须支持幂等。通用的做法是让客户端携带一个唯一请求ID如requestId服务端在处理前先查一下Redis中这个requestId是否已处理过。降级策略当AI引擎服务响应慢或不可用时不能让它拖垮整个聊天链路。我们设置了熔断器如Resilience4j当失败率达到阈值就快速失败并降级到基于规则的关键词匹配或者直接提示用户“当前咨询人数较多请稍后”。核心原则是有损服务但保证基本功能可用。整个项目做下来一个深刻的体会是架构设计没有银弹都是在做权衡。比如为了极致的实时性我们可能会把更多状态放在内存缓存但这又增加了数据不一致的风险和内存成本。如何根据业务特点在实时性、一致性、系统资源消耗之间找到最佳平衡点是一个需要持续思考和优化的问题。大家在实际项目中又是如何权衡的呢