話務系統平臺是典型的LNMP架構，架設在AWS云服務上，前端使用AWS ELB作為負載均衡，為業務方和供應商提供接入口，流量分發到后端多臺Server上，Server可以很方便地水平擴展。ELB和Server之間有TCP健康檢查。
存儲采用MySQL，呼叫中心外呼系統用以保存號碼綁定關系、會話關系、可分配號碼號池，以及通話記錄。通話記錄歷史數據會定期歸檔。旁路有一個控制臺UI，用來做數據報表展示，以及控制號池調度?？蛻艟烤故窃鯓油ㄟ^撥打虛擬號聯系到經紀人的呢？
1. 綁定。首先客戶要拿到被叫經紀人的虛擬號?？蛻粼L問業務線產品，業務線產品調用話務平臺綁定接口，傳遞經紀人真實號，話務平臺從號池中取出一個儲備虛擬號，建立綁定關系，并將虛擬號返回給業務線產品。在這里，綁號接口同時也是查詢虛號接口，如果真實號已經有綁定關系，則直接返回已綁定虛號，如果尚未綁定，則綁定后再返回虛號。虛擬號是按需分配，并非所有經紀人都預先分配一遍，這樣可以節約號碼。
2. 撥打?？蛻魮艽蛱撎?，或者通過APP自動調用號盤撥號。通話流程轉到運營商，運營商再將通話流程轉到與之有合作關系的供應商，可以理解為供應商在運營商處注冊了路由。因為撥打的是虛號，而虛號的綁定關系存儲在話務平臺，故供應商調用話務平臺查詢虛號的綁定關系。
3. 轉接。供應商通過話務平臺接口查到虛號對應的真實號，然后做轉呼。雙方建立通話。電話銷售呼叫系統，在這里，供應商可能查到多個真實號，按照約定，供應商按順序逐個轉呼真實號，直到某一個接通或者都未接通。每次轉呼有一定的超時時間，這樣既保證用戶不用等太久，又避免經紀人漏接電話。
4. 推送話單。當通話結束之后，供應商將話單數據推送至話務系統平臺，話單包含號碼、時長、計費、通話狀態等關鍵信息。話務平臺存儲話單，并推送給業務方。在這里，可能受到網絡抖動等因素影響而推不成功，我們的解決方案是：
A、供應商重復推送，當出現超時、503等狀況時，供應商標記該條話單為“未同步成功”狀態，并在一定時間后重新發起推送，如果仍然不成功，則拉長時間間隔后再次推送；
B、話務平臺定期拉取話單，和本地數據check，若發現丟單則補單。
以上通過重復推送和推拉結合的方式保證話單數據及時、正確地同步。這一設計在其他數據同步的設計中已被證明為一種行之有效的方法，比如支付行業，第三方支付平臺通知商戶支付訂單狀態就是采用這種方法。
