一、引言

在企業(yè)客服場景中，客服發(fā)送一條消息的背后，需要考慮網(wǎng)絡(luò)通信、前端展示、后端存儲以及安全性等多個(gè)方面的技術(shù)支持，單從前端層面來說，就需要考慮到消息的顯示、狀態(tài)更新、穩(wěn)定傳輸以及極限操作消息不卡頓等場景，隨著IM系統(tǒng)的不斷更新迭代，已經(jīng)實(shí)現(xiàn)了從外采到自研再到一站式全場景工作臺的搭建，我們能夠很明顯地感知到客服對于IM的體驗(yàn)要求越來越高了，因此客服發(fā)送一條消息背后所涉及的技術(shù)和思考也越來越重要。本文將探秘客服發(fā)送一條消息背后的技術(shù)和思考，幫助大家了解如何在IM聊天場景中提供高效、安全、可靠和良好的用戶體驗(yàn)。

二、IM聊天消息的重要性

IM聊天消息是客服和用戶之間最快速、最直觀、最高效的雙向溝通方式之一。IM聊天的重要性體現(xiàn)在以下幾個(gè)方面：

即時(shí)響應(yīng)：及時(shí)地解答用戶咨詢的問題，更快捷的服務(wù)用戶，提高用戶滿意度。

個(gè)性化互動：可以根據(jù)用戶的需求快速做出個(gè)性化回應(yīng)，從而更好地滿足用戶需求。

數(shù)據(jù)處理和分析：通過對IM聊天消息的處理分析，可以洞察用戶需求、用戶行為，幫助改進(jìn)服務(wù)質(zhì)量。

綜上，IM聊天消息的重要性在于提高用戶滿意度、提高客服作業(yè)效率，這也意味著IM消息的可靠、高效、安全尤為重要，接下來本文就從前端視角對客服發(fā)送一條消息背后的技術(shù)和思考進(jìn)行詳細(xì)的講述。

三、客服IM消息發(fā)展歷程

以下是客服IM消息發(fā)展的歷程，列舉的都是核心技術(shù)專項(xiàng)的里程碑節(jié)點(diǎn)。

圖片

在這個(gè)過程中，我們積累了一定的經(jīng)驗(yàn)和技能，同時(shí)也遇到了各種各樣的問題和挑戰(zhàn)。比如：消息丟失、消息發(fā)送失敗、消息重復(fù)、消息亂序等等方面的問題，針對這些問題我們也都通過技術(shù)專項(xiàng)的方式去逐個(gè)解決并達(dá)到了預(yù)期效果，我們相信，隨著技術(shù)的不斷發(fā)展和創(chuàng)新，我們可以更好地提供更加高效便捷的服務(wù)。

四、技術(shù)和思考的細(xì)節(jié)

站在用戶/客服角度，發(fā)送消息不就是輸入消息后點(diǎn)擊回車鍵或點(diǎn)擊發(fā)送按鈕就完成了嗎，看似非常簡單，但是從開始輸入消息到對方收到消息這個(gè)過程實(shí)際上有非常強(qiáng)大的技術(shù)在高效、穩(wěn)定支撐。我們客服IM消息鏈路會涉及到三個(gè)核心端口，發(fā)出方、IM網(wǎng)關(guān)以及接收方。以下將以客服發(fā)送一條消息到IM網(wǎng)關(guān)這個(gè)過程簡單描述一下涉及到的技術(shù)點(diǎn)，反之用戶側(cè)發(fā)送消息也是類似的。

圖片

