一、背景
客服 IM 的外围业务就是在线沟通，客服与用户通过实时沟通的形式能够在最短的工夫内帮忙用户解决问题。初期为了疾速撑持业务需要，便基于第三方 SDK 进行了二次开发，同时也埋下了问题定位艰难，非凡性能实现老本低等隐患。随着公司业务的疾速倒退，客服对 IM 聊天的性能和体验都有了更高的要求，第三方 SDK 音讯通信逐步遇到了瓶颈，为解决第三方 SDK 接入带来的潜在隐患、晋升 IM 的稳定性和高扩展性，自研一套可控、稳固、灵便的 IM 零碎已是无奈避开的一条路线了。以下次要是以客服端 (web) 为主。
二、思考
客服与用户在聊天过程中，直观上是客服在输出文案，而后通过网络发送给用户，然而 SDK 该如何设计能力使客服在发送音讯过程中感知不到卡顿，这一点是十分要害的，要防止卡顿就要设计正当的发送策略以及防止大量 JS 脚本执行，举个客服与用户聊天的例子：
客服发送了“客服小冰为您服务”这个文案，通过业务侧调用 SDK 的接口，传入到 SDK 里，SDK 会先创立音讯体，即把这个字符串封装成一个自定义的构造体 model；
再将该数据存储到数据池中，序列化后把这个数据对象 data 传递给 socket 接口，通过网络通道发送到网关；
网关侧接管到音讯后，再反序列化，传递到数据池中进行解决，组装成业务可辨认的 model，推送到业务侧应用。
其聊天流程如下：
如上图所示，能够清晰的看出音讯发送和接管的流程链路。如果 SDK 设计不合理，发送音讯和接管音讯流程呈现了卡顿，将间接影响用户的体验。
三、自研框架架构图
整体的技术改造有两个方面：
对音讯链路的形象革新：次要是音讯数据存储和音讯排序的重构。业务接入侧的形象革新：次要是将业务逻辑和 SDK 源码进行解耦，做到代码分层更加的清晰。
四、音讯链路公布订阅实现
在 SDK 自研开发过程中，如何解耦框架代码和业务代码，做到灵便的音讯监听，后期调研之后应用了 RxJS，这里简略介绍几个 RxJS 的外围概念：
Observable(可察看对象)：示意一个可调用的将来值或事件的汇合。Observer(观察者)：监听由 Observable 提供的值。Subscription (订阅)：示意 Observable 的执行。Subscription 有一个重要的办法，即 unsubscribe，它不须要任何参数，只是用来清理由 Subscription 占用的资源次要用于勾销 Observable 的执行。
SDK 底层在接管到数据后须要同步到业务侧，之前的做法是通过监听形式实现，这种形式不具备勾销订阅的能力，保护老本绝对较高。而应用 RxJS 能够清晰的梳理出数据流向，通过公布订阅的形式实现数据的通信。RxJS 在公布订阅的实现流程如下：
从上图能够看到音讯解决的整个流向十分清晰，框架底层接管音讯，订阅者生产音讯。
五、音讯框架的分层实现
在整个 IM 音讯通信框架中，次要有三层构造：网络层、数据链路层和应用层，如下：
1、网络层
网络层作为音讯发送的最底层，负责 TCP 的连贯，音讯发送 & 接管，网络协议咱们抉择的是 TCP 协定，咱们为什么没有抉择 UDP 呢？因为 UDP 是无连贯的，不够平安，无奈提供牢靠传输的服务，通过 TCP 连贯传送的数据能够无差别、不失落、不反复且按序达到。
整个 SDK 的通信形式咱们采纳的是 Websocket + Json、grpc + protobuf，第一步咱们要做的就是建设 Websocket 连贯，代码层面咱们会先创立一个 Connection 的抽象类，次要解决网络连接相干配置、超时后从新连贯的弥补实现，和一些继承类须要实现的形象办法。
如上述代码所示，外围在解决超时重连，传统的重试策略是每隔一段时间重试一次，因为是固定的工夫距离重试，重试时又会有大量的申请在同一时刻涌入，会一直地造成限流。这里应用了指数退却的形式，指数退却是一种通过反馈，成倍地升高某个过程的速率，以逐步找到适合速率的算法，可依据时隙和重试尝试次数来决定提早重试，其实现算法大抵如下：
Websocket 的连贯咱们是通过继承 Connect 类实现的，如下：
至此网络层连贯就已实现了，绝对比较简单，都是一些 socket api 的封装，外围的点在用指数退却算法实现音讯发送失败重连贯。
2、数据链路层
数据链路层是 SDK 的核心层，次要波及到用户信息、音讯、数据池等等，咱们来一步步对每个模块进行剖析。首先梳理一下客服在登录到用户进线发送音讯和接管音讯的全过程，过程有如下几个阶段：
2.1 协定类型
音讯协定类型十分重要，是音讯发送的基石。初始化协定数据体，能够用于后续各种音讯、事件的发送。在 IM 自研的 SDK 通信协议类型次要有如下几种：
- Hi：发送客户端根底信息，通知 server 以后 client 的版本、设施类型、语言等信息
- Login: 登录，token 验证，获取或创立以后用户 topic 信息
- Sub: 订阅 topic 或更新 topic 数据
- Leave: 勾销订阅，解绑之前的订阅关系
- Pub: 发送数据音讯给指定 topic 的订阅者
- Get: 获取 topic 的 metadata 信息，例如：获取订阅者列表、历史数据等
- Set: 更新 topic 的 metadata 信息，例如：删除音讯或删除 topic
- Del: 用于删除操作，包含删除音讯、删除订阅关系、删除 topic 等
- Note: client 发送告诉给 topic 的订阅者，例如音讯已收到，音讯已读，以后正在输出等
- Action: 触发的事件，例如：切换客服状态、获取机器人问题等
- Datares: ack 机制，通知网关已收到该音讯
2.2 创立连贯
对网络层音讯链接实例化，实现音讯的失常发送和接管，其实现如下：
2.3 音讯定义
客服要发送一条音讯，必定有对应的音讯构造体 model，即须要对音讯体进行设计，这里会设计一下 message 类，每次创立新的音讯体都会 new 一个实例，通过对实例的操作能够更新音讯状态等，如下：
针对单个音讯，咱们也要定义好消息状态，用于聊天过程中音讯状态的更新，如下：
2.4 数据池
音讯类创立好之后，就须要有音讯数据池来存储，音讯池构造定义如下：
这里还波及到音讯体的一些基本操作办法对数据池中的数据进行操作，就不做过多的论述。
2.5 用户维度
下面都是在剖析公共模块，然而客服和用户是一对多的关系存在，还须要设计一个用户维度模块，后续在业务侧的操作根本都是以用户维度来操作，须要从单个用户维度设计对应的订阅关系、音讯发送、删除等等。其实现大抵如下：
2.5.1 发送音讯链路剖析
针对客服发送音讯，咱们首先要站在客服角度思考音讯是否已收回去，优先展现的聊天页面，而不是等网关给了回复后在展现到聊天页面，依据已往教训来看，只有回车音讯就要立刻展现到聊天页面，否则客服会认为呈现了卡顿，体验成果不佳，鉴于这种场景的需要，在设计发送音讯链路的时候就要充分考虑到这一点，所以设计流程如下：
如上图所示，先在 SDK 内进行解决对应的音讯，解决实现后返回到业务侧实现渲染后再进行音讯发送到网关，失常状况下都在一帧之内，客服是感知不到有提早的，这里要关注音讯体序列化、反序列化的机会，防止无谓的性能节约。上述图中有个虚构 seq，次要是为了在未收到 IM 网关响应之前进行排序用的，图片、视频、断网发送音讯、音讯发送失败，或收到 IM 网关回复短少 seq(场景：敏感词)等状况都须要通过虚构 seq 进行精确排序。
2.5.2 接管音讯链路剖析
接管音讯过程绝对比较简单，收到音讯进行反序列化后更新相干数据，而后在数据池中实现去重(重试机制)、排序后更新到业务侧渲染即可。
2.5.3 音讯的牢靠传递
IM 音讯的牢靠投递次要是指：音讯在发送接管过程中，可能做到不丢音讯、音讯不反复、音讯程序不错乱。咱们先来剖析以下 2 种状况：
第一种：如果客服 A 在把音讯发送到 IM 网关的过程中，因为网络不通等起因失败了；或者 IM 网关接管到音讯进行存储时失败了；或者 IM 网关始终没有返回后果，导致超时，这些状况客服 A 都会被提醒音讯发送失败。
第二种：音讯在 IM 网关存储完后，客服 A 被告知音讯发送胜利了，而后 IM 网关把音讯推送给用户 A 的在线设施。在推送的筹备阶段或者把音讯写入到内存后，如果服务端呈现掉电，也会导致音讯不能胜利推送给用户 A。如果用户 A 的设施在接管到音讯，在后续处理过程中呈现问题，也会导致音讯失落。比方：用户 A 的设施在把音讯写入本地 DB 时，出现异常导致落库失败，这种状况下，因为网络层面实际上曾经胜利传输，但用户 A 却看不到音讯。咱们客服 IM 对于音讯失落的解决计划如下：参考 TCP 协定的 ACK 机制，实现一套基于业务层的 ACK 协定。
增加 ACK 之前音讯发送的时序图如下：
– ACK 机制 –
在 TCP 协定中，默认提供了 ACK 机制，通过一个协定自带的规范的 ACK 数据包，来对通信方接管的数据进行确认，告知通信发送方已确认胜利接管了数据。ACK 机制也是相似，须要解决的是：IM 网关推送后如何确认音讯是否胜利送达接管方并明确被接管方所接管。具体实现的时序图如下：
客服或用户在发送音讯的过程中都会携带一个 msgid(32 位的 uuid，相似 TCP 的 sequenceId)，IM 网关在接管到音讯后，会依据 msgid 到数据库中查问是否存在该条音讯，如果存在就不落库，如果不存在就落库，而后再推送到接管方，接管方在收到音讯后会回复 ACK，ACK 包中会携带上以后最新的 seqid，IM 网关收到 ACK 回复后会对最大的 seqid 进行更新。这里为什么要更新最大 seqid 呢？有什么用呢？这么设计必定有肯定情理的，IM 网关在收到发送方发送的音讯后除了到数据库中检测该音讯是否存在外，还会比照以后接管到音讯的 seq 和最大 seqid 两者之间的差值，会把 [seq, seqid) 之间的数据全副推到接管方，失常状况下都是 [n, n-1)，如果 IM 网关没有收到接管方 ACK，n- 1 就不会更新，推送的音讯个数就大于 1 了。如果 seq 和 seqid 相等那就是发送方反复推送的音讯，这个时候就不会向接管方推送。这里就波及到了音讯重试，持续向下剖析吧。
– ACK 机制中的音讯重试 –
音讯推给 A 的过程中失落了怎么办？比方:
- A 网络理论曾经不可达，但 IM 网关还没有感知到(ping 呈现问题)；
- 音讯在两头网络途中被某些中间设备丢掉了。
解决这个问题也是参考了 TCP 协定的重传机制。咱们会在客服端、IM 网关、用户端都保护一个超时计时器，肯定工夫内如果没有收到对方回的 ACK 包，会从新取出该音讯进行重推。在重试肯定次数后，如果还是没有收到 ACK，视为放弃。前端代码构造和成果如下：
上述图片中的数据只是模仿音讯重试，实在场景中执行频次必定要比这个工夫更久一些。
– 音讯反复推送的问题 –
如果在肯定工夫内没有收到 ACK 包，就会触发重试机制。收不到 ACK 的状况有两种，除了推送的音讯真正失落导致 A 不回 ACK 外，还可能是 A 回的 ACK 包自身丢了。
解决方案是：发送方在发送音讯时携带一个 msgid，msgid 是全局惟一的，针对同一条重推的音讯 msgid 不变，接管方依据这个惟一的 msgid 进行去重，这样通过去重后，对于 A 来说，在聊天界面是不会看到反复的音讯，不影响应用体验。
– 保障音讯不会乱序 –
音讯的一致性是十分重要的，在聊天过程中音讯程序不能错乱。
以发送方的本地工夫戳为序号，然而这样有比拟大的问题，发送方的工夫戳是能够被改变的，这种形式不可取；IM 网关服务是集群部署，会通过 topic 和 seqid 做为惟一索引，在接管到音讯落库之前会生成 seqid，客服端和用户端接管到发送音讯的回执时须要依据返回的 seqid(IM 网关自增)进行音讯排序，这种形式可取。
通过以上的剖析，客服 IM 音讯的可靠性就是通过 ACK 机制，重试机制，去重机制，排序机制来确保每一条音讯的残缺触达和精确排序。
3、应用层
业务侧应用的时候间接实例化 SDK 即可，在音讯链路公布订阅中曾经提到了 RxJS，此时在业务侧订阅应用即可。须要留神的是在实例化 SDK 的时候传递了一个 filterMsgItem 办法，次要是为非凡业务场景提供应用的，就拿咱们客服业务来说，有些特定音讯是不须要展现到聊天页面的，比方：用户发送音讯被篡改等，当然咱们在业务侧从新对数据过滤或者渲染的时候也是能够做过滤的，这样操作是没什么问题，然而没有必要，如果不从源头过滤数据，后续参加二分、倒序查找的源数据也会减少。会有一些不必要的节约。当然也能够不增加这个参数，SDK 都是全兼容的。
至此咱们就实现了整个 SDK 的实现以及在业务侧的应用，音讯发送和接管也都失常，成果如下：
六、总结
自研 SDK 还是蛮有挑战的一件事件，从单纯的基于第三方 SDK 二次开发到自研 SDK 并与咱们的理论业务场景绝对完满的联合。在 SDK 的整体设计以及和业务侧如何更完满的联合并不是欲速不达的，都是在理论业务场景中一直积攒教训，一直尝试才找到绝对完满的解决方案。这里列举一个简略的案例吧，例如音讯发送：须要思考到断网场景下该如何进行音讯显示、排序、从新发送？发送失败的场景下从新发送再次失败后又该如何显示、排序？弱网场景下发送音讯触发重试机制该如何以最优的形式去重、排序？发送音讯触发敏感词该如何解决？断网重连后对于发送失败和触发敏感词的音讯又该如何解决？如果在波及到文件又该如何解决？… 在自研过程中除了关注业务场景外，还调研了行业内比拟好的一些 web 利用在某些非凡场景的解决形式。很多优良的计划也都只能是借鉴一些核心思想，还是要以业务为外围，真正通过技术手段解决业务痛点才是最重要的。
自研 SDK 收益还是十分大的，也积攒了很多 IM 方面的教训，实现自研 SDK 也只是一个开始，后续咱们将会在耗时工作、数据安全等方面继续深耕细作。
参考文档：
- RxJS
- TCP/UDP 协定
- 指数弥补（Exponential backoff）在网络申请中的利用
* 文 / 王卫强
@得物技术公众号