简介在线客服系统是企业网站与用户实时沟通的重要入口但其源码门槛远高于普通聊天Demo。一个可运营的客服系统需要解决路由分配、消息可靠投递、会话生命周期管理等核心问题并依托WebSocket实现实时通信借助消息队列削峰。从技术架构到数据库设计从坐席工作台到数据统计每个模块都直接影响生产环境的稳定性。本文针对基于Spring Boot的运营级在线客服系统源码进行深度拆解围绕消息体设计、路由算法、离线补拉等关键逻辑讲解从环境部署、二次开发到性能压测的完整路径帮助技术团队避开常见坑点真正将源码落地为支撑业务运营的客服平台。 运营级在线客服系统源码这个东西搜出来的人十个里有八个是拿了个聊天Demo。Demo什么样能发消息、能回消息看着像个客服系统了可真往生产环境一丢立刻露馅——坐席一多就乱套客户一多消息就丢想查个历史记录得翻数据库管理员连个统计报表都看不到。我见过好几个团队拿着这种源码改了大半年最后还是推倒重来。所以这篇文章不打算给你贴一段完整源码然后说拿去用而是把一套真正能支撑运营的在线客服系统拆开揉碎讲清楚它和Demo的差距到底在哪、每个核心模块为什么要这么设计、源码里的关键逻辑怎么读、以及从零部署到跑通全流程会遇到哪些坑。适合三类人看想在公司内部自研客服系统的技术团队、拿到源码但不知道怎么二次开发的学习者、以及正在做技术选型想评估自研还是买的负责人。1. 运营级三个字意味着什么先理清需求边界1.1 Demo和运营级系统之间隔着整整一个部门先说个扎心的结论在线客服系统的核心难点从来不在聊天。发消息、收消息、显示消息这仨功能随便找个WebSocket教程就能做出来。真正的分水岭在于你把它放到一个真实业务环境里之后要面对的所有琐碎问题50个坐席同时在线怎么分配访客才不会有人闲着、有人累死一个访客换了个页面、断了次网重新进来之后怎么让他还是同一个客户坐席下班了会话没处理完这些消息怎么交接老板要的数据报表——今天接入多少会话、平均响应时长多少、满意度多少——从哪儿来客服组长要质检怎么抽查聊天记录这些问题Demo级源码不会替你考虑但运营级系统必须全部覆盖。所以当你拿到一份源码时第一件事不是急着跑起来而是对照这份清单看它有没有这些模块。如果只有一个聊天窗口加一个管理后台那它离运营级还有很长的路。1.2 运营级系统的完整功能地图我在实际落地时会把一个可运营的客服系统拆成六个域缺一个都撑不起日常运转功能域核心职责缺失时的后果访客端发起会话、消息收发、满意度评价客户体验直接崩坐席工作台接待、转接、结束会话、快捷回复坐席效率低下完全没法用路由分配技能组匹配、坐席选择、排队策略客户全堆在一个人身上消息中枢实时收发、离线补发、消息可靠投递消息丢失客诉事故管理后台坐席账号、技能组、权限、会话记录团队没法协作和管控数据统计会话量、响应时长、满意度、导出没有复盘依据运营无从谈起你会发现前两个域是面上的功能后四个才是让系统真正运转起来的里子。源码的含金量也主要看后四个域做得多深。下面我就按这个地图逐个模块讲。2. 技术选型与整体架构为什么我会这么搭2.1 后端语言和框架的选择逻辑考虑到客服系统的业务特征——长连接多、消息并发高、业务逻辑中等到偏复杂后端我选的是Spring Boot。可能有人会说Go更适合高并发长连接这话没错但对于一个还需要做权限管理、报表统计、对接内部CRM的完整系统来说Spring Boot的生态成熟度更高招人也好招。具体版本组合我用的是Spring Boot 2.7.x WebSocket Redis MySQL 8.0 RabbitMQ。这套组合的成熟度很高网上资料多遇到问题基本都能搜到答案。WebSocket负责实时消息通道Redis存会话状态和在线状态MySQL存消息和业务数据RabbitMQ做消息削峰和跨节点广播。2.2 实时通信选WebSocket而不是轮询这个决策基本不需要纠结。早期客服系统有用HTTP长轮询的但代价很大——每次请求都有HTTP头开销服务端还要维护大量挂起的请求水平扩展时很容易被连接数拖垮。WebSocket建立一次TCP连接后全双工通信服务端可以主动推送这是客服系统最自然的模型。但WebSocket有个坑必须提前知道它基于长连接部署时要考虑负载均衡层的连接保持。我用的是Nginx做反向代理配置了ip_hash或sticky session不然坐席A发的消息可能被路由到另一台机器而那个WebSocket连接不在那台机器上消息就丢了。2.3 Redis和MQ在架构里各扮演什么角色Redis我用来存四类数据坐席在线状态、访客与坐席的绑定关系、会话的当前状态、以及没读消息的计数。这些数据的特点是读取极其频繁、允许丢失后重建放Redis正合适。MySQL则只存最终需要归档的数据——消息记录、会话详情、操作日志。RabbitMQ的引入是最关键的决定。当访客发一条消息时后端会先把消息扔进MQ然后由消费者异步写入MySQL。这样做有两个目的一是削峰客服系统平时流量不大但搞活动时可能瞬间涌入大量访客直接写库会把MySQL打死二是解耦写入MySQL和推送消息给坐席是两个不同频率的操作没必要绑在同一个事务里。2.4 数据库表结构设计的核心思路表结构这块我见过太多人把消息表做得极其复杂其实没必要。核心就四张表session会话表会话ID、访客ID、坐席ID、技能组ID、状态排队中/接待中/已结束、创建时间、结束时间message消息表消息ID、会话ID、发送者类型访客/坐席/系统、消息内容、消息类型文本/图片/商品卡片、发送时间agent坐席表坐席ID、账号、昵称、技能组、状态离线/空闲/忙碌visitor访客表访客ID、来源页面、浏览器信息、首次访问时间核心设计要点在message表要按会话ID建索引查询历史消息时只查单条会话避免全表扫描。如果消息量真的很大日均百万条以上再考虑按月分表。客服系统大多数场景下消息量没那么夸张单表加索引能扛很久别过早引入分库分表增加复杂度。3. 核心模块拆解从访客上线到会话关闭的完整链路3.1 访客初始化与身份识别访客第一次访问网站时前端会向服务端请求一个访客ID这个ID会种在cookie里。用户刷新页面、重新打开浏览器只要cookie还在他就是同一个访客。但如果用户换了设备、清了cookie那就成了一个新访客——这是客服系统非常常见的数据割裂问题。解决思路是靠访客身份绑定。当访客在你们的网站上登录了账号前端会把登录用户ID传给客服系统客服系统将visitorId和userId做关联。这样一来即使cookie丢了也能通过userId找到历史会话记录。更进一步的做法是接入设备指纹把UA、屏幕分辨率、Canvas指纹等信息hash一下作为辅助识别手段。3.2 路由分配把访客分给最合适的坐席访客点了在线咨询系统得回答一个问题这个访客该由谁来接最粗糙的做法是随机分配谁闲着分给谁。但运营级的分配要满足几个规则技能组优先访客问的是售后问题就得分配给售后组不能甩给售前组。坐席饱和度控制每个坐席设置一个最大接待数比如同时最多接10个会话满了就不再分配。负载均衡在满足前两条的前提下优先分给当前会话数最少的坐席。实际实现时路由分配器是常驻内存的一个服务它监听Redis里的坐席状态变化。访客进来时先根据他的来源页面对应到技能组然后从该技能组在线坐席中筛掉已达到上限的人最后按当前会话数最少排序取第一个。这段逻辑放在源码里一般不会太复杂但性能要求很高——分配决策要在几十毫秒内完成不能等坐席响应。3.3 排队机制与访客等待体验当没有可用坐席时访客不能干等着系统要做两件事一是告诉访客当前排队人数二是坐席空闲时按顺序接入。排队队列我会放在Redis的List里访客进入排队时RPUSH坐席空闲时从队首LPOP。这里有个细节要注意访客可能等不及关掉了页面他离开时要从队列里移除不能等他回来后还在队首插队。所以每次检查队首元素时要确认这个访客的WebSocket连接还活着。排队体验这块运营级的系统会在前端做一件事预估等待时间。这个值可以不精确用当前排队人数乘以前5分钟平均接待时长再除以在线坐席数算个粗略值但有了它用户流失率会明显降低。3.4 消息可靠性消息不能丢也不能重复在线客服的消息可靠性要求比普通聊天软件更高因为这是服务承诺。我在设计时用了一套客户端生成消息ID 服务端幂等检查 离线补拉的组合方案。每条消息在客户端生成时就带上一个全局唯一的msgId服务端收到后先查这个msgId有没有处理过处理过就直接丢弃。这样即使客户端因为网络原因重发了同一消息也不会产生重复记录。发送过程的时序是这样访客点发送消息先走WebSocket通道发出同时前端把消息渲染在气泡里但标记为发送中。服务端收到消息后回一个ack前端收到ack才把状态改为已送达。如果WebSocket断了前端会走一个兜底接口用HTTP重发保证消息最终能到服务端。3.5 会话生命周期管理一个会话从创建到结束会经历几个状态QUEUEING排队中→ACCEPTED坐席已接入→ENDED已结束。状态流转的逻辑虽然简单但容易踩坑的第位是结束会话的时机。坐席点了结束访客还没回话这个会话到底是结束还是待定我的处理方式是坐席可以主动结束但结束前必须弹出提示框让坐席确认访客在会话结束后再发消息系统会自动创建一个新会话并带上上一会话的关联ID。这样一个连续的服务过程可以被追溯成一个会话组统计时会讲一次服务会话组为维度而不是单看会话条数。4. 源码核心逻辑精读消息体设计、分配算法与离线补拉4.1 消息体字段设计源码里最值得精读的其实是消息体。消息体的设计决定了系统的扩展性。我的消息体核心字段如下{ msgId: 550e8400-e29b-41d4-a716-446655440000, sessionId: S20240801001, senderType: VISITOR, senderId: V10086, contentType: TEXT, content: 你好我昨天买的商品还没发货, createTime: 1735027200000, extra: { productId: P8899, orderId: O123456 } }msgId客户端生成全局唯一sessionId标识所属会话senderType区分访客、坐席、系统三类消息contentType是消息类型除了TEXT还有IMAGE、EVENT、CARD等extra是个JSON字段用来携带订单信息、商品卡片这类业务数据。这个extra字段的价值很大它让客服系统能灵活对接业务系统而不用改表结构。4.2 路由分配算法伪代码精讲分配算法是源码里含金量最高的部分之一我用伪代码展示核心逻辑function findAvailableAgent(skillGroupId, visitorId): agents getOnlineAgentsBySkillGroup(skillGroupId) candidates [] for agent in agents: currentLoad redis.zscore(agent_load, agent.id) maxLoad getAgentMaxLoad(agent.id) if currentLoad maxLoad: candidates.append((agent, currentLoad)) if candidates is empty: return null sort candidates by currentLoad asc return candidates[0].agent这个算法用Redis的有序集合agent_load存每个坐席当前会话数key是坐席IDscore是会话数。每接一个新会话score加1会话结束score减1。查找时按score升序取第一个就是最闲的坐席。因为Redis操作是单线程的zscore和zadd之间可能有并发问题——两个访客同时被路由到同一个坐席。解决方式是用Lua脚本把检查负载和加负载合并成一个原子操作或者分两种情况处理分配后的会话接入做二次校验发现超过上限就重新路由。4.3 离线消息的补拉机制用户关掉页面再打开或者网络切换导致WebSocket断开重连这个过程中来的消息不能让他看不到。我采用的策略是游标补拉客户端断开时记录下当前收到的最后一条消息的createTime或者msgId。重连成功后客户端调用一个HTTP接口带上会话ID和游标时间。服务端查出该会话从游标之后的所有消息一次性返回。客户端把消息追加到聊天窗口里。这个方案比服务端存离线消息背包简单得多也稳妥得多。因为客服系统的消息是会话维度的不存在把全站消息推给离线用户的需求只需要按会话补拉即可。源码里这个接口通常叫/api/session/{sessionId}/messages/pull入参是cursorTime。4.4 WebSocket心跳与重连的细节处理WebSocket连接断了怎么办网络不稳定是常态不能让客服觉得客户怎么突然不说话了。客户端每30秒发一个PING心跳服务端收到后返回PONG。如果服务端超过70秒没收到心跳就判定这个连接已死清理掉在线状态。客户端这边每5秒检测一次WebSocket状态如果是CLOSED就自动重连重连成功后重新订阅会话消息。重连有次数上限连续失败5次就提示用户刷新页面。这里有个值得分享的坑WebSocket断线后服务端的onClose事件不一定会立刻触发尤其是用户直接拔网线、关电脑这种非正常断开。TCP层要等到超时才能发现可能要好几分钟。所以心跳机制不是可选项是必须项。当初我把心跳间隔设在30秒就是为了让僵尸连接最多存活不到1分钟。5. 从零部署到跑通环境准备与关键配置细节5.1 基础环境清单我假设你拿到的是一份标准的Spring Boot Vue前后端分离源码先列一下需要准备的环境组件版本要求用途JDK1.8以上建议11运行后端服务Maven3.6构建后端MySQL5.7或8.0数据持久化Redis5.0在线状态、队列、缓存RabbitMQ3.8消息削峰与广播Node.js14构建前端Nginx1.18反向代理与静态资源服务这套组合对机器要求不高4核8G的服务器单机部署足够支撑中小团队使用。5.2 配置文件里必须改的五处拿到源码后最烦的就是配置改不对跑不起来。我把最关键的配置列一下application.yml核心配置spring: datasource: url: jdbc:mysql://localhost:3306/cs_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: yourpassword redis: host: localhost port: 6379 password: yourredispassword rabbitmq: host: localhost port: 5672 username: guest password: guest servlet: multipart: max-file-size: 10MB server: port: 8080 custom: upload-dir: /data/upload第一处是数据库连接第二处是Redis第三处是RabbitMQ第四处是上传目录第五处是WebSocket端点路径前缀。前三个改不对直接连不上上传目录不建好站内图片消息功能会静默失败WebSocket路径如果和前端的配置不一致会出现能看历史消息但实时消息进不来的诡异现象。5.3 数据库初始化源码一般会带一个docs/sql/init.sql这个脚本建库建表还会插入初始管理员账号和默认技能组数据。执行的时候要注意MySQL的编码必须设为utf8mb4否则访客发个生僻字或者表情符号消息写入直接报错。注意utf8mb4和utf8的区别一定要搞清楚。MySQL的utf8最多存3字节而emoji表情是4字节不用utf8mb4的话用户发个你就得查日志看Data too long的报错了。5.4 后端启动步骤用Maven打包是个高频出问题的环节。我第一次打包时各种依赖下载失败后来统一换了阿里云镜像才顺畅。操作步骤# 1. 编译打包 mvn clean package -DskipTests # 2. 启动应用 java -jar target/cs-system-1.0.0.jar 启动之后看日志看到Started CsSystemApplication就说明起来了。常见坑有两个一个是端口被占用改server.port另一个是启动时报Redis连接失败多半是Redis没设密码或者防火墙没放行。5.5 前端搭建和联调前端如果用的Vue依赖安装命令是npm install如果网络不好建议配置npm的registry为国内镜像。安装完依赖后改.env文件里的后端API地址VUE_APP_BASE_URLhttp://localhost:8080 VUE_APP_WS_URLws://localhost:8080/ws然后npm run dev启动开发模式。浏览器打开前端后建议同时开两个浏览器窗口一个模拟访客一个用管理员账号登录坐席工作台。在访客窗口发起会话看坐席工作台是否实时弹出新会话——这一步能通整个链路的60%就算通了。6. 性能压测与稳定性治理运营级系统真正的分水岭6.1 单机能扛多少并发我压测过这套架构的单机性能结论供参考4核8G机器上WebSocket连接数可以稳定扛到5000左右消息吞吐大约每秒800到1000条。如果超过这个量CPU会飙升延迟会明显变大这时候就得加机器水平扩容。6.2 三个最先爆发的瓶颈实际运营中我发现有三个瓶颈会最先出现而且往往同时爆发文件句柄耗尽。每个WebSocket连接都要占用一个文件描述符Linux默认单进程1024个跑不了几百个连接就满了。修改方式ulimit -n 65535这只是当前会话临时生效要持久化得修改/etc/security/limits.conf。这个坑我踩过线上好好的突然连不上排查半天发现是句柄打满了。Nginx的代理超时。WebSocket是长连接如果Nginx配置里没设置长连接超时默认60秒后连接会被断开。需要在Nginx的location里加上proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s;这个proxy_read_timeout如果太短坐席端就会频繁掉线重连客户会觉得系统很卡。数据库连接池被打满。当大量消息同时落库而默认的连接池只有10个连接时写并发稍微一高就排队。我一般把HikariCP的maximum-pool-size调到50并且给写库操作单独加一个队列缓冲避免瞬时高峰直接冲垮数据库。6.3 消息削峰MQ是如何救命的有一次做活动营销访客量是平时的20倍消息洪峰瞬间打到后端。如果没有MQ每一条消息都直接写库加推送数据库很快会变成瓶颈然后整个系统的接口响应都变慢最终所有坐席的界面都转圈。MQ削峰的基本流程是WebSocket收到消息生产者把消息发到交换机消费者从队列里拉取异步写入MySQL同时推送实时消息给目标坐席。这样就算消息量瞬时暴涨也只是消息堆积在队列里数据库的写入压力被匀速释放。RabbitMQ在这种场景下表现很稳只要消费者处理能力高于平均生产速率堆积的消息最终会消费完。6.4 一套最简监控报警方案运营级系统必须要监控。不需要上什么重型的APM平台我用了最轻量的一套组合Spring Boot Actuator暴露健康检查端点Prometheus按15秒间隔抓取指标Grafana做可视化面板。重点盯四个指标WebSocket当前连接数超过预估上限要告警消息队列积压量持续上涨说明消费者出问题了接口P99延迟超过1秒说明开始变卡系统CPU和内存出现内存泄漏会有缓慢上涨趋势报警通知我接到了钉钉机器人阈值设的是队列积压超过5000告警接口P99超过1秒告警CPU超过80%告警。这套配置帮我提前发现了三次隐患一次是内存泄漏导致的老年代持续增长一次是消息消费线程被某个慢SQL卡住还有一次是某个坐席客户端在异常循环重连。7. 运营后台与数据统计让客服团队真正用起来7.1 坐席管理与权限控制一个运营级的系统管理员要能做的事情创建坐席账号、分配技能组、设置最大接待数、查看每个坐席的实时状态在线、空闲、忙碌、离线。权限这块我按角色分成三层管理员、组长、坐席。组长能看到自己组内的会话记录和统计数据但不能动系统配置管理员拥有一切权限。如果你二次开发最容易忽略的其实是坐席不可见的权限隔离——一个坐席只能看到自己接待过的会话不能看全站会话。这个功能在SQL上就是每次查会话记录时强制带上agent_id 当前登录坐席ID条件不要相信前端传参。7.2 会话记录查询与导出会话记录查询是客服团队高频使用的功能。运营同学经常要查上周三那个投诉的客户是哪位坐席接待的聊天记录给我拉一下。查询条件一般有时间段、访客ID/名称、坐席、技能组、会话状态、是否包含敏感词。后端实现时要注意时间段字段一定要走索引否则运营查一个月的数据会把数据库拖垮。我会在session表的create_time和agent_id上建联合索引并且禁止不带时间范围的全表查询。7.3 核心统计指标怎么算才不骗人我看过太多客服系统统计面板上的数据是假的原因是口径不对。一个可靠的口径如下平均响应时长访客发消息到坐席发出第一条回复的时间差只统计坐席在接待中的会话平均首次响应时长一个会话里坐席回复第一条消息的时长衡量接待效率的关键指标会话解决率标记为已解决的会话数除以总会话数解决标记由坐席在结束会话时打满意度访客评价中满意和非常满意的占比注意要排除未评价的会话这些指标不算难但数据口径必须和业务对齐。比如平均响应时长如果用所有消息的时间差去算会被长消息打断场景严重拉低数字毫无参考价值。所以我强烈建议代码里单独维护一个坐席首次回复时间字段统计时直接取这个字段。7.4 访客画像与CRM打通最后聊一个让客服系统真正产生业务价值的模块访客画像。光接会话是客服系统的及格线运营级的系统要把访客的访问轨迹串起来——他逛了哪些页面、在哪个页面发起的咨询、咨询前是不是刚加过购物车、历史上有几次服务记录。这些数据拼起来就能在坐席工作台右侧展示一张访客卡片坐席打开会话的第一眼就知道对面是什么量级的客户。落地方式并不复杂前端在埋点时把当前页面的URL、来源、自定义业务参数如订单号、商品ID通过WebSocket消息发给后端服务端存到Redis里的访客上下文中。坐席端加载会话时调用一个接口把访客上下文取出来。如果要和CRM打通就用userId作为关联键去CRM系统查用户等级、消费记录展示在访客卡片上。做到这一步客服系统就从一个聊天工具变成了客户运营工具。源码这种东西跑起来只是起点真正有价值的是你理解了它每一层设计在解决什么实际问题。我带着团队把这套系统从Demo一路改到支撑日均万级会话中间踩过的坑远比文章里写得多。如果你正在折腾一套在线客服系统源码我最后给三条实在建议第一先把路由分配和消息可靠性搞清楚这俩是地基地基不行上层全白搭第二不要一开始就追求微服务单机加MQ已经能扛住绝大多数团队的量第三尽早接上监控和日志别等线上出了事故再去补。按这个顺序来你的系统离运营级就不会太远。本文还有配套的精品资源点击获取 运营级在线客服系统源码解析：从Demo到生产落地的技术指南
简介在线客服系统是企业网站与用户实时沟通的重要入口但其源码门槛远高于普通聊天Demo。一个可运营的客服系统需要解决路由分配、消息可靠投递、会话生命周期管理等核心问题并依托WebSocket实现实时通信借助消息队列削峰。从技术架构到数据库设计从坐席工作台到数据统计每个模块都直接影响生产环境的稳定性。本文针对基于Spring Boot的运营级在线客服系统源码进行深度拆解围绕消息体设计、路由算法、离线补拉等关键逻辑讲解从环境部署、二次开发到性能压测的完整路径帮助技术团队避开常见坑点真正将源码落地为支撑业务运营的客服平台。 运营级在线客服系统源码这个东西搜出来的人十个里有八个是拿了个聊天Demo。Demo什么样能发消息、能回消息看着像个客服系统了可真往生产环境一丢立刻露馅——坐席一多就乱套客户一多消息就丢想查个历史记录得翻数据库管理员连个统计报表都看不到。我见过好几个团队拿着这种源码改了大半年最后还是推倒重来。所以这篇文章不打算给你贴一段完整源码然后说拿去用而是把一套真正能支撑运营的在线客服系统拆开揉碎讲清楚它和Demo的差距到底在哪、每个核心模块为什么要这么设计、源码里的关键逻辑怎么读、以及从零部署到跑通全流程会遇到哪些坑。适合三类人看想在公司内部自研客服系统的技术团队、拿到源码但不知道怎么二次开发的学习者、以及正在做技术选型想评估自研还是买的负责人。1. 运营级三个字意味着什么先理清需求边界1.1 Demo和运营级系统之间隔着整整一个部门先说个扎心的结论在线客服系统的核心难点从来不在聊天。发消息、收消息、显示消息这仨功能随便找个WebSocket教程就能做出来。真正的分水岭在于你把它放到一个真实业务环境里之后要面对的所有琐碎问题50个坐席同时在线怎么分配访客才不会有人闲着、有人累死一个访客换了个页面、断了次网重新进来之后怎么让他还是同一个客户坐席下班了会话没处理完这些消息怎么交接老板要的数据报表——今天接入多少会话、平均响应时长多少、满意度多少——从哪儿来客服组长要质检怎么抽查聊天记录这些问题Demo级源码不会替你考虑但运营级系统必须全部覆盖。所以当你拿到一份源码时第一件事不是急着跑起来而是对照这份清单看它有没有这些模块。如果只有一个聊天窗口加一个管理后台那它离运营级还有很长的路。1.2 运营级系统的完整功能地图我在实际落地时会把一个可运营的客服系统拆成六个域缺一个都撑不起日常运转功能域核心职责缺失时的后果访客端发起会话、消息收发、满意度评价客户体验直接崩坐席工作台接待、转接、结束会话、快捷回复坐席效率低下完全没法用路由分配技能组匹配、坐席选择、排队策略客户全堆在一个人身上消息中枢实时收发、离线补发、消息可靠投递消息丢失客诉事故管理后台坐席账号、技能组、权限、会话记录团队没法协作和管控数据统计会话量、响应时长、满意度、导出没有复盘依据运营无从谈起你会发现前两个域是面上的功能后四个才是让系统真正运转起来的里子。源码的含金量也主要看后四个域做得多深。下面我就按这个地图逐个模块讲。2. 技术选型与整体架构为什么我会这么搭2.1 后端语言和框架的选择逻辑考虑到客服系统的业务特征——长连接多、消息并发高、业务逻辑中等到偏复杂后端我选的是Spring Boot。可能有人会说Go更适合高并发长连接这话没错但对于一个还需要做权限管理、报表统计、对接内部CRM的完整系统来说Spring Boot的生态成熟度更高招人也好招。具体版本组合我用的是Spring Boot 2.7.x WebSocket Redis MySQL 8.0 RabbitMQ。这套组合的成熟度很高网上资料多遇到问题基本都能搜到答案。WebSocket负责实时消息通道Redis存会话状态和在线状态MySQL存消息和业务数据RabbitMQ做消息削峰和跨节点广播。2.2 实时通信选WebSocket而不是轮询这个决策基本不需要纠结。早期客服系统有用HTTP长轮询的但代价很大——每次请求都有HTTP头开销服务端还要维护大量挂起的请求水平扩展时很容易被连接数拖垮。WebSocket建立一次TCP连接后全双工通信服务端可以主动推送这是客服系统最自然的模型。但WebSocket有个坑必须提前知道它基于长连接部署时要考虑负载均衡层的连接保持。我用的是Nginx做反向代理配置了ip_hash或sticky session不然坐席A发的消息可能被路由到另一台机器而那个WebSocket连接不在那台机器上消息就丢了。2.3 Redis和MQ在架构里各扮演什么角色Redis我用来存四类数据坐席在线状态、访客与坐席的绑定关系、会话的当前状态、以及没读消息的计数。这些数据的特点是读取极其频繁、允许丢失后重建放Redis正合适。MySQL则只存最终需要归档的数据——消息记录、会话详情、操作日志。RabbitMQ的引入是最关键的决定。当访客发一条消息时后端会先把消息扔进MQ然后由消费者异步写入MySQL。这样做有两个目的一是削峰客服系统平时流量不大但搞活动时可能瞬间涌入大量访客直接写库会把MySQL打死二是解耦写入MySQL和推送消息给坐席是两个不同频率的操作没必要绑在同一个事务里。2.4 数据库表结构设计的核心思路表结构这块我见过太多人把消息表做得极其复杂其实没必要。核心就四张表session会话表会话ID、访客ID、坐席ID、技能组ID、状态排队中/接待中/已结束、创建时间、结束时间message消息表消息ID、会话ID、发送者类型访客/坐席/系统、消息内容、消息类型文本/图片/商品卡片、发送时间agent坐席表坐席ID、账号、昵称、技能组、状态离线/空闲/忙碌visitor访客表访客ID、来源页面、浏览器信息、首次访问时间核心设计要点在message表要按会话ID建索引查询历史消息时只查单条会话避免全表扫描。如果消息量真的很大日均百万条以上再考虑按月分表。客服系统大多数场景下消息量没那么夸张单表加索引能扛很久别过早引入分库分表增加复杂度。3. 核心模块拆解从访客上线到会话关闭的完整链路3.1 访客初始化与身份识别访客第一次访问网站时前端会向服务端请求一个访客ID这个ID会种在cookie里。用户刷新页面、重新打开浏览器只要cookie还在他就是同一个访客。但如果用户换了设备、清了cookie那就成了一个新访客——这是客服系统非常常见的数据割裂问题。解决思路是靠访客身份绑定。当访客在你们的网站上登录了账号前端会把登录用户ID传给客服系统客服系统将visitorId和userId做关联。这样一来即使cookie丢了也能通过userId找到历史会话记录。更进一步的做法是接入设备指纹把UA、屏幕分辨率、Canvas指纹等信息hash一下作为辅助识别手段。3.2 路由分配把访客分给最合适的坐席访客点了在线咨询系统得回答一个问题这个访客该由谁来接最粗糙的做法是随机分配谁闲着分给谁。但运营级的分配要满足几个规则技能组优先访客问的是售后问题就得分配给售后组不能甩给售前组。坐席饱和度控制每个坐席设置一个最大接待数比如同时最多接10个会话满了就不再分配。负载均衡在满足前两条的前提下优先分给当前会话数最少的坐席。实际实现时路由分配器是常驻内存的一个服务它监听Redis里的坐席状态变化。访客进来时先根据他的来源页面对应到技能组然后从该技能组在线坐席中筛掉已达到上限的人最后按当前会话数最少排序取第一个。这段逻辑放在源码里一般不会太复杂但性能要求很高——分配决策要在几十毫秒内完成不能等坐席响应。3.3 排队机制与访客等待体验当没有可用坐席时访客不能干等着系统要做两件事一是告诉访客当前排队人数二是坐席空闲时按顺序接入。排队队列我会放在Redis的List里访客进入排队时RPUSH坐席空闲时从队首LPOP。这里有个细节要注意访客可能等不及关掉了页面他离开时要从队列里移除不能等他回来后还在队首插队。所以每次检查队首元素时要确认这个访客的WebSocket连接还活着。排队体验这块运营级的系统会在前端做一件事预估等待时间。这个值可以不精确用当前排队人数乘以前5分钟平均接待时长再除以在线坐席数算个粗略值但有了它用户流失率会明显降低。3.4 消息可靠性消息不能丢也不能重复在线客服的消息可靠性要求比普通聊天软件更高因为这是服务承诺。我在设计时用了一套客户端生成消息ID 服务端幂等检查 离线补拉的组合方案。每条消息在客户端生成时就带上一个全局唯一的msgId服务端收到后先查这个msgId有没有处理过处理过就直接丢弃。这样即使客户端因为网络原因重发了同一消息也不会产生重复记录。发送过程的时序是这样访客点发送消息先走WebSocket通道发出同时前端把消息渲染在气泡里但标记为发送中。服务端收到消息后回一个ack前端收到ack才把状态改为已送达。如果WebSocket断了前端会走一个兜底接口用HTTP重发保证消息最终能到服务端。3.5 会话生命周期管理一个会话从创建到结束会经历几个状态QUEUEING排队中→ACCEPTED坐席已接入→ENDED已结束。状态流转的逻辑虽然简单但容易踩坑的第位是结束会话的时机。坐席点了结束访客还没回话这个会话到底是结束还是待定我的处理方式是坐席可以主动结束但结束前必须弹出提示框让坐席确认访客在会话结束后再发消息系统会自动创建一个新会话并带上上一会话的关联ID。这样一个连续的服务过程可以被追溯成一个会话组统计时会讲一次服务会话组为维度而不是单看会话条数。4. 源码核心逻辑精读消息体设计、分配算法与离线补拉4.1 消息体字段设计源码里最值得精读的其实是消息体。消息体的设计决定了系统的扩展性。我的消息体核心字段如下{ msgId: 550e8400-e29b-41d4-a716-446655440000, sessionId: S20240801001, senderType: VISITOR, senderId: V10086, contentType: TEXT, content: 你好我昨天买的商品还没发货, createTime: 1735027200000, extra: { productId: P8899, orderId: O123456 } }msgId客户端生成全局唯一sessionId标识所属会话senderType区分访客、坐席、系统三类消息contentType是消息类型除了TEXT还有IMAGE、EVENT、CARD等extra是个JSON字段用来携带订单信息、商品卡片这类业务数据。这个extra字段的价值很大它让客服系统能灵活对接业务系统而不用改表结构。4.2 路由分配算法伪代码精讲分配算法是源码里含金量最高的部分之一我用伪代码展示核心逻辑function findAvailableAgent(skillGroupId, visitorId): agents getOnlineAgentsBySkillGroup(skillGroupId) candidates [] for agent in agents: currentLoad redis.zscore(agent_load, agent.id) maxLoad getAgentMaxLoad(agent.id) if currentLoad maxLoad: candidates.append((agent, currentLoad)) if candidates is empty: return null sort candidates by currentLoad asc return candidates[0].agent这个算法用Redis的有序集合agent_load存每个坐席当前会话数key是坐席IDscore是会话数。每接一个新会话score加1会话结束score减1。查找时按score升序取第一个就是最闲的坐席。因为Redis操作是单线程的zscore和zadd之间可能有并发问题——两个访客同时被路由到同一个坐席。解决方式是用Lua脚本把检查负载和加负载合并成一个原子操作或者分两种情况处理分配后的会话接入做二次校验发现超过上限就重新路由。4.3 离线消息的补拉机制用户关掉页面再打开或者网络切换导致WebSocket断开重连这个过程中来的消息不能让他看不到。我采用的策略是游标补拉客户端断开时记录下当前收到的最后一条消息的createTime或者msgId。重连成功后客户端调用一个HTTP接口带上会话ID和游标时间。服务端查出该会话从游标之后的所有消息一次性返回。客户端把消息追加到聊天窗口里。这个方案比服务端存离线消息背包简单得多也稳妥得多。因为客服系统的消息是会话维度的不存在把全站消息推给离线用户的需求只需要按会话补拉即可。源码里这个接口通常叫/api/session/{sessionId}/messages/pull入参是cursorTime。4.4 WebSocket心跳与重连的细节处理WebSocket连接断了怎么办网络不稳定是常态不能让客服觉得客户怎么突然不说话了。客户端每30秒发一个PING心跳服务端收到后返回PONG。如果服务端超过70秒没收到心跳就判定这个连接已死清理掉在线状态。客户端这边每5秒检测一次WebSocket状态如果是CLOSED就自动重连重连成功后重新订阅会话消息。重连有次数上限连续失败5次就提示用户刷新页面。这里有个值得分享的坑WebSocket断线后服务端的onClose事件不一定会立刻触发尤其是用户直接拔网线、关电脑这种非正常断开。TCP层要等到超时才能发现可能要好几分钟。所以心跳机制不是可选项是必须项。当初我把心跳间隔设在30秒就是为了让僵尸连接最多存活不到1分钟。5. 从零部署到跑通环境准备与关键配置细节5.1 基础环境清单我假设你拿到的是一份标准的Spring Boot Vue前后端分离源码先列一下需要准备的环境组件版本要求用途JDK1.8以上建议11运行后端服务Maven3.6构建后端MySQL5.7或8.0数据持久化Redis5.0在线状态、队列、缓存RabbitMQ3.8消息削峰与广播Node.js14构建前端Nginx1.18反向代理与静态资源服务这套组合对机器要求不高4核8G的服务器单机部署足够支撑中小团队使用。5.2 配置文件里必须改的五处拿到源码后最烦的就是配置改不对跑不起来。我把最关键的配置列一下application.yml核心配置spring: datasource: url: jdbc:mysql://localhost:3306/cs_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: yourpassword redis: host: localhost port: 6379 password: yourredispassword rabbitmq: host: localhost port: 5672 username: guest password: guest servlet: multipart: max-file-size: 10MB server: port: 8080 custom: upload-dir: /data/upload第一处是数据库连接第二处是Redis第三处是RabbitMQ第四处是上传目录第五处是WebSocket端点路径前缀。前三个改不对直接连不上上传目录不建好站内图片消息功能会静默失败WebSocket路径如果和前端的配置不一致会出现能看历史消息但实时消息进不来的诡异现象。5.3 数据库初始化源码一般会带一个docs/sql/init.sql这个脚本建库建表还会插入初始管理员账号和默认技能组数据。执行的时候要注意MySQL的编码必须设为utf8mb4否则访客发个生僻字或者表情符号消息写入直接报错。注意utf8mb4和utf8的区别一定要搞清楚。MySQL的utf8最多存3字节而emoji表情是4字节不用utf8mb4的话用户发个你就得查日志看Data too long的报错了。5.4 后端启动步骤用Maven打包是个高频出问题的环节。我第一次打包时各种依赖下载失败后来统一换了阿里云镜像才顺畅。操作步骤# 1. 编译打包 mvn clean package -DskipTests # 2. 启动应用 java -jar target/cs-system-1.0.0.jar 启动之后看日志看到Started CsSystemApplication就说明起来了。常见坑有两个一个是端口被占用改server.port另一个是启动时报Redis连接失败多半是Redis没设密码或者防火墙没放行。5.5 前端搭建和联调前端如果用的Vue依赖安装命令是npm install如果网络不好建议配置npm的registry为国内镜像。安装完依赖后改.env文件里的后端API地址VUE_APP_BASE_URLhttp://localhost:8080 VUE_APP_WS_URLws://localhost:8080/ws然后npm run dev启动开发模式。浏览器打开前端后建议同时开两个浏览器窗口一个模拟访客一个用管理员账号登录坐席工作台。在访客窗口发起会话看坐席工作台是否实时弹出新会话——这一步能通整个链路的60%就算通了。6. 性能压测与稳定性治理运营级系统真正的分水岭6.1 单机能扛多少并发我压测过这套架构的单机性能结论供参考4核8G机器上WebSocket连接数可以稳定扛到5000左右消息吞吐大约每秒800到1000条。如果超过这个量CPU会飙升延迟会明显变大这时候就得加机器水平扩容。6.2 三个最先爆发的瓶颈实际运营中我发现有三个瓶颈会最先出现而且往往同时爆发文件句柄耗尽。每个WebSocket连接都要占用一个文件描述符Linux默认单进程1024个跑不了几百个连接就满了。修改方式ulimit -n 65535这只是当前会话临时生效要持久化得修改/etc/security/limits.conf。这个坑我踩过线上好好的突然连不上排查半天发现是句柄打满了。Nginx的代理超时。WebSocket是长连接如果Nginx配置里没设置长连接超时默认60秒后连接会被断开。需要在Nginx的location里加上proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s;这个proxy_read_timeout如果太短坐席端就会频繁掉线重连客户会觉得系统很卡。数据库连接池被打满。当大量消息同时落库而默认的连接池只有10个连接时写并发稍微一高就排队。我一般把HikariCP的maximum-pool-size调到50并且给写库操作单独加一个队列缓冲避免瞬时高峰直接冲垮数据库。6.3 消息削峰MQ是如何救命的有一次做活动营销访客量是平时的20倍消息洪峰瞬间打到后端。如果没有MQ每一条消息都直接写库加推送数据库很快会变成瓶颈然后整个系统的接口响应都变慢最终所有坐席的界面都转圈。MQ削峰的基本流程是WebSocket收到消息生产者把消息发到交换机消费者从队列里拉取异步写入MySQL同时推送实时消息给目标坐席。这样就算消息量瞬时暴涨也只是消息堆积在队列里数据库的写入压力被匀速释放。RabbitMQ在这种场景下表现很稳只要消费者处理能力高于平均生产速率堆积的消息最终会消费完。6.4 一套最简监控报警方案运营级系统必须要监控。不需要上什么重型的APM平台我用了最轻量的一套组合Spring Boot Actuator暴露健康检查端点Prometheus按15秒间隔抓取指标Grafana做可视化面板。重点盯四个指标WebSocket当前连接数超过预估上限要告警消息队列积压量持续上涨说明消费者出问题了接口P99延迟超过1秒说明开始变卡系统CPU和内存出现内存泄漏会有缓慢上涨趋势报警通知我接到了钉钉机器人阈值设的是队列积压超过5000告警接口P99超过1秒告警CPU超过80%告警。这套配置帮我提前发现了三次隐患一次是内存泄漏导致的老年代持续增长一次是消息消费线程被某个慢SQL卡住还有一次是某个坐席客户端在异常循环重连。7. 运营后台与数据统计让客服团队真正用起来7.1 坐席管理与权限控制一个运营级的系统管理员要能做的事情创建坐席账号、分配技能组、设置最大接待数、查看每个坐席的实时状态在线、空闲、忙碌、离线。权限这块我按角色分成三层管理员、组长、坐席。组长能看到自己组内的会话记录和统计数据但不能动系统配置管理员拥有一切权限。如果你二次开发最容易忽略的其实是坐席不可见的权限隔离——一个坐席只能看到自己接待过的会话不能看全站会话。这个功能在SQL上就是每次查会话记录时强制带上agent_id 当前登录坐席ID条件不要相信前端传参。7.2 会话记录查询与导出会话记录查询是客服团队高频使用的功能。运营同学经常要查上周三那个投诉的客户是哪位坐席接待的聊天记录给我拉一下。查询条件一般有时间段、访客ID/名称、坐席、技能组、会话状态、是否包含敏感词。后端实现时要注意时间段字段一定要走索引否则运营查一个月的数据会把数据库拖垮。我会在session表的create_time和agent_id上建联合索引并且禁止不带时间范围的全表查询。7.3 核心统计指标怎么算才不骗人我看过太多客服系统统计面板上的数据是假的原因是口径不对。一个可靠的口径如下平均响应时长访客发消息到坐席发出第一条回复的时间差只统计坐席在接待中的会话平均首次响应时长一个会话里坐席回复第一条消息的时长衡量接待效率的关键指标会话解决率标记为已解决的会话数除以总会话数解决标记由坐席在结束会话时打满意度访客评价中满意和非常满意的占比注意要排除未评价的会话这些指标不算难但数据口径必须和业务对齐。比如平均响应时长如果用所有消息的时间差去算会被长消息打断场景严重拉低数字毫无参考价值。所以我强烈建议代码里单独维护一个坐席首次回复时间字段统计时直接取这个字段。7.4 访客画像与CRM打通最后聊一个让客服系统真正产生业务价值的模块访客画像。光接会话是客服系统的及格线运营级的系统要把访客的访问轨迹串起来——他逛了哪些页面、在哪个页面发起的咨询、咨询前是不是刚加过购物车、历史上有几次服务记录。这些数据拼起来就能在坐席工作台右侧展示一张访客卡片坐席打开会话的第一眼就知道对面是什么量级的客户。落地方式并不复杂前端在埋点时把当前页面的URL、来源、自定义业务参数如订单号、商品ID通过WebSocket消息发给后端服务端存到Redis里的访客上下文中。坐席端加载会话时调用一个接口把访客上下文取出来。如果要和CRM打通就用userId作为关联键去CRM系统查用户等级、消费记录展示在访客卡片上。做到这一步客服系统就从一个聊天工具变成了客户运营工具。源码这种东西跑起来只是起点真正有价值的是你理解了它每一层设计在解决什么实际问题。我带着团队把这套系统从Demo一路改到支撑日均万级会话中间踩过的坑远比文章里写得多。如果你正在折腾一套在线客服系统源码我最后给三条实在建议第一先把路由分配和消息可靠性搞清楚这俩是地基地基不行上层全白搭第二不要一开始就追求微服务单机加MQ已经能扛住绝大多数团队的量第三尽早接上监控和日志别等线上出了事故再去补。按这个顺序来你的系统离运营级就不会太远。本文还有配套的精品资源点击获取