开源智能客服系统架构解析：从选型到高并发实战
背景痛点：智能客服的三座大山
做客服系统最怕的不是“答非所问”，而是“答了也白答”。线上踩坑三年，我把最痛的点总结成三座大山：
- 消息乱序：用户连发三条消息“我要退货”“订单号 123”“算了不退了”，如果服务端先处理第三条，客服机器人会直接回“好的，已为您取消退货”，用户当场爆炸。
- 意图识别延迟：高峰期 3000 条/秒进线，BERT 模型在 GPU 上排队 200 ms，前端超时 500 ms 就重试，结果同样一句话被识别三次，后台雪崩。
- 横向扩展困难：单实例 QPS 到 800 就顶不住，加机器却发现会话粘在多节点，Redis 里 30 万条分布式锁，CPU 空跑 40%。
不把这仨搞定，别谈“智能”，先谈“能用”。
技术选型：Rasa、Dialogflow 与“国产小分队”
中文场景下，开源方案里呼声最高的是 Rasa、Dialogflow 社区版，以及国内开源的 LAC + PaddleNLU。我们在 4 核 8 G 的同一台压测机上，用 5 万条真实客服日志跑了三次，结论如下：
| 框架 | NER F1 | 意图 Top-1 延迟 | 备注 |
|---|---|---|---|
| Rasa 3.x | 0.87 | 180 ms | 需要 2 G 内存预加载 Spacy zh |
| Dialogflow ES | 0.84 | 120 ms | 免费额度 180 req/min，超量直接 429 |
| LAC+BERT-base | 0.89 | 95 ms | 模型 400 M，TensorRT 推理占 1.2 G 显存 |
数据来源：Rasa 官方 Benchmark 2023、Google Dialogflow SLA 文档、百度 LAC GitHub 首页。
最终我们选了“国产小分队”：LAC 做分词 + 自训 BERT-base 意图模型，原因无他——延迟低、可离线、不担心 GDPR 把数据弄出国。
核心架构：Spring Cloud + RocketMQ 的“三板斧”
整体思路一句话：“先削峰填谷，再水平扩容，最后让 AI 慢慢算。”
- 接入层：Spring Cloud Gateway + Sentinel 做统一限流，令牌桶 2000 QPS 兜底。
- 消息层：RocketMQ 顺序消息，按 userId 做 sharding key，保证同一用户的对话串行处理；官方白皮书（Apache RocketMQ v4.9 Performance Report）显示，单组 broker 可扛 10 w 条/秒，我们压测 3 主 3 从稳稳到 6 w。
- 服务层：
- chat-service：无状态，纯 Java，负责收发包。
- nlp-service：GPU 节点池，批量推理，支持最大 32 条/批，平均延迟 65 ms。
- session-service：维护分布式状态机，Redis Cluster 存储，Lua 脚本保证原子滑动。
代码示例：对话状态机（带超时重试）
下面这段代码跑在生产 90 天无重启，注释直接写进 Google Java Style，CV 即可用。
/** * Finite state machine for single user session. * STATE: INIT -> WAIT_INTENT -> WAIT_SLOT -> CONFIRM -> DONE */ @Component public class ChatStateMachine { private static final long SESSION_TTL_SECONDS = 300L; private static final int MAX_RETRY = 2; @Resource private StringRedisTemplate redis; @Resource private NlpService nlpService; public String onMessage(String userId, String text) { String key = "session:" + userId; BoundHashOperations<String, String, String> ops = redis.boundHashOps(key); ops.expire(SESSION_TTL_SECONDS, TimeUnit.SECONDS); String state = ops.get("state"); if (state == null) state = "INIT"; int retry = Optional.ofNullable(ops.get("retry")).map(Integer::valueOf).orElse(0); switch (state) { case "INIT": ops.put("state", "WAIT_INTENT"); ops.put("text", text); return askIntent(text, ops, retry); case "WAIT_INTENT": if (!text.equals(ops.get("text"))) { // 去重 ops.put("text", text); return askIntent(text, ops, retry); } return "处理中，请稍候……"; // 其余状态略…… default: return "状态未知"; } } private String askIntent(String text, BoundHashOperations<String, String, String> ops, int retry) { try { Intent intent = nlpService.predict(text); ops.put("state", "WAIT_SLOT"); ops.put("intent", intent.getName()); ops.delete("retry"); return intent.getReply(); } catch (Exception ex) { if (retry >= MAX_RETRY) { ops.put("state", "DONE"); return "识别失败，转人工"; } ops.put("retry", String.valueOf(retry + 1)); throw new RetryException(ex); // 由 MQ 重试 } } }要点：
- 用 Redis hash 而不是 string，省 30% 内存。
- 每次 expire 重新设 300 s，解决“用户聊到一半去吃饭”场景。
- 异常抛给 MQ 重试，避免线程池被长尾拖死。
性能优化：把 2000 QPS 压到 60% CPU
JMeter 压测报告
4 台 8 C16 G 节点，2000 并发线程，平均 RT 110 ms，CPU 占用 58%，内存 5.2 G。
线程池参数最终调优结果：corePoolSize=CPU*2=16 maxPoolSize=CPU*4=32 queueCapacity=5000 keepAliveSeconds=60来源：Spring Boot 2.7 官方调优指南 + 实测，队列太小会频繁 reject，太大则 RT 抖动。
Redis 管道优化
多轮对话一次要读 5~7 个 key，用 pipeline 把 7 次 RTT 压成 1 次，整体延迟降 28 ms。
代码片段：List<Object> batch = redis.executePipelined( (RedisCallback<String>) connection -> { connection.stringCommands().get("key1".getBytes()); connection.stringCommands().get("key2".getBytes()); return null; });
避坑指南：敏感词 & K8s 滚动升级
敏感词过滤
不用正则，用 AC 自动机（Aho-Corasick）单次扫描，2 万条敏感词库，长文本 1 M 耗时 12 ms。
开源实现直接用 sensitive-filter 即可，注意把 DFA 序列化到磁盘，重启时 0.8 s 加载完毕。K8s 滚动升级会话迁移
老 Pod 下线前会收到 SIGTERM，我们在 PreStop 里把内存中的会话写回 Redis，延迟 3 s 内完成；
同时 ReadinessProbe 把/ready接口置为 false，Gateway 不再转发新流量，实现“优雅下线”。
升级 20 次，零会话丢失。
生产部署小结
- 鉴权：Gateway 层统一 JWT + OPA，令牌里带 userId，后端无感。
- 降级：nlp-service 超时 400 ms 即熔断，返回“抱歉，没听懂，转人工”。
- 监控：Prometheus + Grafana，核心看“MQ 积压量”“GPU 利用率”“Redis 命中率”三条线，任何一条掉底都立即扩容。
开放问题
消息顺序、横向扩展、意图延迟都解决后，新的挑战来了：
“如何设计跨渠道的会话粘性策略？”
用户可能在微信小程序里问一半，又跑到 PC 网页继续聊，还要保证上下文不丢、不重复、不串号。你有好的思路吗？欢迎留言一起拆坑。
