外呼平臺(tái)是一個(gè)與通話相關(guān)的多功能管理平臺(tái)，將通信資源與相關(guān)應(yīng)用技術(shù)的管理能力平臺(tái)化，高效利用通信資源，外呼能力賦能產(chǎn)品服務(wù)創(chuàng)新和客戶響應(yīng)能力，同時(shí)無縫對(duì)接業(yè)務(wù)、數(shù)據(jù)、AI等其他能力。外呼平臺(tái)集成了資源隔離和資源分配，機(jī)器人和IVR會(huì)話管理，坐席管理等多種應(yīng)用能力。完成資源的高效利用和運(yùn)營的高效管理，做到配置化，可視化，分鐘級(jí)別告警。下面主要圍繞外平臺(tái)，建設(shè)過程中遇到哪些問題，又是怎么解決展開的。

一、外呼平臺(tái)建設(shè)

外呼給人的第一印象就是打電話，但是加上了平臺(tái)，就會(huì)變成怎么高效撥打電話，高效運(yùn)營管理和新的賦能，圖1是外呼平臺(tái)的網(wǎng)絡(luò)拓?fù)鋱D。

外呼平臺(tái)網(wǎng)絡(luò)拓?fù)鋱D

外呼平臺(tái)是以開源的呼叫中心服務(wù)器作為中心節(jié)點(diǎn)，圖中左邊是運(yùn)營商網(wǎng)絡(luò)，通常指三大運(yùn)營商以及其代理運(yùn)營商，統(tǒng)稱為線路資源；右側(cè)是坐席部分，可以支持sip話機(jī)，軟電話和web話機(jī)；外呼平臺(tái)通過與呼叫中心服務(wù)器交互，來控制通話的建立，掛斷，重?fù)埽シ胖付ㄕZ音等功能。外呼平臺(tái)的建設(shè)涉遇到了多個(gè)技術(shù)選型和問題，下面會(huì)逐一說明怎么做的技術(shù)選型和問題解決。

1.1 技術(shù)選型

1，呼叫中心服務(wù)器選型

從圖1的外呼中心網(wǎng)絡(luò)拓?fù)鋱D中可以看出，外呼中心服務(wù)器的選擇將直接決定整個(gè)系統(tǒng)的架構(gòu)，目前常見的開源服務(wù)器有Asterisk和FreeSwitch（后續(xù)簡稱FS）。Asterisk起步較早，單機(jī)性能已經(jīng)有些落后；FS起步晚，所以更加貼近當(dāng)前的技術(shù)需求，具備跨平臺(tái)，伸縮性強(qiáng)，也支持多協(xié)議，而且社區(qū)活躍，遇到問題可以通過社區(qū)尋求幫助，可查閱的資料也更多，經(jīng)過調(diào)研也發(fā)現(xiàn)，很多廠商的呼叫中心都是采用的FS。其他廠商經(jīng)過實(shí)踐結(jié)果表明，F(xiàn)S具備更高的性能；由于資料更加完備，學(xué)習(xí)成本也會(huì)更加低，最主要的是，已有的較多成功落地的案例，所以選擇FS。

2，開發(fā)模式選型

FS的開發(fā)模式有兩種：一種是面向服務(wù)器開發(fā)，這種開發(fā)模式是基于腳本內(nèi)嵌的方式，主要開發(fā)lua腳本，開發(fā)人員的學(xué)習(xí)成本高，不易維護(hù)，且無法控制會(huì)話流程，腳本之間無法復(fù)用；另外一種是面向客戶端開發(fā)，如下圖所示，F(xiàn)S有java客戶端，開發(fā)人員可以使用自己熟悉的開發(fā)語言(java)，通過客戶端轉(zhuǎn)換后，控制整個(gè)會(huì)話流程，方便定制，易擴(kuò)展，學(xué)習(xí)成本也低。雖然lua腳本執(zhí)行效率更高，但是客戶端更加方便定制化開發(fā)，易于開發(fā)，最終選擇面向java客戶端來控制FS。

面向客戶端開發(fā)示意圖

1.2 集群建設(shè)

通話經(jīng)過的各個(gè)節(jié)點(diǎn)示意圖

如圖3所示，一通電話的建立，需要經(jīng)過的節(jié)點(diǎn)包含F(xiàn)S服務(wù)器，網(wǎng)關(guān)，運(yùn)營商三個(gè)關(guān)鍵節(jié)點(diǎn)，任務(wù)一個(gè)節(jié)點(diǎn)出現(xiàn)問題，都會(huì)導(dǎo)致通話失敗。

