自動外呼——設計思路整理篇

-Advertisement-

PS：關於自動外呼的功能我在總體結構篇已經大概說過了，類似資料庫設計、以及相關代碼實現都不難，我就不多贅述了。這裡主要介紹當時遇到的幾個經過仔細思考過的設計思路。這幾天整理的時候，發現當時還是缺乏很多的知識，考慮也沒有很全面。這裡僅僅寫出來，供大家思考。排隊機制的處理板卡上的電話通道是有限的（公 ...

PS：關於自動外呼的功能我在總體結構篇已經大概說過了，類似資料庫設計、以及相關代碼實現都不難，我就不多贅述了。這裡主要介紹當時遇到的幾個經過仔細思考過的設計思路。這幾天整理的時候，發現當時還是缺乏很多的知識，考慮也沒有很全面。這裡僅僅寫出來，供大家思考。

排隊機制的處理

板卡上的電話通道是有限的（公司提供的板卡通道當時是40個），因此難免會遇到需要排隊處理的情況。一旦進行排隊，勢必會有優先順序的區分。當時想當然準備做一個獨立的排隊模塊，後來被自己否決了（圖樣圖深破）。一個是因為獨立的話，不能分散式部署，意義不大；還有一個原因是外呼中的優先順序有點特殊，因為即使某個業務需要優先處理，其他正在處理的業務也不能因為它而不給客戶電話（沒有那種絕對優先的場景）。既然沒有絕對意義上的優先排隊需求，當時就換了個思路，將優先排隊和板卡通道的數量聯繫在了一起。為每一個業務分配一個處理隊列（每個業務本身肯定是先後優先的），每個處理隊列，會分配不等的通道個數，這樣就同時保證了任務的重要性分級和排隊處理的需求（動態分配的設置方式有很多選擇，這裡就不多說了）。由於不考慮獨立排隊，以及跟板卡通道有緊密聯繫，因此處理隊列組就放在了底層的呼叫中心服務。

和底層服務端之間通信方式的處理

通信方式使用的是socket。客戶端和服務端分別開啟線程去接收監聽到的消息。客戶端發送請求，服務端接收消息後，非同步處理該請求。處理完成後，服務端將結果發送給客戶端。（類似於非同步回調）公司內部使用服務端通信99%都是基於WCF的，這裡使用socket的原因，其實還是學藝不精T_T~。不過當時我這張破嘴居然把leader給忽悠過去了，想想也是牛逼的醉了^_^。主要當時沒研究過WCF（其實就是懶），不清楚有這種雙向發送消息的模式。其實使用WCF雙工通信中的訂閱發佈模式，就能很好的解決這個需求了。（相關介紹網上很多，有興趣的大家可以自行查閱）

任務執行流的設計

當時開發的時候，老大直接扔了一個某公司比較完善的外呼配置流程文檔，居然可以使用類似圖形控制項的東西進行編輯（還特麽的支持拖拽），一下子覺得長見識了。後面老大要求我們也要這麼靈活才行，瞬間我差點嚇跪了。後面就開始各種幻想，剔除了不切實際的東西，開始考慮流程這東西存儲在電腦中是個什麼樣子，一下子想到了大學時候學過的數據結構——圖（此處應該給我大學的周老師如雷貫耳般的掌聲）。然後想到了有向圖這種有起始點、完結點和有向邊的模型。（可能和標準的有一些差異）主要要求時間有點緊，也沒時間去仔細研究WorkFlow相關的東西，其實就是——懶~~~~ 圖片就不放了，網上一大堆，雖然跟原版的有差異，但大致是一樣的。下麵是當時對於有向圖流轉模型的介紹（直接抄過來了，反正也是自己寫的0_0）：對於任務執行流，我們的目的是讓任務按照預定的路線運行。每一個運行都是一個單獨的單元，連接運行單元的是一條條的有向線路。首先會有唯一的一個開始節點和唯一的結束節點，中間按照模板載入成有向圖，包含處理節點（頂點）和流轉邊（有向邊）。流轉邊中有通行條件，通行條件可以是服務端返回的處理結果，也可以自定義其他的條件（類似迴圈放音之類的阻塞條件），沒有通行條件的為無條件邊，可以無條件通行。在處理時，首先執行開始節點（例如撥號），然後根據接收到返回事件通過邊來找到接下來執行的一組節點（對於搜索，類似於廣度優先，搜索到該事件能夠到達的節點為止，因為設置的通行邊中，應該只會有一個能通行才對），然後依次執行節點，直到到達結束節點後結束任務。後記：當然這裡僅僅只是一部分當時思考了比較久的東西。其實開發過程中，不免會遇到很多其他的問題。以大家的聰明才智應該可以很快解決才對，我這裡就不獻醜了~~~~

