电商智能客服系统设计实战：高并发场景下的架构演进与避坑指南-编程实验室

背景痛点：大促零点，客服先崩

去年双11，我们组第一次独立扛智能客服。凌晨 0:03，峰值 QPS 冲到 4.8 w，系统直接“哑巴”：

会话状态丢失：用户刚问“优惠券怎么用”，刷新页面后机器人重新说“亲，在的～”，体验瞬间归零。
意图识别延迟：模型在本地 JVM 缓存，一台机器被 2 k 并发打满，TP99 飙到 3 s，客服群里骂声一片。
横向扩容无效：无脑加 Pod，结果 Redis 连接数先爆，数据库连接池紧随其后，雪崩得整整齐齐。

痛定思痛，我们决定把“单体+规则”彻底拆掉，用微服务 + 事件驱动重新设计一套能扛住 10 w 并发的智能客服。

技术选型：规则引擎 vs ML 模型，为啥还上微服务？

规则引擎
适合固定问答，比如“发货时间”、“退货地址”。优势：毫秒级返回、无需 GPU、可解释性强；劣势：多轮对话一复杂，规则指数级膨胀，维护成本爆炸。
ML 模型（BERT+CRF）
适合意图漂移大、口语化表达，比如“俺的包裹搁哪儿啦”。优势：泛化好，用户越聊越准；劣势：计算重、冷启动慢、需要 GPU 池。
架构理由
把“热规则”与“冷模型”拆成独立服务：
- 规则服务：无状态，横向扩容秒级完成。
- 模型服务：GPU 节点单独池化，按需弹性。
  再用微服务框架，统一注册、熔断、限流，谁慢谁扩容，互不拖累。

核心实现：三板斧落地

1. 服务发现与负载均衡（Spring Cloud 2021.x）

# application.yml spring: application: name: chat-rule cloud: nacos: discovery: server-addr: nacos:8848 metadata: version: 1.0.0 config: server-addr: nacos:8848 file-extension: yaml server: port: 8081

消费端使用@LoadBalancedRestTemplate，默认轮询，也可在 metadata 里打标签做灰度。

2. Redis 分布式会话（含 TTL、集群配置）

/** * 分布式会话仓库 */ @Component public class ChatSessionRepository { private static final String KEY_PREFIX = "chat:session:"; private static final Duration TTL = Duration.ofMinutes(30); @Resource private StringRedisTemplate redisTemplate; /** * 保存会话，带 TTL */ public void save(ChatSession session) { String key = KEY_PREFIX + session.getUserId(); redisTemplate.opsForValue().set(key, JSON.toJSONString(session), TTL); } /** * 读取会话 */ public ChatSession get(String userId) { String json = redisTemplate.opsForValue().get(KEY_PREFIX + userId); return json == null ? null : JSON.parseObject(json, ChatSession.class); } }

集群层面开启redis-cluster，max-redirects=3，业务代码零改动；同时把key按{userId}做哈希，保证同一用户固定到同一 slot，避免moved重定向放大延迟。

3. 事件驱动架构（Kafka）

用户提问 → 规则服务命中则直接返回；未命中发ChatMsgEvent到 Kafka。
模型服务消费 → 异步推理 → 回写ReplyEvent→ WebSocket Gateway 推回前端。
所有事件统一 Avro 序列化，Schema 注册到 Confluent，兼容字段演进。

性能优化：让 TP99 稳定在 500 ms 以内

压测对比
单机 8C16G：峰值 1.2 w QPS，CPU 96%，TP99 1.8 s
10 台同等规格集群：峰值 10 w QPS，CPU 55%，TP99 380 ms
结论：水平扩容有效，但前提是“无状态 + 分布缓存”。
对话上下文压缩
用户多轮对话最长保留 10 句，超过后使用LZ4压缩历史，再存 Redis。
实测 1 k 文本压缩后 ≈ 280 byte，网络 IO 降 70%，解析耗时增加 < 2 ms，可忽略。
本地短缓存
规则服务把“最热 100 问答”缓存到 Caffeine，命中率 42%，进一步把 TP10 压到 30 ms。

避坑指南：那些半夜踩过的雷

分布式锁
早期用SETNX + expire，进程宕机造成死锁。
后来改成 RedissonRLock，自动续期，外加tryLock(3s, 10s)防止线程饥饿。
锁粒度按“用户维度”而非“全局”，把竞争面降到最小。
冷启动降级
模型容器首次拉镜像 + 加载权重需 90 s，期间全部流量回退到规则服务。
实现：K8s readinessProbe 检测/model/ready接口，返回 false 则摘除流量；同时模型服务启动后异步预热 GPU，ready 后再注册到注册中心。
大 Key 热 Key
促销期间“同款商品”被集中咨询，导致单个 Redis Key 达到 3 MB，网卡被打满。
解决：把“商品 FAQ”拆成哈希，分散到 64 个子 Key，再本地缓存，热 Key 问题消失。