呼叫中心怎样充分利用云计算的优势？
采用哪种架构才能应对业务快速增长的挑战？
建立原生云架构最重要的一步是什么？
不断扩大的业务规模与快速增长的客户数量，促使企业呼叫中心对大规模座席可用性要求日益提升，自建与外包职场的统一管理需求以及外呼、质检效率等问题为呼叫中心带来挑战，传统模式难以为继。
云计算、人工智能等新技术的兴起，推动呼叫中心行业进入新时代，以硬件集成为特点的传统呼叫中心迎来变革机遇。曾经多租户技术有效降低一次性建设成本，赋予呼叫中心更好的座席弹性；软交换和CTI部分云化解决了扩展性等问题，现在呼叫中心云服务逐渐受到企业客户的认可与信赖。
呼叫中心怎样充分利用云计算的优势？采用哪种架构才能应对业务快速增长的挑战？建立原生云架构最重要的一步是什么？
一:什么是原生云架构
传统呼叫中心软件架构有些设计理念与云计算价值相背。如果传统呼叫中心软件架构继续以CPU序列号方式来做license授权，那么在云端虚拟环境底层硬件变化时，呼叫中心将变得不可用。
原生云架构就是打破了传统呼叫中心软件架构的设计理念，与云计算价值与发展相一致，在基础设施、平台、软件等方面全部采用云化资源的架构模式。原生云架构利用云端成熟、开放、开源技术，使得基于原生云架构的呼叫中心成为了一个可生长的系统。呼叫中心可与云服务组件的性能增长、功能完善、可用性提升等共同成长。
图1 呼叫中心演进历程
基于原生云架构，呼叫中心将变得比以往能力更强、效率更高，可以有效满足对平台高可用性的需求，同时在大容量、高弹性、扩展性、快速部署等方面具有优势。
呼叫中心的每一次进步都与技术进步紧密相关，云计算是呼叫中心云服务的核心技术，赋予呼叫中心随时随地、按需便捷地使用共享计算资源、存储资源和应用功能，有效解决平台大容量下的高可用性、扩展性等问题，此外使得呼叫中心在部署速度、统一管理、成本管理等方面具有极大优势。当前采用原生云架构的天润融通CTI-Cloud，成功实现单平台20000座席并发登录，平台可用性也达到99.99%。
二：原生云架构的建立与探索
天润融通一直致力于用新模式、新技术为企业提供高品质的呼叫中心服务。作为全球最大的云服务商AWS中国区高级技术合作伙伴，天润融通充分利用与AWS的合作，基于云平台更加地专注在呼叫中心云服务的演进与应用。
关注用户需求，领先一步。“我们曾经在团队中讨论过如何用S3做对象数据库，然而S3 Select、Glacier Select不久后便上线了”，天润融通总架构师安静波介绍说，“当我们想做跨区（Region）漂移时， AWS Aurora Multi-Master则恰好发布；当我们尝试用Kaldi做语音识别时，Amazon Transcribe则提供了托管服务。”AWS新产品的发布总是领先用户一步，用户可以方便地根据自身节奏演进产品。
无服务器架构创新让开发者更专注。Lambda是AWS在2014年推出的世界上第一个基于无服务器架构技术（Serverless）的商用产品，一经推出便备受推崇。re:Invent 2017上大量实践案例分享标志着这项技术的成熟。除无服务器架构的核心Lambda、API Gateway之外，Aurora、Baremetal、GPU、FPGA、 IoT等都可以在AWS找到，开发人员已不再需要关注和代码不相关的任何事情，只需关注业务逻辑，连接服务即可。
天润融通CTI-Cloud的原生云架构基于AWS各种成熟的云服务组件来进行快速迭代、快速演进，使用微服务架构技术将呼叫中心切成了26个子模块，每个模块均利用集群、双活等技术实现大容量、高弹性、高可用性。
图2 天润融通 CTI-Cloud 的原生云架构
图3 原生云架构正在使用和即将使用的 AWS 服务
在天润融通目前正在使用的AWS服务（见图3）中，黄色虚线框内的是去年才开始使用，如Lambda是可以让开发者无需配置或管理服务器即可运行代码的服务，用来实时处理流数据，不运行不收费，可以用来降低成本；Amazon DynamoDB 是一项快速灵活的 NoSQL数据库服务，在数据库管理、性能、可扩展性和可靠性等方面具有非常大的优势，适合任何容量情况下低延迟存储、读取数据的应用程序等。
近年来人工智能技术在呼叫中心行业的应用变得广泛，如机器学习、语音识别、NLP等。Lex、Polly、Machine Learning等人工智能相关的服务（见图3）也已经在我们后续的使用计划中了。这些人工智能技术的应用将为呼叫中心带来更优秀的体验和效率提升，比如Polly是一种文本转换为逼真语音的服务，可用来替换传统TTS冰冷生硬的机器人声音。
三：录音处理架构的演进与价值
原生云架构变革最重要的一步和价值是什么？我们可以从录音处理架构的演进过程看出端倪。录音处理架构最重要的一步就是应用Auto Scaling和Lambda，使录音处理获得了高可用性、大容量、高弹性，并且解决掉录音会丢失情况，同时极大地降低了录音生成时间以及成本。
图4 第一代录音处理架构
在第一代录音处理架构中，录音是从CTI-Cloud平台的sip-media模块产生，经过弹性负载均衡器（ELB）转到media-zip录音压缩处理模块进行处理，最后将所有wav文件和处理后的mp3文件上传到S3。
该架构最大的缺点是无弹性，需要预置media-zip的个数，当出现业务高峰时，录音处理延时会加大，如果预置太多实例，就会在业务低谷时造成极大的浪费。
图5 第二代录音处理架构
在第二代录音架构中使用Auto Scaling将sip-media和media-zip两个模块放在了弹性伸缩组，能够随业务量变化弹性伸缩。但是该架构也有两个缺点：因为所有录音wav文件都是通过弹性负载均衡器到后端的media-zip，所以弹性负载均衡器的流量压力会比较大；media-zip的弹性伸缩要负责处理实例销毁，如果实例在处理完wav文件之前销毁，会造成录音丢失。
图6 无服务化-录音处理架构
在最新一代无服务化-录音处理架构中，使用Lambda函数替换了EC2实例弹性组。wav文件通过sip-media直接上传到S3 bucket上，省去中间弹性负载均衡的环节。在S3上通过配置事件驱动启动Lambda，Lambda会获取wav文件并转换成mp3，然后上传到S3 bucket上，整个中间的处理全部实现无服务化。
该架构有三个优势：更快的弹性、更可靠、更便宜，弹性响应从5分钟缩短到了1秒，录音生成时间缩短到5秒之内；实现自动异常处理、先上传后处理；从按照实例计费变成按毫秒计费。