开源智能客服系统架构解析：从选型到高并发实战-开发者社区

开源智能客服系统架构解析：从选型到高并发实战

背景痛点：智能客服的三座大山

做客服系统最怕的不是“答非所问”，而是“答了也白答”。线上踩坑三年，我把最痛的点总结成三座大山：

消息乱序：用户连发三条消息“我要退货”“订单号 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 次，零会话丢失。