使用FS作為呼叫中心服務(wù)器，單臺(tái)服務(wù)器的承載能力只能同時(shí)支持1000-1500通會(huì)話，外呼平臺(tái)在建設(shè)初期采用VIP實(shí)現(xiàn)雙機(jī)熱備，保證外呼過程的高可用。隨著業(yè)務(wù)發(fā)展，單臺(tái)FS服務(wù)器已經(jīng)無法滿足業(yè)務(wù)需要，F(xiàn)S服務(wù)器需要從雙機(jī)熱備架構(gòu)轉(zhuǎn)換到集群架構(gòu)。

1.2.1 事件處理瓶頸

從雙機(jī)熱備切換到集群架構(gòu)有個(gè)阻塞點(diǎn)：java應(yīng)用單機(jī)處理事件的能力有限，如果不解決這個(gè)問題，集群的規(guī)模將會(huì)受到限制。如圖4所示，每一臺(tái)java后臺(tái)應(yīng)用服務(wù)器，與每一臺(tái)FS服務(wù)器建立socket連接，如圖中紅色箭頭所示。java后臺(tái)應(yīng)用，用事件通信的方式來控制FS，這其中存在一個(gè)弊端在于，F(xiàn)reeSwitch每次以廣播的方式發(fā)送響應(yīng)事件信息，每臺(tái)java后臺(tái)應(yīng)用需要處理所有FS發(fā)送的事件，包含自己需要處理和不需要自己處理的事件，用n表述java后臺(tái)應(yīng)用服務(wù)器的數(shù)量，那么一臺(tái)java后臺(tái)服務(wù)期望處理的數(shù)量是1，但實(shí)際處理的事件數(shù)量就是n，因?yàn)槠渌鹡-1臺(tái)服務(wù)器發(fā)送的事件，在廣播機(jī)制，會(huì)收到其他n-1臺(tái)應(yīng)用服務(wù)器的響應(yīng)事件。這樣的話，整個(gè)外呼的上線就是單臺(tái)java應(yīng)用服務(wù)器的單機(jī)處理上線。

java應(yīng)用控制FreeSwitch示意圖

由于FS支持發(fā)送RabbitMQ，業(yè)內(nèi)很多的做法是在FS和java后臺(tái)應(yīng)用服務(wù)器之間加一層RabbitMQ，然后集中做事件分發(fā)，這種方式會(huì)導(dǎo)致架構(gòu)更加復(fù)雜，而且事件轉(zhuǎn)發(fā)層也會(huì)逐漸成為瓶頸。并且當(dāng)前公司支持的是RocketMQ，如果新搭建一套R(shí)abbitMQ，不僅增加了架構(gòu)復(fù)雜性，運(yùn)維成本也會(huì)增加。這種方案只能成為兜底方案。

問題的關(guān)鍵點(diǎn)在于處理了其他n-1臺(tái)的的事件，如果能夠過濾掉非本機(jī)應(yīng)用發(fā)送請(qǐng)求的響應(yīng)事件，那么問題就完美解決。經(jīng)過各方面的咨詢和調(diào)研，業(yè)內(nèi)幾乎沒有碰到這類問題，主要原因在于量級(jí)問題，一般遇到這種量變導(dǎo)致的架構(gòu)瓶頸問題，要么放棄使用面向客戶端的開發(fā)方式，改為使用lua腳本執(zhí)行所有的會(huì)話流程，這樣就不需要java后臺(tái)應(yīng)用控制會(huì)話流程；要么使用RabbitMQ作為中間層轉(zhuǎn)發(fā)。這兩條路都不想選擇的情況下，就轉(zhuǎn)到socket連接上做文章，如果在socket接受端能夠過濾掉非本機(jī)事件，那么也能解決這個(gè)問題。通過在事件頭部添加本機(jī)ip信息，依次作為socket過濾事件的依據(jù)，最終得以解決這個(gè)問題，如圖5所示。需要指出的是，雖然最終還是每臺(tái)java后臺(tái)服務(wù)器接受了所有事件，但是過濾動(dòng)作從java應(yīng)用內(nèi)部過濾提前至socket接收端過濾，而socket過濾效率又是極高的，socket本身不會(huì)成為瓶頸。

socket執(zhí)行ip過濾示意圖

1.2.2 任務(wù)執(zhí)行要求

外呼平臺(tái)的主要功能之一是系統(tǒng)自動(dòng)外呼，其主要工作流程為：不同的業(yè)務(wù)使用方，批量提交大量任務(wù)到外呼平臺(tái)，形成一個(gè)任務(wù)池，外呼平臺(tái)從任務(wù)池中獲取外呼任務(wù)，發(fā)起外呼。整個(gè)過程，面臨這三個(gè)難點(diǎn)。