您的分享是我們最大的動力!

-Advertisement-

更多相關文章

設計模式之筆記--簡單工廠模式（Simple Factory）

簡單工廠模式（Simple Factory）類圖描述簡單工廠：一個抽象產品類，可以派生多個具體產品類；一個具體工廠類；工廠只能創建一個具體產品。應用場景汽車介面汽車類汽車工廠類調用，從配置文件中讀取操作符 ...
代碼重構(六)：代碼重構完整案例

無論做什麼事情呢，都要善始善終呢。前邊連續發表了5篇關於重構的博客，其中分門別類的介紹了一些重構手法。今天的這篇博客就使用一個完整的示例來總結一下之前的重構規則，也算給之前的關於重構的博客畫一個句號。今天的示例借鑒於《重構，改善既有代碼的設計》這本書中的第一章的示例，在其基礎上做了一些修改。今天博客 ...
實時監控Cat之旅~對Get和Post進行封裝，支持分散式消息樹

對第三方介面的調用我們需要對GET和POST進行監控，看一些請求的執行是否成功，如A調用B，B調用C，C調用D，這一連串的東西需要我們使用cat進行記錄，進行記錄之後，我們可以很容易的發現請求響應的時間及是否出錯，下麵是我對這兩種請求的封裝。在程式中使用非常方便，如下代碼，一看便知而它產生的消息 ...
[業務監控系統]MEDIVH架構設計和接入方案

本系統旨在提供業務監控實時數據和歷史數據以及報表、閾值報警、同比增長分析等一體化的歷史業務數據解決方案。技術選型 sdk部門有C#版和java版，api和website採用golang語音開發，資料庫採用mysql,數據傳輸採用socket+http 架構設計本系統主要分3個部分：即sdk（@2 ...
併發思想提煉（2）（Lock free，輪詢及線程池）

8. 告別Lock 不是一直說Lock比較麻煩危險嗎，那就不要好了。其實有一個Lock free的方法。首先引入一個概念——原子變數。在這種變數上的操作是原子操作（atomic operation）。原子操作就是說這個操作要麼都完成，要麼都不完成，部分完成是不行的。就像物理化學中的原子一樣，借用不 ...
由面試引發的思考：B/S與C/S究竟是何物

一、現狀說明：就在這金三銀四的求職黃金時期，我有幸作為公司的獨立技術面試官，擁有最終決定錄用權，在倍受上級領導的充分信任下，我也向上級保證，一定要為公司找到合適的人才，就在我滿懷信心的情況下麵試了一個又一個的求職者，發現了大多數求職者共同的問題，一是：眼高手低，即工作年限雖長，但受工作內容及個人原 ...
Magicodes.WeiChat——多租戶的設計與實現

多租戶（Multi Tenancy/Tenant）是一種軟體架構，其定義是：在一臺伺服器上運行單個應用實例，它為多個租戶提供服務。本框架使用的是共用資料庫、共用 Schema、共用數據表的數據設計架構。進入系統管理員界面，打開租戶管理界面，如下圖所示：下麵是租戶管理界面：這裡可以管理租戶成員 ...
領域驅動設計：分離領域

本章大部分內容摘自：《領域驅動設計：軟體核心複雜性應對之道》一書中的第四章，分離領域，純屬原創。如有錯誤請指正，相互學習。在軟體中，專門用於解決問題的那部分通常之占整個軟體的系統的很小一部分，這與其重要性遠遠不成比例。要想實現最佳的設計構思，就得去研究模型中的元素並它們視為一個系統模式：LAYE... ...