引言

在快速变化的商业环境中，我们迫切需要高效的即时通讯工具来满足日益增长的沟通需求。尽管传统的第三方IM系统提供了基本的沟通功能，但其在灵活性和可定制性方面往往无法满足我们的特定要求。因此，我们自主研发了一款客服IM系统，经过三年的稳定运行，显著提升了沟通协作效率，更好地支持了业务发展。

背景

在使用第三方IM系统时，我们面临着多重挑战，尤其是在灵活性不足和个性化服务无法满足特定业务需求。这不仅影响了沟通效率，也限制了我们在业务流程和司用体验上的创新。为了解决这些问题，我们设计并开发了自研的客服IM系统，旨在提供更高的定制化能力，以适应我们的业务需求和沟通协作方式，并且有较高的稳定性。

在接下来的内容中，我们将深入探讨自研IM系统的技术架构、设计理念，以及在开发过程中遇到的挑战与解决方案，以全面了解该系统如何高效、灵活地开展司用服务。

系统设计理念

在开发自研客服IM系统时，我们秉持以下设计理念，以确保系统不仅能满足当前需求，还能灵活应对未来多变的业务场景：

以司用为中心虚拟客服助手实时性与高可用性数据安全与隐私保护技术架构系统架构

基于目前主流的，也是货拉拉标准化的系统架构设计，能确保系统的可靠性，通过模块化将系统划分为不同层级，使系统更具灵活性，便于系统维护。

技术选型通信协议

我们选择WebSocket作为通信协议。WebSocket作为一种全双工通信的TCP网络协议，被广泛应用于即时通讯、游戏、实时通知等，它在HTTP协议基础上，通过“握手”过程建立了一个持久的连接，支持双向通信，使得信息的发送和接收可以即时进行，而不需要不断地重新建立连接，具有实时性、低延迟、高效性等特点。

网络模型

网络模型可以使用同步阻塞I/O、同步非阻塞I/O和异步I/O，详细的差异在此不展开赘述，Java针对网络模型分别提供了BIO，NIO和AIO等API，我们最终决定使用NIO网络模型，一方面是结合实际应用场景以及公司内部的基础建设，一方面是NIO通过非阻塞I/O和多路复用，提供高效的大量并发连接管理和处理能力，而且系统开销也比较小，比较符合IM系统使用场景。

开发框架

对接原生NIO操作API比较繁琐，为了更好更高效完成系统开发，我们选择市面上比较成熟的Spring Webflux框架，底层容器使用Netty，大大降低了NIO网络模型对接成本，并且框架内部做了许多系统优化，能充分利用NIO的非阻塞特性，通过实现Reactor响应式编程以及事件驱动处理模型，表现出卓越的性能，提供高并发连接和低延迟通信。

Netty事件驱动模型

服务中心化

在IM系统的网络设计中，对于端对端的个人通信，通常采用Client-Client模式。此模式下，两个客户端通过WebSocket建立直接连接，实现简单高效的通信。

相比之下，在客服业务场景中，我们选择Client-Server模式。所有客户端与中心网关建立连接，网关负责接收并转发司用与坐席或者服务端的请求。这种设计不仅便于记录通信过程，还为后续操作提供了灵活性。

基本链路

会话前会话中会话后设计原则：低耦合，高内聚

在IM系统设计的初期，我们考虑到随着业务的发展，系统将经历不断的升级与迭代。如果没有良好的系统架构，后续的维护成本将会不断增加。因此，我们采用“低耦合、高内聚”的设计原则，旨在提升系统的可维护性和扩展性，尤其是在敏捷开发和持续集成的环境中，能够快速响应变化并减少模块之间的依赖关系。

模块化设计

我们将IM系统拆分为多个独立模块，各模块通过API或消息队列（MQ）进行交互：

事件驱动架构

我们采用事件总线和消息队列来解耦模块，消息的顺序性依据具体业务场景。对于IM系统的大部分场景而言，消息消费可以是无序的：

单一职责（SRP）

每个模块专注于特定功能，职责明确，确保模块间的功能界限清晰。在微服务设计中，各模块可单独部署，依据系统运行情况提供不同的运行环境，实现独立自治。

技术挑战与解决方案挑战一：网关设计