1，速度控制：（1）業(yè)務(wù)方提交任務(wù)的速度遠(yuǎn)遠(yuǎn)大于系統(tǒng)處理的速度，外呼平臺(tái)需要根據(jù)自己的能力，自適應(yīng)的控制處理速度；（2）caps（每秒建立通話數(shù)）控制：呼叫中心服務(wù)和網(wǎng)關(guān)的caps值過大，會(huì)造成通話卡頓和延遲；線路商caps值過大，通話請(qǐng)求被拒絕；（3）已經(jīng)建立會(huì)話量控制：如果系統(tǒng)維持的通話量過大，會(huì)造成通話卡頓和延遲，甚至服務(wù)器宕機(jī)。

2，過載保護(hù)控制：FS服務(wù)器本身不具備過載自我保護(hù)能力，當(dāng)處理的會(huì)話過多，會(huì)造成通話不順暢甚至服務(wù)器宕機(jī)。所以必須控制每臺(tái)服務(wù)器處理外呼的數(shù)量，保證服務(wù)器運(yùn)行在一個(gè)合理的負(fù)載范圍內(nèi)。

3，高觸達(dá)率和不可重試的業(yè)務(wù)矛盾：外呼一個(gè)重要指標(biāo)是客戶正常觸達(dá)率，由于外呼過程中經(jīng)過了多個(gè)節(jié)點(diǎn)，導(dǎo)致外呼故障的原因多種多樣，一種典型的例子：外呼請(qǐng)求已經(jīng)發(fā)出，然后服務(wù)器故障，此時(shí)用戶已經(jīng)收到電話，但是無法正常的建立通信，所以外呼不能像調(diào)用接口一樣，多次重試，這樣會(huì)造成用戶投訴，所以需要判斷通話無法建立是存在故障還是正常，發(fā)生故障時(shí)，立即故障轉(zhuǎn)移。目前常見的故障有兩種：（1）線路商提供的線路故障；（2）外呼中心服務(wù)器故障。

1.2.3 集群建設(shè)

外呼平臺(tái)采用任務(wù)調(diào)度和心跳檢測來完成符合實(shí)際需要的集群。

1，秒級(jí)任務(wù)調(diào)度和任務(wù)執(zhí)行隔離：調(diào)度執(zhí)行分離達(dá)到各種資源負(fù)載均衡，控制caps值和通話量；計(jì)數(shù)資源使用情況，實(shí)現(xiàn)過載保護(hù)

2，線路管理控制：實(shí)現(xiàn)外呼資源（服務(wù)器，線路等）在業(yè)務(wù)間即可獨(dú)立，也可共享，通過界面化完成配置；通過實(shí)時(shí)計(jì)算接通率，判斷當(dāng)前線路是否存在故障，及時(shí)剔除。

3，狀態(tài)檢測：定時(shí)檢測java后臺(tái)應(yīng)用和FS的連接狀態(tài)以及FS自身狀態(tài)，及時(shí)剔除不可用的后臺(tái)應(yīng)用和FS服務(wù)器。

經(jīng)過上面的建設(shè)后，外呼平臺(tái)的整個(gè)任務(wù)提交和執(zhí)行如圖6所示。

任務(wù)調(diào)度執(zhí)行示意圖

業(yè)務(wù)提交的外呼任務(wù)會(huì)進(jìn)入到與業(yè)務(wù)相關(guān)的不同待執(zhí)行隊(duì)列中，這里采用redis列表數(shù)據(jù)結(jié)構(gòu)作為任務(wù)隊(duì)列，任務(wù)左進(jìn)右出。需要說明的是，這個(gè)地方不需要包裝DB數(shù)據(jù)和緩存數(shù)據(jù)的一致性，任務(wù)在出隊(duì)執(zhí)行后，會(huì)校驗(yàn)任務(wù)狀態(tài)并采用樂觀鎖修改任務(wù)狀態(tài)，操作成功后才會(huì)執(zhí)行任務(wù)，否則只會(huì)做出隊(duì)操作，不執(zhí)行。

scheduler層（調(diào)度層）每一秒執(zhí)行一次調(diào)度：scheduler層對(duì)效率要求比較高，采用線程池并行執(zhí)行不同的任務(wù)隊(duì)列，在任務(wù)調(diào)度過程中，需要io的地方只有訪問redis，提交任務(wù)到worker采用異步rpc接口調(diào)用的方式。具體過程如下：

1，獲取隊(duì)列id列表，一個(gè)隊(duì)列從線程池中獲取一個(gè)線程去執(zhí)行自己的任務(wù)；

