在沒(méi)有做云化前，整體的呼叫中心會(huì )包含著(zhù)很多種不同的網(wǎng)絡(luò )的組件，有軟件、硬件、中間件，也就是我們所謂的CTI，有人工的服務(wù)，可能也會(huì )有機器人的服務(wù)和各種各樣的系統。客觀(guān)而言，它整體的系統還是相對比較重的，以至于這樣的系統天然地就適合大型的企業(yè)。那如果是初創(chuàng )企業(yè)或者小型企業(yè)，一開(kāi)始就進(jìn)行上云，企業(yè)就很少會(huì )想去自建這么重的系統架構。這里面所謂的“重”，只是一個(gè)網(wǎng)絡(luò )組件在邏輯概念上面的重，就是說(shuō)這里面有大量的組件是系統必不可少的一塊，而并不是說(shuō)它是由大量的硬件進(jìn)行堆棧而成。

　　整個(gè)呼叫中心發(fā)展了將近有20年到30年，整體的技術(shù)演進(jìn)可以定義為四種趨勢：

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

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

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

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

　　我們今天談?wù)擃}主要是云呼叫中心與呼叫中心上云的不同。既然說(shuō)到云，呼叫中心的最核心的部件，所謂的中間件或者說(shuō)ContactCenterInfrastructure這一塊，它的系統到底應該是什么樣的架構？在這里面我們其實(shí)還可以進(jìn)一步來(lái)進(jìn)行探討，呼叫中心的核心系統架構大概是什么樣子，從廣泛的來(lái)說(shuō)，我們在業(yè)界可以看到大概是分成三種不同的系統架構，這里面和云無(wú)關(guān)，是和整體的系統軟件的或者說(shuō)系統服務(wù)的設計有關(guān)。

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

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

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

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