在IM系统中，网关设计至关重要，为了确保稳定运行，我们更多时候是多节点部署，处理Client和Server之间的WebSocket连接会话也是关键，这样才能保证通信畅通无阻，避免“交通堵塞”。在迭代过程中，我们尝试了多种解决方案，最终结合实际业务场景，选定了「本地存储+Redis存储」方案。这样一来，性能也有提升，全局映射表功能也变得触手可及！

方案优点缺点

本地存储

1.高效性：快速读写操作，提升性能。

2.简易实施：结构简单，容易维护。

1.扩展性限制：重新计算路由可能导致连接失效。

2.管理负担：需维护路由转发功能。

Redis存储

1.集中管理：统一维护映射表，简化操作。

2.高效存取：内存数据库，读写性能高。

1.原子性保障：需确保并发操作的原子性。

2.网络延迟：依赖外部存储可能影响性能。

本地存储+Redis存储

1.减少延迟：优先使用本地存储，降低网络IO耗时。

2.灵活性：兼顾性能与一致性需求。

3.鲁棒性：Redis故障时可部分运行。

1.一致性维护：需确保两份存储的数据一致性。

2.资源占用：增加内存和存储消耗。

本地存储+消息队列

1.快速响应：本地存储加速本机请求。

2.灵活处理：通过消息队列简化跨Server请求。

3.可扩展性：动态扩展Server实例，提升并发能力。

1.延迟要求：生产和消费延迟可能影响响应时间。

2.吞吐量限制：性能受消息队列吞吐量制约。

3.增加复杂性：引入中间件增加维护工作。

本地存储+Redis存储

挑战二：会话数据存储

IM系统主要的数据是会话数据，其中会话数据如何存取以及数据格式如何设计，直接影响了系统的稳定性和性能，面对传统的DB存储，往往面临以下问题：

优化前：

数据存储方式仅使用MySQL，缺乏灵活性。

数据读取性能较低，受限于MySQL的处理能力，造成性能瓶颈。

合理的数据存储架构确保系统灵活可扩展，并提升数据访问速度，同时可以支撑业务高峰高并发量，确保系统在高负载情况下依然可靠运行，经过不断迭代升级，最终才能达到理性的效果。

优化后：

实现了冷热数据隔离存储，活跃会话数据实时处理，离线会话数据异步写入MySQL，减轻了数据库负担。

数据读取性能显著提升，而且采用Redis丰富的数据结构，满足IM系统多样化存储需求。

通过特定规则进行分片存储，提升了存储能力和读写性能。

挑战三：消息ACK

消息ACK是IM系统中用于确认消息成功送达的机制，它通过向发送方反馈消息状态（如已接收、发送失败等），提高了司用对消息传递的信任感和体验。简而言之，ACK就是让你知道你的消息没有“平白无故地消失了”！

主要流程：

对于服务端推送消息到司用端/坐席端也是同样道理。其中cmId用于确认消息唯一性，确保消息不会重复发送或接收。

挑战四：人工排队机制

合理设计IM系统的人工排队机制能够显著提升司用体验，优化客服资源的分配，并改善服务流程，从而降低运营成本。为此，我们付出了大量努力，力求得到一个高效的解决方案。

原有机制存在的问题：

升级之后：

系统演进之路

自研IM系统的演进过程中，满足业务需求的挑战始终存在，我们需要不断地升级迭代，才能更好给司用提供服务，提升坐席接待效率。

收益分析

未来展望自助服务

未来在线IM系统将通过融合流程编排配置化的自助服务，在聊天过程中引入动态表单功能，智能引导司用提交必要信息，以便更准确地描述问题，让司用无需与客服直接互动即可轻松获得所需信息和解决方案。在转接到人工客服时，系统将整理司用数据，帮助客服快速了解诉求，提高问题解决效率。

人机协作

为提升人工接待效率并为司用提供更优质的体验，我们将引入人机协作的模式。在这种模式下，当客服同时接待多个司用时，智能客服助手将与客服协同工作，实时提供支持和信息。人机协作机制将相辅相成，高效地满足司用需求，确保服务的及时性和准确性，从而整体提升司用体验。

结论

在线客服IM系统设计旨在提升司用体验，采用灵活的架构确保可扩展性和稳定性。同时，系统通过有效利用数据来优化服务流程，并集成自动化工具以提高客服效率。持续改进和迭代也是设计的重要环节，以适应不断变化的业务需求。最终，IM系统不仅促进高效沟通，还提升客户满意度，助力货拉拉的持续发展和竞争力。