呼叫中心的技術演進趨勢

　　整個呼叫中心發展了將近有20年到30年，整體的技術演進可以定義為四種趨勢：

　　趨勢一：硬件的軟件化

　　傳統的呼叫中心有大量的硬件的PBX、SBC，以及各種各樣的物理的線路和大量的呼叫中心所需要使用的硬件設備，包括話機，所以在這里面我們可以看到硬件的軟件化成為一個主流的趨勢。那大量的傳統的硬件的交換機慢慢地就會變成了基于VoIP的IMS系統。傳統的語音網關，鑒于現在4G和5G核心網絡時代的到來，運營商慢慢地都會提供IP化的通信，從傳統的模擬網關轉變成了SBC甚至eSBC，也就是說基于軟件的SBC的方式。那傳統的TDM電話逐步變成了VoIP的SIP Phone，SIP Phone既然是有硬件的，其實它也是有軟件的end point，以及最近正在流行的基于瀏覽器的WebRTC與Opus編碼的這種方式實現了整體的硬件的軟件化改造。這是一個很大的技術演進的方向。

　　趨勢二：平臺的虛擬化

　　在早些年，大量的系統都是基于小型機，或者說基于這種傳統的物理服務器而去進行部署的。慢慢的，實際上隨著企業數據中心也就是所謂的IDC的新建，很多的系統都會移植，從小型機一直到物理服務器，再從物理服務器一直到了我們所謂的虛擬化環境，也就是基于主流的是基于VMware這樣的數據中心來去進行的部署。現在整個IT行業在做云化改造的過程中，其實慢慢地如傳統的Virtual Machine，就是所謂的虛擬機，轉向了所謂的彈性計算，這種彈性計算并不一定指公有云的彈性計算，也可能是私有云，或者國內很多云的方案廠商提供的云端私有化部署的一種彈性計算服務。其實在未來，所謂的ECS服務，也叫彈性計算服務，會轉向基于容器化的服務或者基于無服務的計算。

　　趨勢三：　從IaaS層轉向PaaS層及SaaS層

　　準確地來說，之前大的一個系統工程，會從底層逐步將更多的組件移植到Platform as a Service，甚至是進一步移植到SaaS(Software as a Service)，或者是Function as a Service。怎么簡單理解Function as a Service？它并不是提供一套完備的服務，只是提供某一項功能，比如說，如果僅僅是想去調用一個呼叫中心的大量的錄音，我只想去調用一個錄音的轉譯的服務，我并不需要去買一個platform，也不需要去買一個界面，甚至不需要去買一個infrastructure的這樣一個的服務計算資源，我只需要去買這樣一個功能。它更多的是一個API的方式來去進行存在的。這是軟件云化的一個趨勢。它并非一步到位，沒有一個必然的衍生規律，并非一定是從IaaS到PaaS，到SaaS，或者是到FaaS，又或是AIasaService、Contact Center as a Service，這里面實際上可能是多種的選擇都是在很長的一段時間并存的，取決于企業的具體的需求。

　　趨勢四：場景多樣化

　　隨著技術的發展，呼叫中心本身也發生了大量的變革，包括AI的引入、語音場景的進一步豐富，尤其是視頻的發展與社交媒體的介入極大地改變了呼叫中心?，F在傳統上的呼叫中心已經不存在了，我們現在大部分都看到的是聯絡中心，甚至說是體驗中心，以這樣的一個角度去切入整體的一個系統的設計中，就是我們能夠看到的呼叫中心的四個技術的演進方向，有一些可能是呼叫中心本身自身的發展，比如說場景的多樣化，或者說視頻的引入，還有一些可能是伴隨整個IT行業往前推的這么一個浪潮，呼叫中心的這樣的系統必須去做一個核心的演化。

　　呼叫中心的核心系統架構

　　我們今天談論題主要是云呼叫中心與呼叫中心上云的不同。既然說到云，呼叫中心的最核心的部件，所謂的中間件或者說ContactCenterInfrastructure這一塊，它的系統到底應該是什么樣的架構？在這里面我們其實還可以進一步來進行探討，呼叫中心的核心系統架構大概是什么樣子，從廣泛的來說，我們在業界可以看到大概是分成三種不同的系統架構，這里面和云無關，是和整體的系統軟件的或者說系統服務的設計有關。

　　第一種：單體式架構

