開放化的語音平臺結合場景化的應用，使得云呼叫中心平臺對容量和穩定性提出了更大的要求。如何滿足客戶彈性業務需求，應對業務時段峰值?下面就以某訂餐業務模型為例，探討下云呼叫中心架構該如何應對？
　　某外賣業務模型

某外賣業務流量圖

　　每天中午11:00-12:30，晚上17:00-19:00訂餐業務高峰，極不均衡

　　在智能云呼叫中心平臺設計之初，我們根據平臺客戶的業務需求特點，對平臺架構設計確認了如下幾點原則：

　　1.平臺架構應基于開放成熟的云IaaS服務；

　　2.在云端進行架構設計時要保持悲觀，假設所有事物都會發生故障。換句話來說，架構需要面向故障的自動化恢復來設計，實施和部署。平臺任何模塊必須是HA架構，消除單點模塊；

　　3.應用云IaaS服務與IDC機房由DX專線組成混合架構云；

　　4.分布式架構，必須非常容易擴容，支持自動彈性伸縮；

　　5.平臺中模塊之間的關系降低耦合，便于業務的快速演進；

　　6.以業務監控、日志和統計為運營核心構建平臺；

　　7.具備跨機房級別的高可用結構；

　　8.完善的完全機制，自我保護與服務降級能力；

　　憑借“云中優勢”進行系統組網。

　　基于云平臺的架構在組網結構上具備明顯的商業優勢。體現在幾乎為零的啟動成本，靈活的資源按需付費模式，快速的擴容上線能力等方面。

　　在技術層面云平臺架構也存在明顯優勢。可實現自動化構建和部署，自動擴展無需人工干預，可將測試持續注入到開發過程各個階段，實現改進的可預測性。

　　天潤融通智能云呼叫中心平臺，基于AWS云/阿里云+DX直連IDC組建的混合架構云，既能利用云平臺的“云中優勢”又能兼容特殊應用讓平臺的運行上線無縫切換。在網絡架構上，將核心機房和落地機房通過專線打通，形成環線。其中任何一點的專線故障都可以通過整體的網絡調度，由其他專線或互聯網進行切換傳送，從而不影響業務的正常運轉。

高可用的組網結構圖

　　在基礎IaaS云服務上構建大容量高可用的系統。

　　在基礎IaaS云服務方面，AWS與阿里云差別不大，以下僅以AWS為例說明如何在基礎IaaS服務之上構建大容量高可用的系統。

　　目前智能云呼叫中心平臺架構基于AWS所提供的3層基礎服務：

　AWS云平臺組件服務

　　第一層。 基礎計算、存儲和網絡組件，包括EC2，S3，EBS，VPC和DX等等。其中S3服務由AWS提供11個9的持久性，DX專線采用2條互為備份的1G直連保證了網絡性能。

　　第二層。高可用的數據庫RDS，Cache，SNS和SQS應用組件，支持跨機房的高可用和可靈活擴容。實時處理部分全部使用Rediscache降低數據庫壓力，大量使用SQS做異步化處理實現削峰填谷。

　　第三層。應用層的ELB負載均衡器，AutoScaling彈性伸縮，以及完善的監控和日志服務。系統各模塊首先全部是無狀態的，AutoScaling的應用使得通過ELB收集采樣來的當前負載和伸縮策略相結合，能夠動態調整EC2的實例個數，當業務高峰時啟動大量實例承接業務，而低谷時減小實例降低成本。

　　在平臺架構設計中必須意識到，故障和故障切換是作為系統架構的一部分存在的。通過AWS/阿里云等云環境提供的容錯架構，大大降低了系統運維方面的復雜性，實際上這部分架構是由云環境完成了。與基礎硬件故障設計一樣，平臺軟件方面也必須進行故障切換的架構設計，比如：如果一個模塊down掉，平臺上的應用怎么辦？如果接口請求超時或異常怎么處理？如果突發請求超過系統容量又怎么辦？

　　我們的經驗是基于SOA面向服務的架構理念，構建組件之間的關鍵是減小組件之間的依賴。如果一個組件掛了沒有響應或響應時間過長，系統中其他組件應該能繼續工作。組件之間盡量相互獨立，通過異步交互方式使用消息隊列設計組件間的接口。這樣即使某些功能暫時不能用，整個系統仍然繼續運行，當出問題的組件恢復后仍然可以使用消息隊列中的數據恢復運行狀態。

　　基于SOA面向服務的架構理念，我們解耦和拆分構建了大量的生態子系統，系統之間通過API調用構建完整的功能生態鏈，比如NOSS網管中心，BOSS營帳中心，NMC碼號中心，TTS-proxy語音合成中心，SMSC短信平臺等等，整體架構如下圖所示意:

整體架構圖

　　除了整體生態系統層面做了解耦和面向微服務架構的拆分工作，智能云呼叫中心核心交換平臺也進行了大量微模塊拆分。共計拆分了25個子系統，其中主要的子系統如下：