一、背景客服IM的核心业务是在线通讯。客服与用户可以通过实时沟通，帮助用户在最短时间内解决问题。前期为快速支撑业务需求，基于第三方SDK进行二次开发。同时也埋下了问题定位难、特殊功能实现成本高等隐患。随着公司业务的快速发展，客服对IM聊天的性能和体验有了更高的要求，第三方SDK消息通信逐渐遇到了瓶颈。稳定性和高扩展性，自研一套可控、稳定、灵活的IM系统是必经之路。以下主要以客服端（web）为主。2、思考客服和用户的聊天过程。直观上，客服就是输入文案，然后通过网络发送给用户。但是，如何设计SDK，让客服在发送消息的过程中不觉得卡顿，就很重要了。是的，要避免卡顿，需要设计合理的发送策略，避免大量JS脚本的执行。举个客服和用户聊天的例子：客服发送“客服小冰为您服务”的文案，通过业务端调用SDK接口，传给SDK，SDK会先创建消息体，即将字符串封装成自定义的结构模型；然后将数据存入数据池，序列化后将数据对象数据通过socket接口通过网络通道发送给网关；网关端收到消息后，反序列化，交给数据池处理，组装成业务可识别的模型，推送给业务端使用。聊天流程如下：如上图，可以清晰的看到消息发送和接收的流程环节。如果SDK设计不合理，发送和接收消息的过程就会卡住，直接影响用户体验。3、自研框架架构图的整体技术改造有两个方面：消息链接的抽象改造：主要是消息数据存储和消息排序的重构。业务接入端的抽象改造：主要是对业务逻辑和SDK源码进行解耦，让代码层次更加清晰。4、消息链接发布订阅的实现在SDK自研过程中，如何将框架代码和业务代码解耦，实现灵活的消息监听。经过前期调研，使用的是RxJS。下面是RxJS的几个核心概念：可观察对象（Observable）：表示一个可调用的未来值或事件的集合。观察者（observer）：监听Observable提供的值。订阅：表示一个Observable的执行。Subscription有一个重要的方法unsubscribe，不需要任何参数，只是用来清理Subscription占用的资源，主要用来取消Observable的执行。SDK底层收到数据后需要同步到业务端。以前的方法是通过监控来实现的。这种方式不具备取消订阅的能力，维护成本比较高。使用RxJS可以清晰的梳理数据流向，通过发布订阅实现数据通信。RxJS在发布和订阅方面的实现流程如下：从上图我们可以看出整个消息处理流程非常清晰，框架底层接收消息，订阅者消费消息。五、消息框架的分层实现在整个IM消息通信框架中，主要分为网络层、数据链路层和应用层三层，具体如下：1.网络层网络层是最底层ofmessagesending，负责TCPConnection，消息收发，网络协议我们选择了TCP协议，为什么不选择UDP呢？由于UDP是无连接的，不够安全，无法提供可靠的传输服务，所以通过TCP连接传输的数据可以无所谓、不丢失、不重复、有序到达。我们使用Websocket+Json，grpc+protobuf作为整个SDK的通信方式。我们需要做的第一步是建立一个Websocket连接。在代码层面，我们首先会创建一个Connection的抽象类，主要处理网络连接相关的配置。重连的补偿实现，以及继承类需要实现的一些抽象方法。如上代码所示，核心是处理超时重连。传统的重试策略是每隔一段时间重试一次。由于是定时重试，在重试的时候会有大量请求同时涌入，会持续造成限流。这里使用指数退避法。指数退避算法是通过反馈以指数方式降低某个进程的速率，逐渐找到合适的速率的算法。延迟重试可以根据时隙和重试次数来确定。实现算法大致如下：我们通过继承Connect类来实现Websocket连接，如下：至此网络层连接已经完成，比较简单。是对一些socketAPI的封装。核心点是利用指数退避算法实现消息发送失败重连。2.数据链路层数据链路层是SDK的核心层，主要涉及用户信息、消息、数据池等，下面我们逐个模块来分析一下。首先我们来梳理一下登录用户呼入线后客服收发消息的全过程。流程分为以下几个阶段：2.1协议类型消息协议类型非常重要，是消息发送的基石。