從上述流程圖中可以看到一條消息的旅程還是非常豐富的，當(dāng)然其中有一些細(xì)節(jié)點(diǎn)還沒有完全列舉出來，例如：IM網(wǎng)關(guān)的超時(shí)重推機(jī)制、前端的異常處理(網(wǎng)絡(luò)異常、超時(shí)異常、重試無果等)。我們可以很清晰地看到當(dāng)客服開始輸入消息的時(shí)候就開始進(jìn)行通知對方正常輸入，觸發(fā)消息發(fā)送后需要進(jìn)行消息體的創(chuàng)建、排序、去重檢測、網(wǎng)絡(luò)檢測、聊天列表渲染、推入超時(shí)重試隊(duì)列、放入消息攔截器中統(tǒng)一進(jìn)行消息格式轉(zhuǎn)化并發(fā)送，到這里只僅僅是完成了前端層面的發(fā)送工作而已，此時(shí)消息是否發(fā)送成功還是未知的，還需要監(jiān)聽消息的發(fā)送結(jié)果，如果在一定時(shí)間未收到響應(yīng)結(jié)果會進(jìn)行第二次消息的重發(fā)，直到發(fā)送成功或到達(dá)最大重試次數(shù)就表示該消息的生命周期結(jié)束。一旦收到消息的響應(yīng)結(jié)果就會對消息的狀態(tài)進(jìn)行更新(此時(shí)消息已完成了排序，不需要進(jìn)行二次排序)，至此第一個(gè)環(huán)節(jié)就完成了處理，IM網(wǎng)關(guān)到客戶端也會有類似的處理過程。

縱觀整個(gè)消息發(fā)送以及接收鏈路，任何一個(gè)環(huán)節(jié)出現(xiàn)問題都會導(dǎo)致消息發(fā)送出現(xiàn)問題，就需要非常穩(wěn)定可靠的技術(shù)手段進(jìn)行保障，主要從以下幾個(gè)方面講解一下。

消息的可靠性傳遞

消息的可靠性傳遞確保了消息收發(fā)雙方信息的一致性。這也是我們?yōu)槭裁窗严⒖煽啃詡鬟f放在第一個(gè)進(jìn)行講解。我們試想一下這樣一個(gè)場景，經(jīng)常有消息丟失，客服頻繁反饋，每次都要投入研發(fā)資源去排查問題，這還是次要的，有可能因?yàn)橄⒌膩G失導(dǎo)致用戶體驗(yàn)的急劇下降，這就得不償失了。所有消息的可靠性傳遞是非常有必要的，而且也是必須的。那么何為可靠性傳遞？至少要滿足3個(gè)方面：

1.1 消息的實(shí)時(shí)性

我們使用IM最重要的一方面就是希望對方能夠?qū)崟r(shí)接收到我們發(fā)送的消息并能夠給予回復(fù)，這對于提升用戶體驗(yàn)尤為重要。如果不在乎實(shí)時(shí)性我們完全可以使用其他方式，例如郵件、寫信甚至飛鴿傳書…

一條消息發(fā)送給IM網(wǎng)關(guān)，網(wǎng)關(guān)大致需要經(jīng)歷以下5個(gè)環(huán)節(jié)的處理：

驗(yàn)證消息：敏感詞驗(yàn)證、風(fēng)控送審(同步審核)

消息的存儲：排序、去重驗(yàn)證等

給發(fā)送消息方回復(fù)一個(gè)ACK響應(yīng)(成功、失敗)

把消息發(fā)送給接收方，如果存在多端登錄的場景，還需要保障消息多端同步

超時(shí)重試、處理接收方返回的ACK等

從消息的實(shí)時(shí)性的來說，沒有絕對的實(shí)時(shí)，只能盡量優(yōu)化。核心的處理邏輯都在IM網(wǎng)關(guān)，無論是前端還是客戶端，處理過程都是非?？斓?，都在毫秒級別。我們IM網(wǎng)關(guān)是Go語言開發(fā)的，并發(fā)處理的能力也是非常高的，所以整個(gè)閉合鏈路的耗時(shí)還是非常低的。

圖片

1.2 消息的可靠性

眾所周知，TCP本身就是具有可靠性的，但是它只能保障傳輸層可靠，而應(yīng)用層之間的可靠性并不能保證，我們后續(xù)會有針對性的專項(xiàng)文章進(jìn)行發(fā)表，本次就不再贅述。

