呼叫中心架構設計

背景

• 客戶在打電話給客服（坐席）時需要保護自己的隱私（客戶電話號碼不能透傳給客服）
• 客服在打電話給客戶時可根據實際對應業務來設定是否進行號碼透傳（大部分場景是透傳）
• 對一些業務提供基礎數據的支撐（通話開始時間、結束時間、錄音等）
• 不建立真正的呼叫中心，而是接入多個第三方提供的云通話服務完成實際通話過程，降低成本和風險

為此我們需要實現一個能夠能夠支撐業務實現并能夠接入多個云通話服務渠道的系統，命名為 CC（Call Center，呼叫中心）。

架構設計

從呼叫模式上看，目前業界大多數采用的是“回撥”模式，即由呼叫中心發起兩路呼叫，然后將兩路進行連通。提供回撥服務的廠商比較多，比如玖云、華為、吉亞等，下面以玖云和華為為例進行架構設計。（選擇玖云和華為主要是因為他們正好使用了不同的兩種通話狀態獲取模式，玖云是回調，而華為是輪詢）

（圖片看不清的話請另存為后查看）

子模塊

• Callback Logging：玖云事件回調持久化，實現上使用 NGINX 寫文件日志
• Scheduled Task：華為事件輪詢
• Dispatch & Handle：處理來自 Callback Logging 和 Scheduled Task 的通話事件
• Unified Call Records：統一格式的通過記錄持久化存儲
• Channel：提供給應用調用，完成“用戶-坐席-渠道”的關聯管理功能
• User-Agent-Channel：“用戶-坐席-渠道”持久化存儲
• Call：提供給應用調用，完成“回撥”功能
• Call Query：提供給應用調用，完成通話數據查詢功能
• Health：渠道及回調日志健康狀態檢查，以及渠道故障時讓 Channel 自動切換渠道
• Aliyun OSS：將獲取到的通話錄音上傳到阿里云 OSS 進行存儲

通話記錄表

回撥流程

1. 應用發起回撥請求，調用 Call
2. Call 調用 Channel，有 Channel 選擇適合的渠道，并通過公網 HTTP(S) 進行回撥請求

3. 由渠道通過 PSTN 實現電話呼叫：
   3.1 呼叫 A 路（客服），A 路摘機
   3.2 呼叫 B 路（客戶），客戶摘機
   3.3 A-B 接通進行通話
   3.4 通話結束（A/B 掛斷或異常）

   • 在此期間需要接收事件回調（玖云）或進行事件輪詢（華為）并持久化通話狀態，最終形成統一格式的通話記錄
   • 回撥接口參數中可以帶上業務實體標識，以便將通話記錄和業務實體進行關聯對應
   • 回撥接口的返回值中會返回一個 callId，用來表示該次回撥，以便將通話記錄和業務實體進行關聯對應
   • 在通話期間，應用可以使用 callId 來輪詢 CC 查看通話狀態

用戶-坐席-渠道

這個模型用于描述業務系統中的用戶實體以及坐席（可以理解為渠道提供的通話線路，同一時刻同一個線路只能有一通電話在撥打）的關聯，并卻定了這個用戶所使用的通話渠道。

• 對于玖云，坐席對應的是電話號碼
• 對于華為，坐席對應的是坐席號

默認情況下并不需要指定關聯，CC 會自動選擇渠道，只有在某些業務場景下需要應用來指定渠道。

呼叫中心系統方面技術交流： 515229

標簽：馬鞍山 安慶 淮南 十堰 宜昌