線上客服技術

線上客服技術是一個比較流行的功能，網路上有很多提供線上客服服務的公司。

前言線上客服是一個比較流行的功能，網路上有很多提供線上客服服務的公司，但介紹線上客服技術的文章卻很少。另外，網上有一些免費的線上客服框架，但大部分都只適用與小規模的線上客服服務，對於大規模套用（幾萬人甚至幾十萬人同時線上），卻基本沒有。本文將根據自己的一些實際經驗，講解線上客服的各項技術。
這裡講的線上客服系統是基於Web環境，採用Java、JavaScript來實現的。
aJax技術講線上客服技術，就不得不講到aJax技術，AJAX全稱為“Asynchronous JavaScript and XML”（異步JavaScript和XML），是指一種創建互動式網頁套用的網頁開發技術。有了這種技術，就可以實現網頁部分數據的更新，而不像傳統Web技術那樣，需要刷新整個頁面。
目前有很多aJax框架，如DWR，Dojo，ProtoType，BackBase等，不同的aJax框架，實現的功能不同，用處也不同，在開發項目的時候，需要根據自己的需要選擇不同的框架。我比較推崇採用DWR，因為這個框架的實現比較優美，使用也比較簡單，而且能夠把Java和JavaScript統一起來。
DHTML（動態HTML）DHTML（動態HTML）提供了在瀏覽器中維護內容、進行用戶互動的擴展能力。就像Java開發者使用servlet和JSP那樣，DHTML也應該是你的工具箱中的一部分。
DHTML涉及到HTML、級聯樣式表（CSS）、JavaScript和DOM。傳統的頁面只能通過重新裝載來自server新頁面的方式進行更新。DHTML提供了在頁面被裝載完畢後對瀏覽器內的HTML文檔的完全控制。你應該見過一些帶有“圖像翻滾”、彈出內容、可收縮選單功能的web頁面，它們便是使用DHTML技術實現的。儘管存在一些標準上的差異（見下面的“跨瀏覽器DHTML”），多數兼容JavaScript1.4版本的瀏覽器（後面將簡稱為“版本4的瀏覽器”）都支持DHTML。
從開發者的角度審視瀏覽器中的整個文檔，比如Frame、圖片、表格等，它們都可以表示為具有層次的對象模式——DOM。通過使用JavaScript可以維護DOM的成員，不但可以改變文檔的內容和外觀，而且還可以捕捉例如滑鼠移動、form提交這些用戶事件，而後對DOM進行相應修改。例如滑鼠移動到圖片的上方可以產生“mouse-over”事件，這時通過顯示高亮版本的圖片或者彈出解釋性文字的方式修改頁面外觀。
通知解決方案線上客服系統最重要的就是通知，用戶傳送的訊息如何通知到客服，客服傳送的訊息又如果通知到用戶，下面將講解其中一些常用的通知解決方案。
1、 輪詢
這是一種比較古老而簡單的解決方案，也就是定時刷新，線上客服在聊天的時候，aJax在後台定時獲取數據，如果接收到傳送過來的訊息的話，則將訊息顯示在聊天框上。
這種技術的缺點就是後台刷新太頻繁了，而很多刷新都是沒有數據返回了，導致性能的下降。
2、 長連線
這種技術有稱為“長輪詢”，它是基於輪詢技術的，但有所改進，客戶端向服務端發起請求的時候，服務端不會直接返回，而是會阻塞請求，直到伺服器讀取到訊息後才返回，這個時候，客戶端才調用回調函式，將讀取到的訊息顯示出來。
這裡講的線上客服系統將選用該技術來實現。
圖 2. 基於長輪詢的伺服器推模型
訊息
這種解決方案採用一個作為client的applet，它使用TCP/IP或者無連線的UDP、甚至多播協定來建立與訊息中間鍵server的通訊，然後由server推送訊息給client。你可以從例如SoftWired的ibus、IBM的MQSeries、BEA的WebLogic Event這些訊息產品中直接挑選，或者自己使用基於socket的定製開發訊息軟體。
Comet技術Commet是一種使用HTTP長連線，無需瀏覽器安裝外掛程式的“伺服器推”方案。它有兩者方案：基於aJax的長輪詢方式；基於iframe和htmlfile的流方式。這裡，我們只關註裡面的基於aJax的長輪詢方式。
pushlet是一個開源的Comet框架，其中在設計上有很多值得借鑑的地方，能夠使用它來開發一個不是大規模的線上客服系統。而對於大型商用的線上客服系統，我覺得它還無法勝任。
負載均衡（分散式部署）一個正式商用的線上客服系統，不可能只在一個WEB伺服器部署，這樣子，性能和容量都很難擴展，所以必然是允許分散式部署的，通過負載均衡設備（或軟體）來實現分散式訪問。
如果採用分散式部署的話，那么就涉及到聊天的數據保存在哪裡的問題。是保存在web伺服器上，還是資料庫呢？如果是單web伺服器的話，那肯定是保存在web伺服器上，其流程大概如下：
1、 用戶傳送訊息是，系統將數據保存在web伺服器（同時也保存資料庫）上。
2、 客服對應的長連線獲取web伺服器上的數據，然後在客服的頁面上顯示出來。
3、 客服回復聊天信息，系統將數據保存到web伺服器（同時也保存資料庫）上。
4、 用戶所在的長連線獲取web伺服器上的數據，然後在用戶的頁面上顯示處理。
由於從web伺服器上獲取數據比在資料庫獲取數據的效率高，所以上面的邏輯是合理的，但是，基於分散式部署的環境下，他存在多個web伺服器，那么發起聊天的訊息應該保存在哪台伺服器上呢？還是所有的伺服器都保存一次呢？在分散式環境下存在一些像JBossCache等快取同步的技術，但對應線上聊天系統，實時性的要求非常高，是否存在實時性的問題呢？
另外一個，基於安全的考慮，一般需要將用戶所訪問的功能放到一個web伺服器集群上，客服所訪問的功能放到另外一個web伺服器集群上，兩個web伺服器集群的網路需要隔離，以防止黑客的攻擊。這就又出現一個問題，如果用戶傳送的訊息放到用戶的web伺服器上，那么客服如果獲取到該訊息呢？同理，用戶的web伺服器有如果獲取客服web伺服器對應的訊息呢？
那么放到資料庫來實現呢？把聊天記錄都放到資料庫中，用戶和客服都從資料庫獲取聊天的信息。這樣子的話，那么資料庫的負荷將非常大，隨著用戶數的不斷增加，資料庫負荷越來越大，而且，在大用戶下，存儲都是非常頻繁的，將所有人的聊天信息放到資料庫上，是不明智的。還有一個安全上的考慮，一般實現用戶的功能都不直接訪問資料庫，一般會經過一個中間的伺服器作為中轉，那么如果聊天信息從資料庫取的話，效率則會更低。
那么，能不能像QQ那樣，聊天雙方直接建立連線，實時傳送呢？其實，這是一種相對老點的技術，一般是採用Socket，或者UDP，實現雙方的通訊。這種機制的缺點客戶端可能需要採用applet外掛程式或ActiveX外掛程式，通訊時有比較大的性能消耗，最重要的一點，這些技術受網路的影響特別大，在一個環境下可以正常使用，在另外一個環境下，可能就無法正常使用了。所以，本文考慮的是採用aJax長輪詢方式來實現的。
在這裡，我建議客服的聊天數據從資料庫讀取，而用戶的聊天數據從web伺服器上讀取。這是因為客服的數據相對比用戶少很多，直接從資料庫讀取聊天數據，對資料庫的性能影響較少，而用戶的數量龐大，直接從資料庫讀取，無法滿足要求。
那么，客服是將回複數據寫到客服的web伺服器，還是用戶的web伺服器呢？我的建議是寫到用戶的web伺服器，因為用戶的數據量非常龐大，用戶從用戶的web伺服器獲取數據，要比從客服的web伺服器獲取數據，性能要高得多。客服每次傳送聊天信息的時候，往用戶的web伺服器寫數據，雖然效率低，但由於客服的數據量小，並不影響性能。
另外，在分散式部署下，數據該記得所以的web伺服器，還是某台特定的web伺服器呢？我建議寫到某個特定的web伺服器上，這樣避免客服每傳送一條聊天信息，都要往所有的web伺服器寫數據，這會影響性能，但web伺服器不斷增加的時候，性能會隨之下降。
那么，客服往哪台特定的web伺服器寫數據呢？用戶又如何知道從哪台特定的web伺服器上獲取數據呢？這個，我們在用戶登入，負載均衡伺服器給其分配到某個特定的伺服器的時候，就可以將這個特定伺服器的IP記錄下來，客服就可以往這台機器發訊息了，而用戶也同樣可以從該IP獲取數據了。
路由分配
現在來講一個路由分配，這個應該從什麼時候進行路由分配，如何進行路由分配，分配失敗了怎么辦等方面來討論。
1、什麼時候進行路由分配
什麼時候進行路由分配呢？是用戶一登入系統了就給其進行路由分配，還是等待用戶傳送了第一個聊天信息才開始路由分配呢？
這個要分情況討論，像一般的web線上客服系統（或者WAP線上客服系統），用戶都是一登入系統，就給其分配一個客服的。這種，有一個好處，就是登入的時候，已經分配客服了，那么傳送第一條信息的時候，就不需要再路由分配了，可以直接將該信息分配到對應的客服，這樣能提高聊天的效率。而不好的地方就是會占用資源，如果用戶登入後，分配了客服後，用戶又一直不傳送聊天信息，也不退出系統的話，這就占用了一個資源，可能導致客服的處理量減少了。好在正常的邏輯下，用戶登入系統後，都是會馬上傳送聊天信息的，所以這種情況就比較少了。所以一般的web線上客服系統，我建議採用一登入就路由分配的策略。
對於像簡訊線上客服這樣的系統，由於用戶沒有登入系統這樣一步操作，那肯定是用戶傳送第一條聊天信息就開始進行路由分配啦。
是用戶每傳送一條信息就分配一次，還是只路由分配一次，以後傳送訊息都不進行分配呢？
如果用戶每傳送一條信息，都路由分配一次的話，這樣有一個好處，就是可以平均給客服分配話務量，用戶傳送訊息的時候，都可以計算一次，把該訊息分配給當前處理量最小的客服；它的缺點就是影響性能，因為路由分配是需要消耗性能的，每次傳送都會消耗性能，另外一個就是缺乏穩定性，如果前一條訊息傳送給一個客服，下一條訊息又傳送給另外一個，那么，用戶感覺會不舒服，而客服在處理的時候也會不知道前因後果。
只路由分配一次，效率就比較高，但它有個缺點，就是每個用戶聊天的頻率不同，比如說，兩個客服都是同時處理10個用戶，但一個客服對應的用戶比較喜歡聊天，拚命的傳送聊天信息，那么這個客服也會比較忙；而另一個客服對應的用戶很久才傳送一次聊天訊息，那么這個客服就會很閒了。但總的來說，這種情況很少，而且我們可以通過一個路由分配策略來減少和規避這些情況。所以，我建議採用只路由分配一次的情況。
2、如何進行路由分配
現在網上大部分的線上客服系統都是匿名的，它是通過你從哪個網頁點擊登錄，從而分配到對應技能的座席。有些線上客服系統是通過帳戶（如銀行的線上客服系統）或者手機號碼（如電信的線上客服系統）登錄的，它是通過用戶的類型，或者用戶選擇詢問的內容，來路由分配到不同的客服上的。
但不管怎么說，一般都是將客服劃分為不同的技能，一個客服可能擁有一個或者多個技能，用戶登入的時候，屬於一種技能，路由分配的時候根據該路由策略將用戶分配到對應的客服。它一般要求有下面幾個原則：
1、 繼承原則
分配給座席的聊天訊息，需要有一定的繼承性，比如說，用戶聊天完成後，退出系統，隔幾分鐘後，再次登錄系統，這時，最好把該呼叫還是分配給原先處理該用戶的客服，這樣子，用戶的好感度會比另外分配不同的用戶好得多。
2、 分技能服務原則
不同的用戶，根據其技能不同，需要分配到對應技能的客服上，也就是說，客服劃分為多個技能，這樣的好處的節省客服的培訓費用。但它有一個不好的地方，就是用戶問一些跨越該客服技能範圍內的問題，這時客服就無能為力了，它只能詢問其它人，或者將來話轉移給其它客服處理，這就會影響用戶的好感，所以，對於一個高端用戶，可能是需要一個全才性的客服來為他們服務的。
3、 平均分配原則
聊天信息要平均分配，從而保證客服處理的量都是平均的。
4、 最閒分配原則
路由分配的時候，需要將用戶來話分配到最閒的客服上。
5、 不同接通率原則
對於不同基本的用戶，有不同的接通率，比如說，VIP用戶每次來話都接入，而低端用戶，則顯示系統忙。