最近在做一个智能客服系统的重构项目之前的老系统是基于规则引擎的一到业务高峰期就各种“罢工”用户体验很差。经过一番调研和折腾我们最终基于扣子空间搭建了一套新的高可用智能客服系统效果提升非常明显。今天就来和大家分享一下我们的架构设计和实战经验希望能给有类似需求的同学一些参考。1. 为什么必须重构传统客服系统的“阿喀琉斯之踵”我们原来的客服系统核心逻辑都写在规则引擎里。比如用户说“查订单”就触发一堆if-else去数据库捞数据。这套系统在流量平稳时还能应付但有几个致命伤流量雪崩风险一到促销季用户咨询量瞬间暴涨。规则引擎是同步处理大量请求堆积会导致线程池耗尽整个服务雪崩连锁反应拖垮其他关联服务。状态管理地狱多轮对话比如退货流程确认订单-选择原因-填写地址的状态管理非常复杂。用服务器内存存会话状态一旦实例重启或扩容用户对话就断了体验极差。用数据库存每次对话都要查库延迟高数据库压力巨大。扩展性差每加一个新业务比如新增一个“活动咨询”意图就要在规则引擎里写一堆新规则开发和测试周期长维护成本像滚雪球一样越滚越大。正是这些痛点逼着我们寻找新的解决方案。我们的目标是高并发、高可用、易扩展。2. 技术选型为什么是扣子空间在选型阶段我们重点对比了业界主流的几个方案Google的Dialogflow、Amazon的Lex以及国内的扣子空间。Dialogflow/Lex功能强大生态成熟但作为云服务在国内网络环境下稳定性是个挑战且定制化程度深的话成本会比较高。更重要的是它们在应对突发流量的弹性伸缩方面响应速度和成本控制不如我们自主架构灵活。扣子空间它吸引我们的点主要有两个出色的弹性伸缩能力扣子空间底层支持事件驱动和微服务架构可以很方便地与我们自己的K8s集群结合实现秒级扩缩容。这对于应对我们“波峰波谷”明显的咨询流量至关重要。对中文NLP的深度优化相比国外产品扣子空间在中文分词、意图识别、尤其是口语化表达和行业术语比如我们电商领域的“SKU”、“保价”等的理解上准确率明显更高开箱即用效果好减少了我们大量的调优工作。综合考量可控性、成本、性能和对中文场景的适配度我们最终选择了基于扣子空间来构建核心的对话能力而自己掌控整体的系统架构。3. 核心架构设计分层与解耦我们的系统整体采用分层微服务架构下图描绘了核心的数据流与组件交互文字描述一下各层职责与交互时序接入层 (Gateway)使用Nginx作为API网关负责SSL卸载、路由转发、限流和全局JWT鉴权。所有客户端请求首先到达这里。业务聚合层 (BFF)针对不同渠道App、Web、小程序定制了不同的BFFBackend for Frontend服务。它接收网关转发的请求聚合下游多个微服务的调用并处理渠道相关的逻辑比如返回给App的字段可能就和Web端不同。核心服务层 (Microservices)会话管理服务这是大脑。负责创建、维护和销毁对话会话。它采用Redis Cluster 本地缓存Caffeine的二级策略。用户的最新对话状态精简后放在本地缓存保证超低延迟读取完整的对话历史和多轮上下文则持久化到Redis Cluster中保证分布式一致性。通过设置合理的过期时间实现最终一致性。意图识别服务这是核心。封装了对扣子空间NLU引擎的调用。我们不是简单转发请求而是增加了容错降级机制后面会贴代码。当扣子空间服务响应慢或不可用时能快速降级到基于关键词的简易匹配模式保证服务可用性。对话引擎服务根据意图识别结果执行相应的业务流程。比如识别出“查询物流”就去调用订单服务获取物流信息并组织回复话术。这里集成了扣子空间的对话管理模块用于处理复杂的多轮对话流程。知识库服务对接企业内部的FAQ和产品知识库当意图识别为“问答”时从这里获取精准答案。基础设施层包括Redis Cluster会话状态、MySQL业务数据、Kafka异步消息用于记录对话日志、分析用户行为以及监控告警体系Prometheus Grafana。流量调度与负载均衡 在业务聚合层和核心服务层之间我们自研了一个简单的动态负载均衡器采用加权轮询算法根据服务实例的实时CPU负载动态调整权重。以下是Go语言实现的核心代码片段type Server struct { Addr string Weight int Load int // 当前负载如CPU使用率 } type LoadBalancer struct { servers []*Server index int gcd int // 所有权重的最大公约数 } func (lb *LoadBalancer) NextServer() *Server { for { lb.index (lb.index 1) % len(lb.servers) if lb.index 0 { // 一轮结束重新计算动态权重示例权重与负载成反比 totalWeight : 0 for _, s : range lb.servers { dynamicWeight : 100 - s.Load // 简化计算负载越高权重越低 if dynamicWeight 1 { dynamicWeight 1 } s.Weight dynamicWeight totalWeight dynamicWeight } lb.gcd gcdOfArray(lb.servers) // 计算GCD的函数 } currentServer : lb.servers[lb.index] // 加权轮询逻辑如果当前权重大于等于GCD则选中 if currentServer.Weight lb.gcd { return currentServer } } } // 实际使用时会有一个后台协程定期从服务注册中心同步服务器列表和实时负载4. 关键实现细节稳定性的保障意图识别模块的容错处理 直接调用外部NLU服务风险很高。我们设计了一个带超时、重试和降级的健壮客户端。import requests from requests.exceptions import Timeout, ConnectionError import logging from .fallback_matcher import KeywordFallbackMatcher # 降级用的关键词匹配器 class RobustIntentRecognizer: def __init__(self, kozi_endpoint, timeout2, retries1): self.endpoint kozi_endpoint self.timeout timeout self.retries retries self.fallback_matcher KeywordFallbackMatcher() # 初始化降级匹配器 self.logger logging.getLogger(__name__) def recognize(self, user_utterance, session_id): 识别用户意图具备容错能力。 :param user_utterance: 用户语句 :param session_id: 会话ID :return: 意图标签和置信度 payload {text: user_utterance, session_id: session_id} # 尝试调用扣子空间主服务 for attempt in range(self.retries 1): try: resp requests.post(self.endpoint, jsonpayload, timeoutself.timeout) resp.raise_for_status() # 检查HTTP状态码是否为200 result resp.json() if result.get(confidence, 0) 0.6: # 置信度阈值 return result[intent], result[confidence] else: self.logger.warning(fLow confidence from Kozi: {result}) # 置信度低也触发降级 break except Timeout: self.logger.warning(fAttempt {attempt1}: Kozi service timeout.) if attempt self.retries: break # 重试次数用尽 except ConnectionError as e: self.logger.error(fAttempt {attempt1}: Connection error: {e}) break # 连接错误立即降级 except Exception as e: self.logger.error(fAttempt {attempt1}: Unexpected error: {e}) break # 降级逻辑使用本地关键词匹配 self.logger.info(fFalling back to keyword matching for session {session_id}.) fallback_intent, confidence self.fallback_matcher.match(user_utterance) return fallback_intent, confidence # 返回降级结果对话超时自动降级机制 对于多轮对话如果用户在某个步骤长时间不回应系统不能一直占着资源。我们设计了超时降级在Redis中为每个会话设置一个过期时间如300秒。每次用户交互后刷新这个过期时间。如果会话过期会话管理服务会清理该会话的上下文。当用户再次发起请求时如果检测到旧的会话已过期则启动一个新的会话并提示用户“您之前的对话已超时请重新描述您的问题”。这避免了内存和Redis资源的无限增长。5. 生产环境考量压测与安全压力测试报告 系统上线前我们用JMeter模拟了3000并发用户的持续请求场景混合了简单QA和复杂多轮对话。核心指标在2000 TPS每秒事务数的常态压力下P99响应延迟稳定在150毫秒以下。极限测试当流量陡增至3000 TPS时由于触发了自动扩容和负载均衡P99延迟升高到约350毫秒但未出现错误率飙升系统表现出了良好的背压机制通过队列和限流和弹性。资源消耗在2000 TPS时核心服务集群的CPU平均使用率在65%左右为我们预留了应对突发流量的缓冲空间。安全防护JWT防重放攻击为了防止请求被拦截后重放我们在JWT令牌中加入了jtiJWT ID和iat签发时间声明。服务端签发JWT时生成唯一的jti并将其与iat一起存入Redis设置一个略长于令牌有效期的过期时间如有效期60秒。网关校验JWT签名和有效期后还会向Redis查询该jti是否存在且iat与存储的一致。如果存在且一致则认为是首次使用放行请求并删除Redis中的该jti或标记为已使用。如果不存在或iat不匹配则判定为重放攻击拒绝请求。 这套方案简单有效地防御了常见的重放攻击。6. 避坑指南我们踩过的那些“坑”冷启动性能服务刚启动时直接处理线上流量由于模型未加载、缓存为空前几个请求响应会特别慢。我们的最佳实践是在K8s的readiness探针中加入对模型加载完成和缓存预热完成的检查。编写启动脚本在容器启动后、接收流量前主动调用自身接口或加载必要数据到本地缓存。对于从零启动的实例先将其放在负载均衡池末尾给予一个“预热期”。分布式会话锁的误用初期我们为了保证对话状态的强一致性在更新Redis中的会话上下文时频繁使用分布式锁RedLock。这在高并发下成了性能瓶颈且增加了复杂度。后来我们优化为减少锁粒度不再锁整个会话对象而是只对真正存在竞争的关键字段如“当前正在处理的订单ID”使用轻量级的Redis原子操作如SETNX。接受最终一致性对于对话历史记录这类追加操作采用异步写入允许极短时间的不一致用户体验几乎无感知但系统吞吐量大幅提升。7. 互动与思考思考题在我们的架构中会话状态是服务端管理的。但如果用户从App咨询到一半又切换到Web端如何设计才能让用户的对话上下文无缝衔接保持“会话粘性”参考答案要点统一会话标识不再以设备或渠道ID作为会话唯一标识而是以用户IDUser ID为核心键。无论用户从哪个渠道接入都通过其登录账号关联到同一个会话上下文。状态同步与广播当一个渠道的对话状态更新时例如在App上回答了某个问题会话管理服务除了更新中心存储Redis外还可以通过消息队列如Kafka发布一个“会话状态变更”事件。渠道网关订阅各个渠道的BFF或网关订阅这个事件主题。当Web端的网关收到该用户的状态变更事件后可以主动向Web端推送如WebSocket或在其下次请求时告知其有最新的对话上下文可用。前端适配客户端App/Web需要具备在收到服务端通知或检测到渠道切换时主动拉取并恢复最新会话状态的能力。超时与清理这种跨渠道会话的生命周期管理需要更精细例如当所有渠道都长时间无活动后才清理整个会话。通过这套方案我们实现了“用户在哪服务跟到哪”的连贯体验真正做到了以用户为中心的智能客服。这次基于扣子空间的智能客服系统重构对我们团队来说是一次宝贵的学习和成长。从最初的痛点分析到技术选型、架构设计、编码实现再到最后的压测上线和优化整个过程让我们对高并发、分布式系统的理解加深了不少。目前系统已经平稳运行了几个月扛住了多次营销活动的流量冲击业务方的满意度提升了很多。当然系统还有继续优化的空间比如引入更智能的流量预测进行弹性伸缩、探索基于深度学习的意图识别模型自训练等。希望我们的分享能对你有所帮助也欢迎一起交流探讨。