呼叫中心的技术演进趋势

　　整个呼叫中心发展了将近有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的引入、语音场景的进一步丰富，尤其是视频的发展与社交媒体的介入极大地改变了呼叫中心。现在传统上的呼叫中心已经不存在了，我们现在大部分都看到的是联络中心，甚至说是体验中心，以这样的一个角度去切入整体的一个系统的设计中，就是我们能够看到的呼叫中心的四个技术的演进方向，有一些可能是呼叫中心本身自身的发展，比如说场景的多样化，或者说视频的引入，还有一些可能是伴随整个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。所以在微服务中的日志管理以及故障定位，会显得更加的重。基本上来说，把主流的IT行业的这样的公司都会采用DevOps这种方式也就是开发运维这种方式来进行完成系统架构。

　　这三种方案这三种系统架构都是可以上云的，但是它上云所产生的实际的这种用法和实际的效果是不一样的。