2，根據(jù)隊(duì)列id獲取自己可以使用的資源列表，并判斷資源是否充足，資源的負(fù)載均衡和過載保護(hù)就是在這里實(shí)現(xiàn)的，對(duì)于FS的選擇，網(wǎng)關(guān)的選擇，線路的選擇，內(nèi)置了三種算法，分別是隨機(jī)，輪詢和接通率優(yōu)先，接通率優(yōu)先算法的主要思路是在worker層任務(wù)執(zhí)行完畢后，主動(dòng)上報(bào)數(shù)據(jù)，然后按照分鐘粒度去統(tǒng)計(jì)各個(gè)維度的接通率，然后在選擇的時(shí)候，可以選擇接通率更高的資源，該算法主要適用于線路資源的選擇；過載保護(hù)主要體現(xiàn)在，任務(wù)在執(zhí)行過程中，會(huì)把已經(jīng)占用的資源放到執(zhí)行中隊(duì)列中，如果該項(xiàng)資源超過使用上限，則不會(huì)繼續(xù)使用該資源；

3，任務(wù)完成調(diào)度后，任務(wù)執(zhí)行需要的所有資源信息已經(jīng)確認(rèn)完畢，把這些信息提交到下層的worker執(zhí)行，從scheduler到worker層采用rpc的方式，借用dubbo的接口調(diào)用完成了java后臺(tái)應(yīng)用的負(fù)載均衡。

需要額外指出的是：待執(zhí)行隊(duì)列中的任務(wù)一般會(huì)遠(yuǎn)遠(yuǎn)大于系統(tǒng)的執(zhí)行能力，每個(gè)隊(duì)列中的任務(wù)在1秒內(nèi)是不可能全部提交完畢的，為了保證任務(wù)調(diào)度是嚴(yán)格按照秒級(jí)調(diào)度，每個(gè)線程執(zhí)行任務(wù)提交的時(shí)間必須小于1秒，不然線程池中的線程使用完畢后會(huì)造成任務(wù)堆積現(xiàn)象，也就是當(dāng)停止任務(wù)調(diào)度后，會(huì)發(fā)現(xiàn)scheduler層還要運(yùn)行一段時(shí)間，才會(huì)真正停止。最簡單的方案是采用線程池的拒絕策略，但是這種會(huì)造成獲取線程的隊(duì)列可以提交任務(wù)并且短期內(nèi)不釋放線程，未獲取到線程的隊(duì)列則一直要等待，造成任務(wù)執(zhí)行不均勻；最終采用的方案每個(gè)線程最多執(zhí)行900ms，超過時(shí)間后必須釋放，由此來保證每個(gè)隊(duì)列都能公平的獲得任務(wù)提交的機(jī)會(huì)。

worker層（執(zhí)行層）：每一個(gè)worker在啟動(dòng)的時(shí)候會(huì)與所有的FS建立socket連接，并把連接緩存到本地，然后每間隔固定時(shí)間(10s)，檢測socket通道是否斷開連接，如果當(dāng)前檢測socket斷開，則本機(jī)會(huì)拒絕執(zhí)行任務(wù)，會(huì)把scheduler提交的任務(wù)重新放回待執(zhí)行隊(duì)列，同時(shí)會(huì)發(fā)起一次全局投票，判斷當(dāng)前FS是否正常，如果大多數(shù)worker都不能與這臺(tái)FS建立連接，則把這臺(tái)FS從可用列表中剔除，這樣在scheduler層提交任務(wù)時(shí)就不會(huì)使用這臺(tái)FS。然后等待下一次心跳檢測，如果大多數(shù)可以重新建立連接，則會(huì)重新把FS加入到可用列表中。整個(gè)過程如圖7所示

心跳檢測示意圖

二、總結(jié)

以上主要介紹了后臺(tái)技術(shù)的構(gòu)建，外呼平臺(tái)圍繞這外呼功能，后臺(tái)還引入了opensips+rtpengine架構(gòu)；在使用方面，引入了web話機(jī)，去掉了話機(jī)的概念，節(jié)約了話機(jī)成本，機(jī)器人和ivr的配置都使用界面配置化，可以方便業(yè)務(wù)的快速迭代；運(yùn)維管理可視化，可以及時(shí)感知整個(gè)外呼平臺(tái)的運(yùn)行現(xiàn)狀。所有的工作都圍繞三個(gè)關(guān)鍵詞：大體量，高效率，易運(yùn)營。有關(guān)系統(tǒng)方面問題請(qǐng)找博主，看他名字可以微他一起技術(shù)交流學(xué)習(xí)

外呼平臺(tái)在建設(shè)，是一個(gè)從零到一的故事，并且建設(shè)過程中會(huì)面臨各種陌生領(lǐng)域(通信)的知識(shí)，同時(shí)由于公司業(yè)務(wù)量大，架構(gòu)升級(jí)的過程中，也沒有類似的參考案例，在架構(gòu)升級(jí)過程中，各種選擇的主要方向在于簡單，高效，學(xué)習(xí)成本低。文章來源地址http://www.zghlxwxcb.cn/news/detail-404498.html

到了這里，關(guān)于怎樣才能高效的撥打電話—，人工智能系統(tǒng)，呼叫中心，外呼系統(tǒng)建設(shè)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！