那我們該如何保障應(yīng)用之間的可靠性呢? 可靠性的保障就是讓發(fā)送方知道接收方接收到了消息，這樣就表示消息成功傳遞了。我們再回頭看一下上面講述消息丟失的場景，消息丟失的問題也是我們在IM消息研發(fā)過程中遇到的一個(gè)讓人頭疼的問題，排查一個(gè)問題需要投入的技術(shù)資源是非常巨大的，需要涉及到H5、IM網(wǎng)關(guān)、服務(wù)端以及客戶端，對于用戶以及客服的使用體驗(yàn)是非常差的。很簡單的一個(gè)場景，用戶發(fā)了消息，客服沒有收到，沒有回復(fù)用戶，用戶以為客服故意不回復(fù)，會影響到用戶的滿意度。

那這個(gè)問題該如何解決呢？大家可以看下得物客服IM消息通信SDK自研之路，其中有講解過，核心是參考TCP協(xié)議的ACK機(jī)制，實(shí)現(xiàn)一套基于業(yè)務(wù)層的ACK協(xié)議。這里特別的要注意的是針對批量消息(客服刷新會話、新會話進(jìn)線等場景)，我們采用的是批量ACK機(jī)制，如果每一個(gè)消息都回復(fù)ACK，成本會比較高。我們當(dāng)初是通過一個(gè)IM架構(gòu)升級技術(shù)專項(xiàng)協(xié)同各端完成了IM整體消息觸達(dá)實(shí)現(xiàn)0丟失，保證觸達(dá)，滿足At least once（通過數(shù)據(jù)埋點(diǎn)驗(yàn)證后得到100%的觸達(dá)率）。上線后該場景符合預(yù)期效果，相應(yīng)的問題排查投入也減少了至少70%+。

1.3 消息的有序性

在開發(fā)IM過程中有這樣一個(gè)非常常見的場景，用戶問A問題后又問題了B問題，在客服側(cè)B問題排到A問題的前面，導(dǎo)致客服的回復(fù)也出現(xiàn)了錯(cuò)亂。當(dāng)然這只是IM消息亂序的一種場景而已。諸如此類的還有很多。消息亂序產(chǎn)生的原因有很多，例如發(fā)送文件后再立即發(fā)送消息，文件需要前端先上傳到OSS獲取到URL后再發(fā)送給用戶，上傳文件這個(gè)過程，用戶以及客服都是可以發(fā)送消息的，這種場景處理不好就極易出現(xiàn)消息亂序。

不做IM是真不會想到客服操作的效率會有多高，之前在處理消息亂序問題的時(shí)候有遇到客服連續(xù)發(fā)送了2條消息，間隔只有300毫秒，這種高頻密集的操作場景在客服的工作場景下是持續(xù)性的。

看似一個(gè)亂序問題，不考慮清楚用戶群體、極限場景、臨界值等都不會徹底解決掉這個(gè)問題。

再說回我們客服IM，我們是如何處理消息排序的呢？在整個(gè)開發(fā)過程也是比較曲折的，最終是以IM網(wǎng)關(guān)維護(hù)的Seq為準(zhǔn)，然后返回到發(fā)送方，發(fā)送再根據(jù)消息序號進(jìn)行排序，確保發(fā)送方和接收方消息的排序是一致的。前端處理的流程如下：

1.4 消息的冪等性

說到消息的冪等性，我們要思考一個(gè)問題，為什么會收到多條(>1)相同的消息呢？肯定是發(fā)送方重復(fù)發(fā)送導(dǎo)致的，那在什么場景下會重復(fù)發(fā)送？前面剛講過應(yīng)用層的ACK機(jī)制，如果沒有收到對方的ACK，會在超時(shí)時(shí)間到達(dá)后繼續(xù)重復(fù)發(fā)送直到最大重試次數(shù)。參考下面的截圖會更容易理解，只是模擬消息重試，真實(shí)場景中執(zhí)行頻次肯定要比這個(gè)時(shí)間更久一些。

圖片

