最近在参与一个企业智能客服系统的重构项目之前的老系统一到业务高峰期就卡顿、超时用户体验很差。经过团队几个月的努力我们基于微服务架构完成了一次彻底的升级系统在高并发下的表现有了质的飞跃。今天就把这次实战中的架构设计、技术选型和踩过的“坑”梳理一下希望能给有类似需求的同学一些参考。1. 背景与痛点为什么老系统撑不住了我们之前的系统是一个典型的单体架构所有功能模块用户接入、意图识别、对话管理、知识库查询、工单流转都打包在一个巨大的WAR包里。在用户量不大时运行还算平稳。但随着业务增长尤其是促销活动期间问题集中爆发响应延迟飙升用户发送一条消息前端转圈圈好几秒才有回复高峰期平均响应时间RT从200ms飙升至2s以上。服务雪崩风险一个耗时的知识库深度查询可能拖慢整个应用的线程池导致简单的消息收发都受影响。扩容成本高且不灵活为了应对峰值只能整体扩容应用服务器但大部分时候CPU和内存利用率很低资源浪费严重。技术栈升级困难想引入新的AI模型或消息中间件牵一发而动全身测试和上线风险极高。核心痛点在于耦合性太高和资源无法隔离。这促使我们下决心向微服务架构迁移目标很明确解耦、弹性、可观测。2. 技术选型单体 vs 微服务我们为什么选择后者在立项初期团队内部也有过争论是优化现有的单体应用还是彻底重构成微服务单体架构优化思路优点改动量小初期见效快。可以通过数据库读写分离、引入本地缓存、优化SQL语句等手段提升性能。缺点治标不治本。系统的复杂度会随着代码量增加呈指数级增长可维护性持续下降。性能瓶颈最终会卡在数据库连接池或应用本身。微服务架构重构思路优点彻底解耦每个服务独立开发、部署、伸缩。技术选型更自由例如对话引擎可以用Python而业务服务用Java。容错性更好一个服务故障不易扩散。缺点架构复杂引入了服务发现、配置中心、链路追踪等一系列分布式系统问题。对开发和运维团队的要求更高。考虑到业务的长期发展和团队的技术储备我们最终选择了微服务这条更具扩展性的路。技术栈上我们选择了业界成熟的Spring Cloud Alibaba生态因为它提供了中文文档和活跃的社区与阿里云产品集成也比较好。3. 核心架构设计与实现我们的智能客服微服务集群主要拆分为以下几个核心服务gateway-service (API网关)基于 Spring Cloud Gateway所有外部请求的统一入口。负责路由、鉴权、限流、日志记录。auth-service (认证授权服务)管理客服坐席、企业管理员等角色的登录和权限。session-service (会话服务)核心服务之一管理用户会话的生命周期、状态保持和上下文。nlu-service (自然语言理解服务)调用第三方或自研的AI模型进行意图识别和槽位填充。kb-service (知识库服务)负责向量化检索、FAQ匹配和文档内容查询。dialog-service (对话管理服务)根据NLU的结果和会话历史决定下一步回复策略回答、反问、转人工。agent-service (坐席服务)处理人工坐席的对话分配、监控和交接逻辑。message-service (消息服务)处理消息的持久化、推送和状态同步重度依赖消息队列。关键组件应用细节服务注册与发现使用 Nacos替代了 Eureka因为它同时提供了配置中心功能一举两得。分布式缓存 Redis用途1缓存高频访问的FAQ答案和用户画像减少对数据库和知识库服务的压力。用途2存储分布式会话Session。将会话状态从session-service的内存移至 Redis使得会话服务本身可以无状态化方便水平扩容。我们使用了 Redisson 客户端它提供的分布式锁在“同一用户消息顺序处理”的场景下非常有用。消息队列 Kafka用途1异步解耦消息流。用户消息到达gateway后并不直接同步处理而是发送到一个user-input主题。message-service消费并落库同时触发后续的NLU、对话决策流程。这极大削平了流量峰值避免了同步调用链路过长导致的超时。用途2广播系统通知。例如知识库更新后通过广播消息让所有服务的本地缓存失效。4. 关键代码示例这里展示两个最核心的片段。示例一Gateway 全局过滤器限流与鉴权我们使用 Gateway 的GlobalFilter在路由前进行预处理。Component Slf4j public class AuthGlobalFilter implements GlobalFilter, Ordered { Autowired private RedisTemplateString, String redisTemplate; Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request exchange.getRequest(); String path request.getURI().getPath(); // 1. 公开接口放行如登录 if (isPublicApi(path)) { return chain.filter(exchange); } // 2. 获取并验证Token String token request.getHeaders().getFirst(Authorization); if (StringUtils.isEmpty(token)) { return unauthorizedResponse(exchange, Missing token); } // 3. 从Redis校验Token有效性JWT也可行我们选择Redis便于强制下线 String userId redisTemplate.opsForValue().get(SESSION: token); if (StringUtils.isEmpty(userId)) { return unauthorizedResponse(exchange, Invalid or expired token); } // 4. 将用户信息添加到请求头传递给下游服务 ServerHttpRequest mutatedRequest request.mutate() .header(X-User-Id, userId) .build(); return chain.filter(exchange.mutate().request(mutatedRequest).build()); } Override public int getOrder() { return -100; // 高优先级 } }示例二Session Service 中使用 Redis 存储会话上下文会话状态的管理是关键必须保证读写的高性能和一致性。Service public class SessionServiceImpl implements SessionService { Autowired private RedissonClient redissonClient; Autowired private StringRedisTemplate redisTemplate; private static final String SESSION_KEY_PREFIX CS:SESSION:; Override public ChatSession getOrCreateSession(String sessionId, String userId) { String key SESSION_KEY_PREFIX sessionId; // 使用Redisson的分布式Map存储复杂的会话对象 RMapString, ChatSession sessionMap redissonClient.getMap(key); // 尝试获取现有会话 ChatSession session sessionMap.get(userId); if (session null) { // 创建新会话 session new ChatSession(); session.setSessionId(sessionId); session.setUserId(userId); session.setStartTime(System.currentTimeMillis()); session.setContext(new HashMap()); // 对话上下文 // 存入Redis并设置TTL为30分钟会话不活跃则过期 sessionMap.put(userId, session); sessionMap.expire(30, TimeUnit.MINUTES); log.info(Created new session: {} for user: {}, sessionId, userId); } else { // 每次访问刷新过期时间 sessionMap.expire(30, TimeUnit.MINUTES); } return session; } Override public void updateSessionContext(String sessionId, String userId, String key, Object value) { String mapKey SESSION_KEY_PREFIX sessionId; // 使用分布式锁确保更新上下文时的线程安全尤其在机器人多轮对话时 RLock lock redissonClient.getLock(mapKey :LOCK); try { lock.lock(3, TimeUnit.SECONDS); // 尝试获取锁最多等3秒 RMapString, ChatSession sessionMap redissonClient.getMap(mapKey); ChatSession session sessionMap.get(userId); if (session ! null) { session.getContext().put(key, value); sessionMap.put(userId, session); // 写回 } } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } } } }5. 性能优化与压测结果架构搭好后我们使用 JMeter 进行了多轮压力测试。第一轮基准测试直接压测发现gateway和kb-service知识库查询是瓶颈。Gateway 线程池配置不足KB 服务向量检索耗时。优化措施Gateway调优调整reactor-netty工作线程数为 CPU 核心数 * 2。启用响应式缓存对静态路径进行缓存。KB服务优化为知识库的向量索引增加一层本地缓存Caffeine缓存热点问题。将复杂的查询语句进行预编译和优化。Redis优化使用连接池避免频繁创建连接。对存储的大对象进行压缩例如使用 Snappy。JVM调优为关键服务如session-service,dialog-service设置合理的堆大小和GC参数采用G1垃圾回收器。第二轮全链路压测模拟高峰流量持续30分钟。结果在单服务实例配置下4C8G系统成功支撑了每秒 1000 的对话请求QPS平均响应时间RT稳定在150ms 以内错误率低于0.1%。对比相比原来的单体系统峰值QPS 200RT 2s性能提升了一个数量级。6. 生产环境避坑指南上线后我们遇到了几个典型问题这里分享出来消息顺序问题用户快速发送多条消息由于 Kafka 分区和多个消费者实例的存在可能导致后发的消息先被处理。解决方案将同一会话 ID 的消息通过 Key 路由到 Kafka 的同一个分区确保分区内消息有序。在消费端使用基于会话 ID 的分布式锁如上面代码所示来串行处理同一会话的消息。缓存穿透与雪崩知识库查询时对于不存在的问题如乱码频繁查询数据库。解决方案使用布隆过滤器Bloom Filter预先过滤掉肯定不存在的Key。对于空结果也进行短时间缓存如2分钟。同时为不同的缓存Key设置随机的过期时间避免大量缓存同时失效。服务间超时设置初期服务间 Feign 调用超时时间设置过长默认10秒导致一个慢服务拖垮整个调用链。解决方案根据压测结果和业务重要性为每个下游服务设置合理的连接超时ConnectTimeout和读取超时ReadTimeout例如分别设置为 1秒 和 3秒并配合 Hystrix 或 Sentinel 实现熔断降级。配置管理混乱微服务配置散落在各个应用的application.yml中修改麻烦。解决方案坚决使用 Nacos 配置中心将环境相关的配置数据库地址、Redis地址和业务开关全部上收。通过RefreshScope实现配置的动态更新。7. 总结与思考这次重构让我们深刻体会到微服务不是银弹它用分布式系统的复杂性换来了系统的弹性、可扩展性和技术多样性。对于智能客服这类有明显流量波峰波谷、且业务模块相对独立的系统来说微服务架构的优势非常明显。未来可以继续优化的方向服务网格Service Mesh考虑引入 Istio将流量管理、安全、可观测性等能力下沉到基础设施层让业务代码更纯粹。全链路灰度发布目前我们的发布还是全量滚动。接下来希望实现基于用户ID或渠道的流量灰度让新模型或策略的上线更平滑。AI能力的深度集成当前NLU和对话管理还是“调用式”集成。未来可以考虑将AI模型服务化通过 gRPC 实现更高性能的通信甚至探索模型的热更新机制。留给读者的思考题在智能客服场景中如何设计一个更高效的“会话上下文”管理方案以支持超长、多天的连续对话如果知识库的数据量达到亿级现有的向量检索方案可能遇到性能瓶颈有哪些进阶的架构或技术选型可以考虑例如分片、专用向量数据库希望这篇从实战中总结的笔记能对你有所帮助。架构演进之路永无止境欢迎一起交流探讨。