一
介绍
在企业客服场景中，客服发送消息的背后，需要考虑网络通信、前端显示、后端存储、安全等多方面的技术支撑。 单从前端层面来说，就需要考虑消息的展示，在状态更新、稳定传输、极限操作消息无延迟等场景下，随着IM系统的不断更新迭代，已经实现了构建从外部采购到自研的一站式全场景工作台。 我们可以明显感觉到客服对于IM体验的要求越来越高，所以客服发送消息背后的技术和思维也变得越来越重要。 本文将探讨客服发送消息背后的技术和思维，帮助大家了解如何在IM聊天场景中提供高效、安全、可靠、良好的用户体验。
二
IM 聊天消息的重要性
IM聊天消息是客服与用户之间最快、最直观、最高效的双向沟通方式之一。 IM聊天的重要性体现在以下几个方面：
综上所述，IM聊天消息的重要性在于提高用户满意度，提高客户服务效率。 这也意味着IM消息的可靠性、高效性、安全性显得尤为重要。 接下来，本文将从前端角度考察向客服发送消息背后的技术。 以及详细的想法。
三
客服IM消息的发展历史
以下是客服IM消息的发展历史，列出了核心技术项目的里程碑。
在这个过程中发信息软件，我们积累了一定的经验和技能，也遇到了各种问题和挑战。 比如：消息丢失、消息发送失败、消息重复、消息乱序等问题。我们也通过技术专业化一一解决了这些问题，达到了预期的效果。 我们相信，随着技术的不断发展、创新，我们能够更好地提供更高效、便捷的服务。
四
技术细节与思维
从用户/客户服务的角度来看，发送消息不就是点击回车键或者输入消息后点击发送按钮吗？ 看似很简单，但是从开始输入消息到对方收到消息的过程其实是非常强大的。 技术以高效、稳定为支撑。 我们的客服IM消息链路会涉及三个核心端口，发送方、IM网关和接收方。 下面简单介绍一下客服侧向IM网关发送消息过程中涉及到的技术点。 反之，用户侧发送消息则类似。
从上面的流程图我们可以看到，一条消息的旅程还是很丰富的。 当然，有些细节还没有完全列出来，比如：IM网关的超时重推机制、前端异常处理（网络异常、超时异常、重试不成功等）。 我们可以清楚地看到，当客服开始输入消息时，就开始通知对方正常输入。 触发消息发送后，需要创建消息体、排序、去重检测、网络检测、聊天列表渲染、推送超时重置等。 尝试队列，放入消息拦截器统一转换消息格式发送。 至此，您刚刚完成了前端层面的发送工作。 目前，消息是否发送成功还不得而知。 您还需要监控消息发送结果。 如果在一定时间内没有收到回复，则该消息将重新发送第二次。 直到消息发送成功或者达到最大重试次数，消息的生命周期结束。
一旦收到消息的响应结果，就会更新消息的状态（此时消息已经排序，不需要二次排序）。 至此，第一步处理完成，也会有一条消息从IM网关发给客户端。 类似的处理。
纵观整个消息发送和接收环节，任何一个环节出现问题都会导致消息发送出现问题，这需要非常稳定可靠的技术手段来保证。 这主要从以下几个方面来说明。
消息的可靠传递
消息的可靠传递保证了消息双方信息的一致性。 这就是为什么我们把可靠的消息传递放在第一位来解释。 让我们想象一个场景，消息经常丢失，而客户服务提供频繁的反馈。 每次都要投入研发资源来解决问题。 这仍然是次要的。 消息丢失可能会导致用户体验急剧下降发信息软件，得不偿失。 。 所有消息的可靠传递是非常有必要和必要的。 那么什么是可靠传递？至少要满足三个方面： 1.1 消息的实时性
我们使用IM最重要的一个方面就是希望对方能够实时收到我们发送的消息并且能够回复，这对于提高用户体验尤为重要。 如果我们不关心实时性能，我们可以使用其他方法，比如电子邮件、写信甚至放飞鸽子来发送信件……
当消息发送到IM网关时，网关一般需要经过以下五个步骤：
就消息的实时性而言，没有绝对的实时，只能尽可能地优化。 核心处理逻辑在IM网关。 无论是前端还是客户端，处理过程都非常快，达到毫秒级别。 我们的IM网关是用Go语言开发的，并发处理能力也很高，所以整个闭环的耗时还是很低的。
1.2 消息的可靠性
众所周知，TCP本身是可靠的，但它只能保证传输层的可靠性，无法保证应用层之间的可靠性。 以后我们还会有针对性地专门发表文章，这次就不详细说了。
那么我们如何保证应用之间的可靠性呢？ 可靠性的保证就是让发送者知道接收者已经收到了消息，这意味着消息已经成功传递。 我们回顾一下上面描述的消息丢失场景。 消息丢失的问题也是我们在IM消息开发过程中遇到的一个头疼的问题。 解决一个问题需要的技术资源非常庞大，需要投入。 H5、IM网关、服务器和客户端对于用户和客服的体验非常差。 一个很简单的场景，用户发送消息，但是客服没有收到，也没有回复用户。 用户认为客服故意不回复，影响用户满意度。
那么如何解决这个问题呢？ 大家可以看看得物客服IM消息通讯SDK的自主开发之路，已经有讲解了。 核心是参考TCP协议的ACK机制，实现一套基于业务层的ACK协议。 这里需要特别注意的是，对于批量消息（客服刷新会话、新会话进来等），我们采用的是批量ACK机制。 如果每条消息都回复ACK，成本会比较高。 一开始我们采用了IM架构升级技术，协同所有终端完成整体IM消息到达，做到零丢失，保证到达，满足至少一次（通过数据嵌入点验证后到达率100%）。 上线后，现场达到了预期效果，相应的故障排查投入减少了至少70%+。
1.3 消息的有序性
在IM开发过程中，有一个很常见的场景，用户先问A问题，然后再问B问题。在客服端，B问题排在A问题之前，导致客服回复混乱。 当然，这只是IM消息乱序的场景。 类似这样的还有很多。 消息乱序的原因有很多。 例如，发送一个文件，然后立即发送一条消息。 前端需要将文件上传到OSS获取URL，然后发送给用户。 在上传文件的过程中，用户和客服都可以发送消息。 这个场景如果处理不好的话，很容易出现消息乱序的情况。
如果你不做IM，你真的不会想到客户服务运作会有多么高效。 在处理消息乱序问题时，遇到客服连续发送2条消息，间隔只有300毫秒。 这是一个高频次、密集型的操作场景。 在客服工作场景中，是连续的。
这似乎是一个无序问题。 如果不明确考虑用户群体、极端场景、临界值等，这个问题就无法彻底解决。
回到我们的客服IM，我们如何处理消息排序呢？ 整个开发过程也相当曲折。 最终以IM网关维护的Seq为标准，然后返回给发送者。 发送方按照消息序列号对消息进行排序，以保证发送方和接收方消息排序一致。 前端处理流程如下：
1.4 消息的幂等性
说到消息的幂等性，我们要思考一个问题，为什么我们会收到多条（>1）相同的消息？ 一定是发件人重复发送造成的。 什么情况下会重演？ 刚才讲了应用层的ACK机制。 如果没有收到对方的ACK，则在超时时间达到最大重试次数后继续重复发送。 参考下面的截图会更容易理解。 这只是模拟消息重试。 实际场景中的执行频率肯定会比这个长。
由于必须保证消息的可靠性，因此消息的重复是不可避免的。 可能存在消息幂等性问题。 那么如何解决呢？ 我们使用消息的Message ID来去重，这就涉及到一个性能问题。 排序、去重、风控信息验证等都需要一定的计算成本。 如何保证处理系统不卡顿是一个核心问题。 如果您想了解我们的客服IM是如何完成的，请继续阅读下文。
导致消息处理的优化策略
我们思考一下为什么会出现滞后？ 什么样的场景可以被认为是卡住了？ 我们一般说是16ms内无法完成渲染导致的。 那么为什么需要在16ms内完成呢？ 这里我们需要了解刷新率（RefreshRate）和帧率（frameRate）。
如果帧率为每秒60帧，屏幕刷新率为30Hz，那么屏幕的上半部分将保持在上一帧，屏幕的下半部分将渲染下一帧。 这种情况称为屏幕撕裂。 相反，如果帧率为每秒30帧，屏幕刷新率为60Hz，那么连续两帧就会显示同一张图片，就会造成卡顿。 因此，单方面提高帧率或者刷新率是没有意义的。 两者都需要同时改进。 浏览器都使用 60Hz 的刷新率。 为了达到60FPS的帧率，要求在16.67ms内完成一帧的绘制（1000ms/60frame=16.666ms/frame）。
IM 消息处理中的卡顿现象非常常见。 到了一定程度，这是一个难以避免的问题。 相比我们经常使用电脑，打开多个浏览器标签页，长时间不关机重启的情况，也会出现这种情况。 感觉卡住了，但是优化IM消息处理的方法还是有很多的，主要涉及以下几个优化策略：
2.1 异步处理
众所周知，JS是单线程的，因此可以利用异步处理机制，将低优先级任务推入异步任务队列，将主线程让给高优先级任务。 例如，客服在输入消息后需要立即显示的聊天页面如果短时间内没有显示，就会认为系统卡住了，所以发送消息的优先级高于接收消息。 我们区分了各个场景的任务优先级，低优先级任务异步处理。
2.2 部分加载
这里主要关注的是聊天消息列表。 对于大量消息的会话处理，只渲染可见区域的消息，减轻了浏览器的负担，提高了响应速度。 列表优化有很多选项。 如下：
方案一：使用定时器setTimeout实现批量渲染。 我们一般不推荐这种方法，因为在setTimeout中操作DOM必须等到下次绘制屏幕时才能更新到屏幕上。 如果两个步骤不一致，可能会导致中间一帧的操作被跳过，直接更新下一帧的元素，导致丢帧。
选项 2：使用 requestAnimationframe。 相比之下，requestAnimationframe的优势还是非常明显的，主要体现在以下几个方面：
选项 3：使用 IntersectionObserver。 IntersectionObserver 接口（附属于 Intersection Observer API）为开发人员提供了一种异步监视目标元素及其祖先或视口的相交状态的方法。 祖先元素和视口称为根。
正如你所看到的，交叉意味着当前元素在窗口中并且当前可见。 是替代监控滚动加载的一个很好的解决方案。
当然，还有其他的解决方案，您还是需要根据实际业务场景选择合适的解决方案。 IM消息分段加载的难点在于消息的高度可变（多种不同类型的消息），而且计算成本还是有些昂贵。 因此，优化仍需验证临界值。 有时优化可能并不有效。
2.3 消息遍历
上面我们讲了消息排序、去重、消息状态更新等，如果多个会话中有大量聊天消息，处理不好势必会出现卡顿的情况。 大家可以先看一下我们优化之前的处理流程，使用第三方SDK有一堆for循环。 如果消息量大的话，基本上就会卡住，变得无响应。
那么我们该如何处理这个问题呢？ 根据现有业务场景重写第三方SDK，将Session维护为独立实例。 核心算法采用二分法。 有兴趣的同学可以看一下之前这篇关于客服IM消息SDK自主开发之路的文章，里面有比较详细的介绍。 重写IM SDK后，客服不再报告任何与聊天相关的延迟，聊天的首次调用提高了20%。 结果是相当显着的。
消息安全注意事项
在IM系统中，消息安全非常重要。 开发人员需要有较强的安全意识，将安全融入到开发过程中，以增强系统的安全性和健壮性。 我们在消息安全方面做了很多工作，这里不再赘述。
消息发送和接收延迟
消息发送和接收的延迟直接影响用户体验和沟通效率。 上面我们分析了一条消息的路程，延迟的原因就比较容易分析了。 主要有四点：
既然分析了原因，我们就可以对症下药，通过一些优化策略来减少发送和接收的延迟。 目前我们计划从以下两个方面进行优化：
编码时间：ProtoBuf的编码时间比JSON快很多，因为ProtoBuf的编码是二进制的，不需要编码转换和多余的类型转换。 JSON 编码相对较慢。
解码时间：与编码相比，ProtoBuf的解码效率稍低。 但由于ProtoBuf在数据量较大且结构复杂时优势更加明显，因此在解码小数据时两者的效率差异可能并不明显。
因此，使用ProtoBuf格式代替JSON格式，基本上可以解决大部分延迟问题，这也是接下来IM优化的一个方向。
座席体验和交互注意事项
在座席体验和互动方面，我们积累了很多经验。 不仅仅是IM，体验和交互是所有产品都无法回避的话题。 自从我们创立IM以来，经验一直是我们不断前进的动力。 、卡顿是一直萦绕在我耳边的话题。 客户服务理解的滞后与我们通常理解的滞后有点不同。 前期我们也以为系统卡住了，无法使用。 这类似于丢帧场景，但实际情况并非如此。 接口请求慢且有错误。 提示 提示、切换页面时出现短暂空白、输入消息后聊天页面没有立即显示消息、图片上传的加载提示等都属于卡顿。 针对这些方面，我们不断进行职场调研、数据分析和优化，客户服务满意度提升至18%。 或许在大家看来，时隔这么久，18%的增幅并不是一个好数字，但对于客服领域来说，18%的增幅也是一个比较难克服的数字。 主要原因有两个方面：第一个方面是很多客服人员入职3个月以内，我们做的一些功能优化对比看不懂或者缺乏功能使用对比； 第二个方面是，很多一线工作人员的客服都来自于一线厂商的客服团队。 其实，如果反过来想，这也是一种正向驱动。 至少我们每次做调查都可以收集到新的反馈，可以看到与更成熟、更优秀的产品的经验差距。
经验不是一朝一夕就能获得的。 不要想着一下子就把事情全部做好。 优秀的用户体验和交互设计需要时刻结合用户需求和反馈，不断改进和完善。 在实际的设计和开发过程中，需要不断的测试和优化，以保证系统的质量和可接受性。 同时，我们需要积极与用户沟通和反馈，以便更好地了解用户的需求和意见。 我们以前没有做得很好，特别是在新版本的推广方面。 系统的易用性还没有达到客户服务的水平。 期望也是我们未来需要继续改进的一个方面。
体验是基于绝大多数用户的需求。 你不能仅仅为了少数用户而牺牲其他用户的体验。 特别是不能因为一个用户的反馈而做出过多的改变或者牺牲其他用户的利益。 。 在体验优化过程中不妥协也是一个非常重要的策略。 在体验优化过程中，必须保持理性客观，根据用户研究和数据分析做出合理的权衡和决策，以达到最佳的用户体验。
一些小细节的优化也能达到事半功倍的效果。 在IM系统中，一些细节的优化包括：及时的消息提示、清晰的消息显示、准确的消息发送时间等，这些小细节的优化可以直接提高客户服务效率和体验，从而提高客户服务满意度。 我们将持续优化 IM 体验。 有志者，事竟成。
五
后续规划
上述技术和思考细节包括消息的可靠传递、延迟优化、安全性、效率和体验。 未来一段时间，我们仍会围绕这些方面继续优化和完善IM。 相关能力。 主要考虑以下几个方面的规划：
在上述方面，我们将优先考虑重要且紧迫的技术改造。 我们不会盲目创新和优化。 我们还是会以业务为主，注重业务和代理体验。
六
总结
在 IM 应用中，通过客服发送消息看似简单，但有很多技术细节需要考虑。 首先，这需要考虑到消息传递机制和可靠性。 即使是一条简单的消息，也需要经过一系列的加密、编码、传输、安全合规等之后才能成功接收。
最重要的是要考虑各种极端场景下的实时数据和操作问题。 客服发送的消息需要在聊天页面显示并及时传递给用户。 从事一对多场景的客服同学需要保证每个会话中不会出现消息不一致（丢失、重复），以及消息拦截、异常情况等问题。
因此，客服不仅需要发送消息的技术能力和数据处理能力，还需要考虑座席体验和实时数据等问题。 在开发过程中，需要详细处理各种问题并不断优化，为客户提供稳定、流畅、安全、友好的IM应用。
参考文章：
得物客服IM消息通讯SDK自主发展之路