既然要保證消息的可靠性，消息的重復(fù)就是無法避免的。就有可能出現(xiàn)消息冪等性問題。那怎么解決呢？我們是利用消息的Message ID做去重的，這里會涉及到一個(gè)性能問題，排序、去重以及風(fēng)控信息驗(yàn)證等都需要一定的計(jì)算成本，如何保證處理過程系統(tǒng)不卡頓是一個(gè)核心問題。想要了解我們客服IM是如何做的，請繼續(xù)向下看。

消息處理的卡頓優(yōu)化策略

我們來想一下為什么會出現(xiàn)卡頓？什么樣的場景才能夠被視為卡頓呢？我們一般都會說是因?yàn)樵?6ms內(nèi)無法完成渲染導(dǎo)致的。那么為什么需要在16ms內(nèi)完成呢？這里我們就要了解一下刷新率（RefreshRate）與幀率（FrameRate）。

• 刷新率指的是屏幕每秒刷新的次數(shù)，是針對硬件而言的。瀏覽器刷新率都在60Hz（屏幕每秒鐘刷新60次）。
• 幀率是每秒繪制的幀數(shù)，是針對軟件而言的。通常只要幀率與刷新率保持一致，我們看到的畫面就是流暢的。所以幀率在60FPS時(shí)我們就不會感覺到卡。

如果幀率為每秒鐘60幀，而屏幕刷新率為30Hz，那么就會出現(xiàn)屏幕上半部分還停留在上一幀的畫面，屏幕的下半部分渲染出來的就是下一幀的畫面，這種情況被稱為畫面撕裂。相反，如果幀率為每秒鐘30幀，屏幕刷新率為60Hz，那么就會出現(xiàn)相連兩幀顯示的是同一畫面，這就出現(xiàn)了卡頓。所以單方面的提升幀率或者刷新率是沒有意義的，需要兩者同時(shí)進(jìn)行提升。瀏覽器都采用的60Hz的刷新率，為了使幀率也能達(dá)到60FPS，那么就要求在16.67ms內(nèi)要完成一幀的繪制（1000ms/60Frame = 16.666ms / Frame)。

IM消息處理中出現(xiàn)卡頓的情況非常常見，到一定的量級都是一個(gè)很難避免的問題，對比我們經(jīng)常使用電腦，打開多個(gè)瀏覽器頁簽，稍微時(shí)間長點(diǎn)不關(guān)機(jī)重啟，也會感覺到卡頓，但對于IM消息處理還是有很多方式進(jìn)行優(yōu)化的，主要涉及以下幾方面的優(yōu)化策略：

2.1 異步處理

眾所周知JS是單線程的，所以采用異步處理機(jī)制可以將優(yōu)先級低的任務(wù)推入異步任務(wù)隊(duì)列，讓出主線程給優(yōu)先級高的任務(wù)。比如：客服在輸入完消息后需要立即顯示的聊天頁面，如果存在短暫的不顯示，會被認(rèn)為是系統(tǒng)卡頓了，所以發(fā)送消息的優(yōu)先級是高于接收消息的。我們對各場景任務(wù)優(yōu)先級做了區(qū)分，低優(yōu)先級的任務(wù)都通過異步的方式進(jìn)行處理。

2.2 分段加載

這里主要針對聊天消息列表，對于大量消息的會話處理，只渲染可視區(qū)域的消息降低瀏覽器的負(fù)擔(dān)，提升響應(yīng)速度。列表優(yōu)化的方案有很多。如下：

方案1：使用定時(shí)器setTimeout來實(shí)現(xiàn)分批渲染，這種方式我們一般不推薦，因?yàn)樵趕etTimeout中對DOM進(jìn)行操作，必須要等到屏幕下次繪制時(shí)才能更新到屏幕上，如果兩者步調(diào)不一致，就可能導(dǎo)致中間某一幀的操作被跨越過去，而直接更新下一幀的元素，從而導(dǎo)致丟幀現(xiàn)象。