　　簡單來說就是我們傳統意義上所謂的All-in-one，也就是說一套系統，一套軟件。它可以去滿足一個它的系統設計指標之內的這樣子的一個服務。它可能也會分層，但是它的所謂的分層，它將不同的邏輯層也就是變成它整體的all-in-one軟件中的具體的某些模塊某些module來支持一些定義和一些開發。它天然的一個缺陷是什么？天然的缺陷就是它的整體的設計的指標和能力是由它誕生第一天就已經決定好了。當我的需求是需要去做進一步的靈活更改時，它的模塊化的這種定制能力，會受到整體軟件系統設計的桎梏。同時，它的系統容量，我們簡單理解它是需要堆盒子的方式來去實現的。堆盒子就會產生第二個問題，堆盒子時候，如何實現盒子與盒子之間的通訊？痛點在于:由于單體式設計所帶來的模塊化集群，必然會引發技術的復雜度。小型化開源軟件或者說小型化all-in-one的這種CTI中間件都會存在這樣的一個問題。如果是這個系統它軟硬一起，惡劣情況更加劇。如果你的軟件是綁定于特定硬件或者是基于部分硬件，它實際上是沒法去做到一個云化的改造的。

　　第二種：基于分布式的面向對象的架構

　　實際上這是一種主流的方式。它是由傳統企業軟件向云化軟件轉變的一個必然的過程會存在，當然有可能會有的企業會直接選上第三種，大家都能看到第三種叫做Microservice，第二種叫基于分布式的面向對象的架構。簡單而言，我將不同的模塊轉換成不同的服務，由不同的服務由不同的Server或者是容器來去進行承載?？陀^而言，由于我的分布式架構會讓它的系統的彈性會變得非常好。當然它還是有一些系統的缺陷，也就是說它會基于這個依賴，也就是基于我們傳統軟件里面的ClusterHA這樣的一些特性，去進行系統的高可用性和高容量性的一些保證。它帶來的好處是什么？它帶來的好處是由專業的component專業的service去做專業的事情。它單體的設計，如果你的設計足夠好，單個的service的設計足夠好，它可以讓它的容量能夠進一步的躍升，同時由于它采用這種分布式的面向對象的這種操作。我們這里要避免的一個誤區，并不是說所有的系統所有的軟件一定要天然就必須是microservice才是最好，永遠是適合客戶的才是最好的，永遠是符合用戶真實場景的才是最好的。比如說，我們呼叫中心有大量的結構化數據，你說不行，我非要用Non-SQL，OK是可以的，但是它都會帶來效率的降低，因為本身呼叫中心的數據本身天然就是一個結構化數據，如果你非要用一些分布式的Non-SQL的一些數據庫來進行服務，實際上它是并不能夠完全很好地匹配的。雖然它的技術可能會更加先進，但是這種先進性并不適用于這樣的場景和這樣的客戶的需求。

　　第三種：基于微服務的架構

　　最后一種是現在最時髦最先進的，我們可以認為也是最主流的下一代軟件的或者面向互聯網的軟件設計的一種方案，就是基于微服務的方案。那微服務它是一種開發的方法，它并不是一個像一套軟件，我release一個版本之后我就可以去可以再過每個大半年或一年去做一個大的版本更新。微服務的它的一個特點就是將SOA的這樣一個服務進一步地進行拆分。它主要是主流的我們會基于SpringCloud，SpringBoot，或者說阿里的那個Dubbo的這樣的一個平臺，基于他們這樣的一個開發的這種框架來去進行進一步的拆分。它的一個好處就是說，它整體的系統會更加靈活，它的容錯率會更好。但實際上它也會帶來一些復雜度。它的復雜度是什么？就是當我出現問題時，實際上基于微服務的理念，我第一個系統做出的反應是容錯，我允許錯誤存在。同時我會能夠進行快速的替代和快速的迭代以及版本更新。當然對于運維而言它是一個非常好的地方。但是它對于我們傳統的技術的支持或者說故障的處理以及問題的回溯，它會帶來一個從復雜度帶來一個指數級的上升。那簡單理解，以前我出現一個問題，如果是SOA架構，我看著像我們這張圖里我們看四個Component就能夠看明白。如果是Microservice，我可能要去看上百個不同的log。所以在微服務中的日志管理以及故障定位，會顯得更加的重?；旧蟻碚f，把主流的IT行業的這樣的公司都會采用DevOps這種方式也就是開發運維這種方式來進行完成系統架構。

　　這三種方案這三種系統架構都是可以上云的，但是它上云所產生的實際的這種用法和實際的效果是不一樣的。