方案2：采用requestAnimationFrame，相比之下，requestAnimationFrame的優(yōu)勢還是非常明顯的，主要體現(xiàn)在以下幾個(gè)方面：

• requestAnimationFrame會把每一幀中的所有DOM操作集中起來，再一次重繪或回流中就完成，并且重繪或回流的時(shí)間間隔緊緊跟隨瀏覽器的刷新頻率。
• 在隱藏或不可見的元素中，requestAnimationFrame將不會進(jìn)行重繪或回流，這當(dāng)然就意味著更少的CPU、GPU和內(nèi)存使用量。
• requestAnimationFrame是由瀏覽器專門為動畫提供的API，在運(yùn)行時(shí)瀏覽器會自動優(yōu)化方法的調(diào)用，并且如果頁面不是激活狀態(tài)下的話，動畫會自動暫停，有效節(jié)省了CPU開銷。
• 與setTimeout相比，requestAnimationFrame最大的優(yōu)勢是由系統(tǒng)來決定回調(diào)函數(shù)的執(zhí)行時(shí)機(jī)。
• requestAnimationFrame的步伐跟著系統(tǒng)的刷新步伐走。它能保證回調(diào)函數(shù)在屏幕每一次的刷新間隔中只被執(zhí)行一次，這樣就不會引起丟幀現(xiàn)象。

方案3：采用IntersectionObserver，IntersectionObserver接口(從屬于Intersection Observer API)為開發(fā)者提供了一種可以異步監(jiān)聽目標(biāo)元素與其祖先或視窗(viewport)交叉狀態(tài)的手段。祖先元素與視窗(viewport)被稱為根(root)。

圖片

可以看到，交叉了就是說明當(dāng)前元素在視窗里，當(dāng)前就是可見的了。是代替監(jiān)聽滾動加載的不錯(cuò)方案。

當(dāng)然還有其他方案，還是要根據(jù)實(shí)際的業(yè)務(wù)場景選擇合適的方案，IM消息分段加載的難點(diǎn)在于消息的不定高(多種不同類型的消息)，計(jì)算成本還是有一些昂貴的。所以優(yōu)化還是要驗(yàn)證一下臨界值的，有時(shí)候優(yōu)化不一定會有效。

2.3 消息遍歷

上面我們講到消息排序、去重以及消息狀態(tài)更新等等，多個(gè)會話大量的聊天消息，如果處理不當(dāng)，卡頓是必現(xiàn)的，可以先看一下我們優(yōu)化之前的處理流程，采用的是第三方的SDK，一堆for循環(huán)，消息量大一些基本卡住沒反應(yīng)了。

圖片

那我們是如何處理這個(gè)問題的呢？基于現(xiàn)有的業(yè)務(wù)場景重寫三方SDK，將會話維護(hù)成獨(dú)立的實(shí)例，核心算法就是采用二分法。感興趣的同學(xué)可以看之前的這篇文章 得物客服IM消息通信SDK自研之路，講述得比較詳細(xì)。重寫了IM SDK之后，客服再也沒有反饋過聊天相關(guān)的卡頓，聊天首響提升了20%，成果還是比較顯著的。

消息安全方面的考慮

在IM系統(tǒng)中，消息的安全性是非常重要，開發(fā)同學(xué)需要具備較強(qiáng)的安全意識，將安全融入到開發(fā)流程中，增強(qiáng)系統(tǒng)的安全性和健壯性。消息安全性方面的事情我們做了很多，這里也不再詳細(xì)講解了。

消息發(fā)送和接收的延遲

消息發(fā)送和接收的延遲直接影響用戶的使用體驗(yàn)和溝通效率，在上面我們已經(jīng)分析過一條消息的旅程，出現(xiàn)延遲的原因也比較好分析，主要有以下4點(diǎn)：

• 網(wǎng)絡(luò)延遲：IM消息的發(fā)送和接收是以長鏈接的方式進(jìn)行網(wǎng)絡(luò)傳輸?shù)?，而網(wǎng)絡(luò)傳輸過程中會產(chǎn)生一定的延遲。如果網(wǎng)絡(luò)延遲高，就會導(dǎo)致消息發(fā)送和接收較慢。
• 系統(tǒng)負(fù)載：客服在一對多的情況下，多個(gè)用戶同時(shí)在線，系統(tǒng)需要處理大量的消息和請求，導(dǎo)致系統(tǒng)響應(yīng)速度較慢，這會對客服的體驗(yàn)造成影響。
• 前端延遲：需要經(jīng)過本地消息隊(duì)列、緩存等處理，可能導(dǎo)致消息的延遲。
• 消息編碼和解碼：部分消息需要對數(shù)據(jù)進(jìn)行編碼和解碼，也會消耗一定的時(shí)間，從而導(dǎo)致延遲。

既然能分析出原因，我們就能對癥下藥，可以通過一些優(yōu)化策略來降低發(fā)送和接收的延遲，目前規(guī)劃從以下2個(gè)方面來進(jìn)行優(yōu)化：

• 前端方面：延遲主要在消息的處理和編解碼方面，目前我們IM消息的數(shù)據(jù)格式是JSON，存在序列化和反序列化的過程，這里我們會采用ProtoBuf 替換JSON，目前已完成了相關(guān)技術(shù)調(diào)研和測試驗(yàn)證。我們簡單來看一下ProtoBuf(Protocol Buffers) 和 JSON 處理耗時(shí)的對比：

編碼時(shí)間：ProtoBuf 的編碼時(shí)間比 JSON 快得多，因?yàn)?ProtoBuf 的編碼是二進(jìn)制的，不需要進(jìn)行編碼轉(zhuǎn)換以及無需進(jìn)行冗余類型的轉(zhuǎn)換。相對而言，JSON 的編碼時(shí)間較慢。

解碼時(shí)間：相比編碼，ProtoBuf 的解碼效率要稍微低一些。但是，由于 ProtoBuf 的優(yōu)勢在數(shù)據(jù)量大、結(jié)構(gòu)復(fù)雜的情況下更為明顯，對于小型數(shù)據(jù)解碼時(shí)，兩者的效率差異可能不太明顯。

• 網(wǎng)絡(luò)延遲：網(wǎng)絡(luò)延遲我們很難控制，但是可以通過降低消息傳輸體積進(jìn)行相關(guān)優(yōu)化，剛講了Protobuf 替換JSON，Protobuf是二進(jìn)制格式，比JSON格式更加緊湊，能夠使數(shù)據(jù)包大小大幅度減小，在網(wǎng)絡(luò)傳輸中能夠減少帶寬占用和流量費(fèi)用。在IM系統(tǒng)中，由于用戶數(shù)量龐大，消息發(fā)送頻繁，在數(shù)據(jù)占用和網(wǎng)絡(luò)帶寬方面是一個(gè)巨大的問題，使用ProtoBuf能夠顯著地減少網(wǎng)絡(luò)帶寬消耗，提高系統(tǒng)的性能。還有一方面就是消息壓縮，但是壓縮的深度和壓縮算法需要慎重選擇、驗(yàn)證。

所以使用ProtoBuf格式代替JSON格式基本可以解掉一大半延遲問題，也是接下來IM優(yōu)化的一個(gè)方向。

坐席體驗(yàn)和交互的考慮

體驗(yàn)不是一蹴而就的，不要想著一下子就做到位，一個(gè)優(yōu)秀的用戶體驗(yàn)和交互設(shè)計(jì)需要始終與用戶需求和反饋相結(jié)合，并不斷改進(jìn)和完善。在實(shí)際設(shè)計(jì)和開發(fā)過程中，需要進(jìn)行不斷的測試和優(yōu)化，以確保系統(tǒng)的質(zhì)量和可接受性。同時(shí)，需要與用戶進(jìn)行積極的溝通和反饋，以便更好地理解用戶需求和意見，這一點(diǎn)我們之前是做的不夠好的，尤其是新版本的推廣，系統(tǒng)的易用性并未達(dá)到客服的期望，也是我們后期需要持續(xù)改進(jìn)的一個(gè)方面。

體驗(yàn)是以絕大數(shù)用戶需求為核心的，不能僅僅為了一小部分用戶而去犧牲其他用戶的使用體驗(yàn)，尤其不能因?yàn)槟骋粋€(gè)用戶的反饋意見而做出過多的改變或者犧牲其他用戶的利益。體驗(yàn)優(yōu)化過程的不妥協(xié)也是非常重要的策略，在體驗(yàn)優(yōu)化過程中，必須保持理性和客觀，根據(jù)用戶調(diào)研和數(shù)據(jù)分析進(jìn)行合理的權(quán)衡和決策，以實(shí)現(xiàn)最佳的用戶體驗(yàn)。

一些小細(xì)節(jié)的優(yōu)化也可以起到事半功倍的效果，在IM系統(tǒng)中，一些細(xì)節(jié)的優(yōu)化包括：及時(shí)的消息提示、清晰的消息展示、精確的消息發(fā)送時(shí)間等等。這些小細(xì)節(jié)的優(yōu)化可以直接提高客服的使用效率和體驗(yàn)，從而提高客服滿意度。IM的體驗(yàn)優(yōu)化我們會一直做下去，有志者事竟成。

五、后續(xù)規(guī)劃

• 體驗(yàn)優(yōu)化：體驗(yàn)是我們一如既往要做的事情，會持續(xù)挖掘視覺、交互等層面的優(yōu)化點(diǎn)，從細(xì)節(jié)入手，比如：顏色搭配，按鍵選擇等，提供良好的坐席體驗(yàn)。
• ProtoBuf 替換JSON：降低消息編碼時(shí)間、提升解碼效率、減少數(shù)據(jù)包體積、減少網(wǎng)絡(luò)帶寬消耗，提高系統(tǒng)的性能。
• 消息壓縮：尤其是針對歷史消息、批量消息，使用壓縮技術(shù)，可以有效的減少數(shù)據(jù)包的體積。
• 功能擴(kuò)展：持續(xù)完善機(jī)器人消息類型，尤其是針對售前導(dǎo)購、坐席輔助。逐步支持消息引用、標(biāo)記等功能。
• 多語言能力支持：雖然目前還沒有接入國際化業(yè)務(wù)，但在設(shè)計(jì)層面還是要具備快速擴(kuò)展的能力。

上述幾個(gè)方面我們會優(yōu)先去做重要且緊急的技術(shù)改造，并不會一味的創(chuàng)新、優(yōu)化，還是會以業(yè)務(wù)為主，緊緊圍繞業(yè)務(wù)和坐席體驗(yàn)展開。

六、總結(jié)

客服發(fā)送一條消息在IM應(yīng)用中看似簡單，背后需要考慮的技術(shù)細(xì)節(jié)點(diǎn)是很多的。首先，這需要考慮到消息的發(fā)送機(jī)制和可靠性。即使是一條簡單的消息，也需要經(jīng)過一系列的加密、編碼、傳輸、安全合規(guī)等等處理才能被成功接收。

最重要的是要考慮到數(shù)據(jù)實(shí)時(shí)性的問題，各種極限場景下的操作，客服發(fā)送的消息需要被及時(shí)展示到聊天頁并傳輸給用戶，客服同學(xué)在一對多的場景下工作，需要確保各會話消息不會出現(xiàn)不一致(丟失、重復(fù))，還有消息攔截和異常情況等問題。

因此，客服發(fā)送一條消息不僅需要技術(shù)能力和數(shù)據(jù)處理能力，還需要思考坐席體驗(yàn)和數(shù)據(jù)實(shí)時(shí)性等方面的問題。開發(fā)過程中需要細(xì)致入微地處理各種問題并持續(xù)優(yōu)化，從而為客服提供一個(gè)穩(wěn)定、流暢、安全、友好的IM應(yīng)用。

參考文章：

得物客服IM消息通信SDK自研之路