一种呼叫管理的系统及方法
技术领域
本申请涉及语音通信技术领域,尤其涉及一种呼叫管理的系统及方法。
背景技术
呼叫管理为企业通信领域应用中的基础功能,常见的应用包括呼叫中心、办公通话、电话营销等,呼叫控制包括呼入的控制和呼出的控制,控制包括呼叫的发起、建立、转接(通信行业称为呼叫路由),多人通信的加入、移除和关闭,通话中播放语音和录音,形成呼叫记录等。呼叫控制包括信令控制和媒体控制。
在企业通信领域典型的呼叫中心的系统中,自动呼叫分配(ACD)是一个非常关键的功能。ACD包括对来电的处理,收集客户的意图,并把呼叫转接到合适的业务代表。业务代表(简称Agent)是呼叫中心的工作人员,他们使用软件和电话签入呼叫中心系统,通过客户端软件的状态设置来表达自己接听电话的意愿(如就绪状态,就是表示可以接听ACD分配的电话),同时,通过Agent的技能设定,ACD可以选择不同技能的座席群组来服务不同的来电。
传统的设计模式
设备(座席使用的通话终端,包括常用的话机或具有通话功能的PC软件)的状态、呼叫的状态和座席状态都是一个有限状态机,这几个状态机会相互影响,逻辑上有紧密耦合。比如座席的分机振铃时(RINGING),呼叫状态从空闲(IDLE)变为振铃,座席会从就绪变成忙(BUSY),产生了联动。如果在一个计算机的进程内处理,相对比较简单,一个进程可以管理以上所有的对象和数据,处理逻辑和状态数据天然在一起,也不必考虑跨进程和跨网络的调用,相对比较容易。
一般情况下,所有座席是通过局域网签入到同一个计算机上的服务进程,同时这个所有的来电请求,也是由同一个服务进程来处理。这种模式下,单个服务进程受单个硬件服务器性能的限制,一般最多处理2000并发座席和2000并发的呼叫,而且所需的硬件成本不菲。还有,如果这个服务进程失败,会导致所有座席状态丢失,呼叫中断,在系统恢复以后,座席重新签入才能继续工作,严重影响了用户体验和工作效率。受单个计算机损坏概率的影响,这种系统设计很难满足客户对高稳定性系统品质的要求。
当座席量和呼叫量比较大时,尤其系统做为云服务提供商的呼叫管理平台时,很可能会达到较大的服务数量,比方在线座席会超过5000到10000,呼叫并发会从几千到几万。传统的技术设计方案受到单个计算单元瓶颈的限制,无法做到云平台性能随需求扩展而水平扩展的机制。业内目前没有很好的分布式方案。
发明内容
本申请的一个目的是提供一种呼叫管理的系统及方法,解决现有技术中受硬件服务器性能影响,并发处理能力不高,无法满足云平台多租户系统性能要求的问题。
根据本申请的一个方面,提供了一种呼叫管理的系统,该系统包括:
呼叫逻辑处理器、设备逻辑处理器及座席逻辑处理器;
所述呼叫逻辑处理器用于根据接收到的呼叫请求生成呼叫消息,并将所述呼叫消息发送至所述座席逻辑处理器,其中,所述呼叫消息包括呼叫对象;
所述座席逻辑处理器用于根据所述呼叫消息进行分配座席并将所述呼叫对象对应的呼叫状态反馈至所述设备逻辑处理器;
所述设备逻辑处理器用于处理所述呼叫状态、设备与座席之间的绑定关系以及设备的注册和注销。
进一步地,所述座席逻辑处理器用于为所述呼叫消息分配目标座席,所述呼叫逻辑处理器用于将所述呼叫消息转接至所述目标座席;
所述呼叫逻辑处理器用于将接收到的由所述目标座席根据所述呼叫消息确定的呼叫事件转发至所述设备逻辑处理器。
进一步地,所述设备逻辑处理器用于确定所述目标座席与座席客户端的绑定关系,并将所述呼叫事件发送至与所述目标座席具有绑定关系的座席客户端。
进一步地,所述系统包括第一微服务软件单元、第二微服务软件单元和第三微服务软件单元,分别用于封装所述呼叫逻辑处理器、设备逻辑处理器及座席逻辑处理器中的逻辑。
进一步地,所述座席逻辑处理器用于指定待签入设备,所述第三微服务软件单元查询在所述第二微服务软件封装中的所述待签入设备的状态,所述座席逻辑处理器根据所述待签入设备的状态将所述待签入座席签入系统。
进一步地,所述呼叫对象包括主呼叫对象和被呼叫对象,当所述呼叫请求进入所述呼叫系统后,所述呼叫逻辑处理器用于根据所述被呼叫对象所属的设备类型确定呼叫路由,其中,所述设备类型包括逻辑设备和终端设备。
进一步地,所述逻辑设备用于当所述呼叫请求进入驻留状态后,从对应的交换机触发一事件,根据所述事件获得呼叫路由的请求。
进一步地,所述系统包括通用消息模块,用于处理呼叫逻辑处理器、设备逻辑处理器及座席逻辑处理器之间的消息解耦。
进一步地,所述系统包括负载均衡模块,用于将座席的请求分发至所有座席逻辑处理器。
根据本申请又一个方面,还提供了一种呼叫管理的方法,该方法包括:
根据呼叫系统的状态机处理器内对象的不同状态将所述状态机处理器划分为呼叫逻辑处理器、设备逻辑处理器及座席逻辑处理器;
所述呼叫逻辑处理器根据接收到的呼叫请求生成呼叫消息,并将所述呼叫消息发送至所述座席逻辑处理器,其中,所述呼叫消息包括呼叫对象;
所述座席逻辑处理器为所述呼叫消息分配目标座席,所述呼叫逻辑处理器将所述呼叫消息转接至所述目标座席;
所述呼叫逻辑处理器将接收到的由所述目标座席根据所述呼叫消息确定的呼叫事件转发至所述设备逻辑处理器。
进一步地,所述方法包括:
所述设备逻辑处理器维护所述目标座席、所述目标座席使用的设备和座席客户端之间的绑定关系,同时,跟踪设备状态和设备上的呼叫,并将所述呼叫事件发送至与所述目标座席具有绑定关系的座席客户端;
所述座席客户端通过所述设备逻辑处理器同步设备的状态和设备上的所有呼叫信息。
根据本申请一个方面,还提供了一种计算机可读介质,其上存储有计算机可读指令,所述计算机可读指令可被处理器执行以实现如前述所述的方法。
与现有技术相比,本申请提供了一种呼叫管理的系统,该系统包括:呼叫逻辑处理器、设备逻辑处理器及座席逻辑处理器;所述呼叫逻辑处理器用于根据接收到的呼叫请求生成呼叫消息,并将所述呼叫消息发送至所述座席逻辑处理器,其中,所述呼叫消息包括呼叫对象;所述座席逻辑处理器用于根据所述呼叫消息进行分配座席并将所述呼叫对象对应的呼叫状态反馈至所述设备逻辑处理器;所述设备逻辑处理器用于处理所述呼叫状态、设备与座席之间的绑定关系以及设备的注册和注销。可以通过水平扩展处理器提高并发处理能力,从而可以支持更多的座席;同时由于单个处理器的失败不会影响整体的功能,因此可以解决宕机导致的服务暂停可能,从而提高了业务的连续性。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显:
图1示出根据本申请的一个方面提供的一种呼叫管理的系统的结构示意图;
图2示出根据本申请又一个方面提供的一种呼叫管理的方法流程示意图。
附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
下面结合附图对本申请作进一步详细描述。
在本申请一个典型的配置中,终端、服务网络的设备和可信方均包括一个或多个处理器 (例如中央处理器(Central Processing Unit,CPU))、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器 (RandomAccess Memory,RAM) 和/或非易失性内存等形式,如只读存储器 (Read Only Memory,ROM) 或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存 (Phase-Change RAM,PRAM)、静态随机存取存储器 (Static Random Access Memory,SRAM)、动态随机存取存储器 (DynamicRandom Access Memory,DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (Electrically Erasable Programmable Read-Only Memory,EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器 (Compact Disc Read-OnlyMemory,CD-ROM)、数字多功能光盘 (Digital Versatile Disk,DVD) 或其他光学存储、 磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
图1示出根据本申请的一个方面提供的一种呼叫管理的系统的结构示意图,该系统包括:呼叫逻辑处理器11、设备逻辑处理器12及座席逻辑处理器13;所述呼叫逻辑处理器11用于根据接收到的呼叫请求生成呼叫消息,并将所述呼叫消息发送至所述座席逻辑处理器13,其中,所述呼叫消息包括呼叫对象;所述座席逻辑处理器13用于根据所述呼叫消息进行分配座席并将所述呼叫对象对应的呼叫状态反馈至所述设备逻辑处理器12;所述设备逻辑处理器12用于处理所述呼叫状态、设备与座席之间的绑定关系以及设备的注册和注销。在此,所述呼叫管理为对呼叫的整个生命周期的管理,呼叫管理系统用于管理设备到呼叫的连接以及维护呼叫对象的状态。当呼叫从外部进入呼叫管理系统的交换机后,呼叫逻辑处理器11会收到呼叫进入的消息,并为该消息生成一个新的呼叫对象;呼叫处理逻辑处理器11把呼叫消息发送给座席逻辑处理器13,座席逻辑处理器13分配到一个座席,并将所述呼叫对象对应的呼叫状态反馈至所述设备逻辑处理器12,从而设备逻辑处理器12针对该呼叫状态反馈进行终端设备的响应。设备逻辑处理器12用于管理注册到呼叫平台的终端设备,每个终端设备都有唯一的分机号码,设备逻辑处理器12中的设备管理逻辑主要包括设备的注册和注销以及设备的呼叫状态、设备与座席的绑定关系等。
在本申请一实施例中,所述座席逻辑处理器用于为所述呼叫消息分配目标座席,所述呼叫逻辑处理器用于将所述呼叫消息转接至所述目标座席;所述呼叫逻辑处理器用于将接收到的由所述目标座席根据所述呼叫消息确定的呼叫事件转发至所述设备逻辑处理器。在此,以来电后通过座席实现弹屏为例,座席逻辑处理器为呼叫消息分配一个目标座席,将该目标座席做登录的分机设备的标识信息(ID)发送给呼叫逻辑处理器,呼叫逻辑处理器将呼叫转接给目标座席的分机,分机振铃,呼叫逻辑处理器接收到振铃信息后转发给设备逻辑处理器。
接上述实施例,所述设备逻辑处理器用于确定所述目标座席与座席客户端的绑定关系,并将所述呼叫事件发送至与所述目标座席具有绑定关系的座席客户端。在此,设备逻辑处理器把振铃事件发送给座席客户端,座席客户端通过振铃消息获取来电信息,完成客户信息弹屏。其中,座席客户端是根据设备逻辑处理器中的座席与座席客户端的绑定关系确定的,座席客户端为设备逻辑处理器所管理的终端设备。
在本申请一实施例中,所述系统包括第一微服务软件单元、第二微服务软件单元和第三微服务软件单元,分别用于封装所述呼叫逻辑处理器、设备逻辑处理器及座席逻辑处理器中的逻辑。在此,将状态机处理器作为逻辑部分,处理器内的对象的状态本身作为数据部分,将逻辑部分和数据部分放至不同的微服务进程里,即使用三个微服务软件单元进行存放上述三个逻辑部分,按照呼叫管理逻辑、座席管理逻辑和设备管理逻辑的不同定义和职责进行逻辑拆分,每种状态数据只由一种逻辑处理器负责读写,对应的逻辑处理器为呼叫逻辑处理器11、设备逻辑处理器12及座席逻辑处理器13。其中,将所有状态数据集中存放到内存数据库中,内存数据库采用多进程集群同步复制的方式从而保证可靠性。
基于对呼叫中心的功能按以上的逻辑分析进行拆分,把单个对象的职责分配到独立的逻辑处理单元。由于三种对象的状态影响与依赖,又必须共享数据,但每一类型的对象的数据(主要是座席对象、设备对象和呼叫对象)只能由负责这一类逻辑的处理单元修改,其他类型的对象如果需要及时获得其他对象状态的变化必须通过事件的机制,按对应的逻辑来驱动自身状态机的改变。每一种对象的处理逻辑可以分布和扩展,那么每一类对象的所有数据必须在所有这一类处理单元之间共享。在本申请实施例中定义了每个对象能产生的消息,确保这些信息的必要性、完整性和原子性,同时还定义了每类对象之间的依赖关系和自身的状态机的完整性,保证整体上的逻辑自洽性。
在本申请一实施例中,所述座席逻辑处理器用于指定待签入设备,所述第三微服务软件单元查询在所述第二微服务软件封装中的所述待签入设备的状态,所述座席逻辑处理器根据所述待签入设备的状态将所述待签入座席签入系统。在此,在座席签入系统时,座席需要指定一个设备,封装座席管理逻辑的第三微服务软件单元查询封装设备管理逻辑的第二微服务软件内待签入设备的状态,若该待签入设备不空闲,则会拒绝座席签入,若待签入设备空闲,则允许座席签入;从而避免了多个座席争抢一个设备,也避免了使用一个不可用的设备。若签入成功,则第三微服务软件单元通知第二微服务软件单元,第二微服务软件单元会跟踪到哪个座席在使用该设备。
在本申请一实施例中,所述呼叫对象包括主呼叫对象和被呼叫对象,当所述呼叫请求进入所述呼叫系统后,所述呼叫逻辑处理器用于根据所述被呼叫对象所属的设备类型确定呼叫路由,其中,所述设备类型包括逻辑设备和终端设备。在此,呼叫为两方或两方以上的参与者之间的通话,呼叫对象包括主呼叫对象和被呼叫对象,当呼叫从中继线路或普通终端设备进入系统后,根据呼入的号码来查询,对应被叫号码的设备类型是终端设备还是逻辑设备,从而根据设备类型确定路由,即如何进行路由。
进一步地,所述逻辑设备用于当所述呼叫请求进入驻留状态后,从对应的交换机触发一个事件,根据所述事件获得呼叫路由的请求。在此,逻辑设备具有驻留功能,呼叫进入驻留状态后,从对应的交换平台触发一个事件,呼叫逻辑管理处理器通过该事件生成一个呼叫路由的请求,并通过座席逻辑处理器的接口获取座席并提供路由的结果,该路由的结果包括所分配座席登录的设备ID,呼叫管理单元将所获取的座席设备ID作为路由的目标地址通知交换机,使得语音交换机完成呼叫的转接。通过以上所述过程,呼叫逻辑处理器完成了呼叫分配任务。
在本申请一实施例中,继续参考图1,所述系统包括通用消息模块100,用于处理呼叫逻辑处理器、设备逻辑处理器及座席逻辑处理器之间的消息解耦。所述系统包括负载均衡模块200,用于将座席的请求分发至座席逻辑处理器组。在此,该系统包括通用消息模块100(图1中的通用消息处理总线),用于不同逻辑处理器之间的消息解耦,使用负载均衡模块(图1中的通用负载均衡器200)将座席的请求均衡分发给所有座席逻辑处理器组;该系统还包括存储模块,用于保存所有对象状态的内存数据库300,内存数据库300采用多进程集群同步复制的方式保证可靠性。
本实施例中的所描述的消息分为两类:一类是来自于客户端操作发起的请求消息,一类是基础呼叫平台产生的消息(又称为事件)。本实施例对内存数据访问的规则是:每一种逻辑处理单元只负责一种对象的数据管理,其他逻辑单元无权访问。比如,座席逻辑处理器只管理座席对象的相关数据,并不能直接读取设备对象和呼叫对象的数据。但呼叫相关的变化会反映到设备上,而设备相关的变化也会通知到座席管理器。从而保证了呼叫处理过程的完整性和设备、座席管理的闭环,实现了呼叫中心的所有基本功能。
本实施例在多个服务器上同时运行座席、呼叫、设备管理的服务进程,且并行运行多个同类的服务进程(形成服务群组,也叫集群)以提高并行处理能力。以一个2.0GHz的处理器核心作为处理单元,系统的平均处理能力:一个核心支持5000座席对象,支持3000设备对象,支持每小时150000次呼叫。座席逻辑处理器(ASM)、设备逻辑处理器(EXT)、呼叫逻辑处理器(CMS)分别通过服务器资源的扩充和增加逻辑处理单元数量的方式扩展(在新增加的服务器资源上按比例增加各类微服务的数量),以近似水平的方式提高整个平台的处理能力。
单个的逻辑处理单元不限于只操作特定的对象,集群中的任何一个处理单元都有同样的处理逻辑,因此可以通过水平扩展来提高这一类逻辑处理的速度(如单个进程每秒2000个消息,10个进程可以提高到2万左右)。由于逻辑处理单元处理对象状态的依据就是所收到的消息,而同一类型的逻辑处理单元都处理同一类型的消息。如ASM只处理座席相关的消息,某个座席修改座席状态的请求可以由任意一个ASM处理器来处理,取决于负载均衡器的分配。通过监控这三类逻辑处理器的平均消息处理时长和单位时间内的消息处理数量,可以评估当前系统所承受的压力,在业务系统受到压力时可通过手动或自动的方式,申请并上线新的处理资源并自动部署对应的逻辑处理器,部署完成后通知对应的负载均衡器。负载均衡器在检测到对应的逻辑单元成功运行后,就会把它加入到可以处理这一类逻辑的后台处理器群组里。
本实施例中座席管理逻辑的定义:座席就是使用呼叫中心的工作人员,通过一个客户端的软件工具(通常为软电话或集成了软电话功能的客户端软件)签入平台,签入时需要提供三个基本要素:座席的工号、工作的设备ID和密码。座席工号是呼叫管理系统分配的座席唯一的ID,设备ID一般就是通信平台上分机的号码。座席管理逻辑包括签入、签出和座席工作状态的控制和展现。
本实施例中设备管理逻辑的定义:这里的设备指的是注册到通信平台的通信终端。每个终端都有唯一ID(即分机号码)。设备管理逻辑,主要包括设备的注册和注销(在线或离线)以及设备的呼叫状态、设备与座席的绑定关系等。虽然基础通信平台也具有设备的管理,但本发明的实施中,更关注的是设备在呼叫中的状态,设备管理逻辑需要从基础通信平台吐出的事件和消息中同步设备的呼叫状态(包括空闲、摘机、振铃、通话、呼叫中等)。
本实施例中的平台特指提供呼叫中心功能的通信管理系统,是一个由多个软件模块组成的分布式系统。在系统中呼叫模型包括了呼叫发起方和参与方设备,设备的操作会实时地影响呼叫的状态。而设备上呼叫的状态,也会立即影响到座席的状态。如果设备有呼叫在进行时,座席是不允许签入和签出的,此时设备的状态是忙。如果设备上签入了座席,设备的忙闲状态可以影响座席的状态。以上所描述的三种逻辑是有联动的。
本实施例中呼叫管理逻辑的职责包括确保呼叫的状态和呼叫的正确流转,跟踪呼叫中各方的状态,合理地控制呼叫的媒体流。在一个微服务的软件单元(CMS)里封装呼叫管理逻辑,但不包括修改座席状态和设备状态,只是负责呼叫对象的状态机。
本实施例中座席管理逻辑的职责包括确保座席状态的合理性、正确性和权威性,保证座席的任务能按业务规则分配;呼叫业务规则包括先闲先服务、最高等级技能等级优先服务、工作量平均分配服务逻辑。在一个微服务的软件单元里(ASM)封装座席管理逻辑,但不包括修改呼叫状态和设备状态,只是负责座席对象的状态机。
本申请所述的呼叫管理系统把状态机处理器(逻辑部分)和对象的状态本身(数据部分)进行分离,放到不同的微服务进程里,且按照呼叫管理逻辑、座席管理逻辑和设备管理逻辑的不同定义和职责进行合乎逻辑的拆分,然后把所有的状态集中存放到内存数据库里,内存数据库采用多进程集群同步复制的方式保证可靠性,一点写入,多点读取。由于状态处理逻辑不负责状态数据的存储,因此能做到并发,可以在多个服务器上按当前座席和呼叫负载,并行跑多个实例(服务进程)来提高处理能力,而且即使某个服务器出现故障,某些逻辑处理进程异常结束,也不会造成大的影响,最多是个别的呼叫异常,而座席状态会和通过其他的服务进程保持同步。座席逻辑处理器(ASM)、设备逻辑处理器(EXT)、呼叫逻辑处理器(CMS)分别可以通过水平的方式进行扩展,提高整个平台的处理能力。其中,所述平台为能提供大规模联络中心服务的呼叫处理平台,包括底层的软交换系统和上层的呼叫模型管理(包括设备逻辑处理器和呼叫逻辑处理器)和座席模块管理(包括座席逻辑处理器)。
图2示出根据本申请又一个方面提供的一种呼叫管理的方法流程示意图,该方法包括:步骤S11-S14,
在步骤S11中,根据呼叫系统的状态机处理器内对象的不同状态将所述状态机处理器划分为呼叫逻辑处理器、设备逻辑处理器及座席逻辑处理器;在此,状态机处理器内的对象为呼叫模型对象,对象的状态本身作为数据部分,状态机处理器为逻辑部分,将逻辑部分和数据部分放至不同的微服务进程里,即将处理器按照逻辑划分为呼叫逻辑处理器、设备逻辑处理器及座席逻辑处理器。
在步骤S12中,所述呼叫逻辑处理器根据接收到的呼叫请求生成呼叫消息,并将所述呼叫消息发送至所述座席逻辑处理器,其中,所述呼叫消息包括呼叫对象;在步骤S13中,所述座席逻辑处理器为所述呼叫消息分配目标座席,所述呼叫逻辑处理器将所述呼叫消息转接至所述目标座席;在步骤S14中,所述呼叫逻辑处理器将接收到的由所述目标座席根据所述呼叫消息确定的呼叫事件转发至所述设备逻辑处理器。在此,以来电后通过座席实现弹屏为例进行说明,当呼叫从外部进入呼叫管理系统的交换机后,呼叫逻辑处理器会收到呼叫进入的消息,并为该消息生成一个新的呼叫对象;呼叫处理逻辑处理器把呼叫消息发送给座席逻辑处理器,反馈至所述设备逻辑处理器,座席逻辑处理器为呼叫消息分配一个目标座席,将该目标座席做登录的分机设备的标识信息(ID)发送给呼叫逻辑处理器,呼叫逻辑处理器将呼叫转接给目标座席的分机,分机振铃,此时呼叫对象对应的呼叫状态为振铃,呼叫逻辑处理器接收到振铃信息后转发给设备逻辑处理器,从而设备逻辑处理器中的与座席绑定的座席客户端通过振铃信息获取来电信息,完成客户信息弹屏。
在本申请一实施例中,所述方法包括:所述设备逻辑处理器维护所述目标座席、所述目标座席使用的设备和座席客户端之间的绑定关系,同时,跟踪设备状态和设备上的呼叫,并将所述呼叫事件发送至与所述目标座席具有绑定关系的座席客户端;所述座席客户端通过所述设备逻辑处理器同步设备的状态和设备上的所有呼叫信息。在此,设备逻辑处理器管理注册到呼叫平台的终端设备,每个终端设备都有唯一的分机号码,设备逻辑处理器中的设备管理逻辑主要包括设备的注册和注销以及设备的呼叫状态、设备与座席的绑定关系等,并从呼叫事件与消息中同步设备的呼叫状态,将呼叫状态通知到与座席绑定的座席客户端。
通过本申请所述的系统和方法,解决了呼叫中心领域座席规模扩展中遇到的单个服务器处理能力的瓶颈和单点失败导致的业务停顿问题。按逻辑划分为不同处理器、同类逻辑处理器共享对象状态数据的方法,解决了分布问题;因为可以分布,就可以通过水平扩展处理器提高并发处理能力,从而可以支持更多的座席;同时由于单个处理器的失败不会影响整体的功能,因此本申请解决了宕机导致的服务暂停可能,从而提高了业务的连续性。水平可扩展性和业务连续性是衡量一个IT处理系统最关键的两个非功能性指标。
除了以上明显的收益,还带来了成本上可观的节省。
以下是普通的云服务器每小时的使用成本,如表1所示:
配置 |
每小时使用单价 |
1CPU/1G内存 |
0.24元/小时 |
2CPU/4G内存 |
0.66元/小时 |
4CPU/8G内存 |
1.32元/小时 |
8CPU/16G内存 |
2.66元/小时 |
16CPU/16G内存 |
3.88元/小时 |
16CPU/32G内存 |
5.40元/小时 |
表1
云计算资源使用成本的80%都是CPU和内存,这里假设,传统技术的系统和本发明的新系统在网络和存储资源占用上没有显著变化。这里对照比较2000和5000座席两种规模下传统技术和本申请的成本差异。2000座席规模需要的云服务器资源和成本,如表2所示:
|
传统技术(非分布)(主备冗余) |
本申请(分布,有冗余) |
忙时 |
16C/32G *2,10.80元小时 |
4C/8G * 5, 6.60元/小时 |
闲时 |
16C/32G *2,10.80元小时 |
4C/8G * 3, 3.96元/小时 |
一天(按一天有10小时忙计算) |
259.2 |
121.44 |
一年(按360天计算) |
93312 |
43718 |
表2
计算公式:成本 =(忙时成本*忙的小时数+闲时成本*闲的小时数)*360天;因此,可以得到,通过本申请所述的系统和方法,节约了53%的计算资源使用成本。
由于传统技术很难做到并发5000以上,只能通过部署两套独立的系统来支持,而本申请可以通过水平扩展处理节点来支持,可以节省的成本就更多了。节约成本主要有以下的三个因素:第一,服务器的成本与CPU和内存数量不是线性关系,而是指数关系,核心集成度高的CPU之成本比多个低核心CPU之和的成本,在核心数相同的情况下,前者要更加高昂。第二个原因,由于传统技术在架构上不能分布,为了提高可用性,防止单个机器失败,只能采用备份的模式,而备份模式下,必然有50%的资源闲置。而分布式采用了4个小规模的配置的机器,总的CPU和内存与一个高配置的等同,但只需要增加一个低配置的机器,就可以冗余备份。目前的高可用理论和实践中一般不需要考虑两个机器同时失败的场景。第三,系统有忙和闲的周期,因为呼叫中心是一个企业的工作系统,以正常上班时间使用为主。那么在闲时,通过软件的设计,可以把至少一半的处理器关闭,释放50%的计算资源。以上的假设就是5台机器里关闭2台。关闭后,云平台就不会计费。而传统的系统,由于单体架构的固有刚性,无法释放计算资源,就不能在忙时和闲时动态管理计算资源。
本申请所述的呼叫管理系统和方法,可以进行水平扩展,具有如下有益效果:1)突破了传统上单个系统5000座席的规模;2)显著提高了业务的连续性;3)显著地降低了运营成本。
此外,本申请实施例还提供了一种计算机可读介质,其上存储有计算机可读指令,所述计算机可读指令可被处理器执行以实现前述一种呼叫管理的方法。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
需要注意的是,本申请可在软件和/或软件与硬件的组合体中被实施,例如,可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中,本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地,本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中,例如,RAM存储器,磁或光驱动器或软磁盘及类似设备。另外,本申请的一些步骤或功能可采用硬件来实现,例如,作为与处理器配合从而执行各个步骤或功能的电路。
另外,本申请的一部分可被应用为计算机程序产品,例如计算机程序指令,当其被计算机执行时,通过该计算机的操作,可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令,可能被存储在固定的或可移动的记录介质中,和/或通过广播或其他信号承载媒体中的数据流而被传输,和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此,根据本申请的一个实施例包括一个装置,该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器,其中,当该计算机程序指令被该处理器执行时,触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。
对于本领域技术人员而言,显然本申请不限于上述示范性实施例的细节,而且在不背离本申请的精神或基本特征的情况下,能够以其他的具体形式实现本申请。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本申请的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外,显然“包括”一词不排除其他单元或步骤,单数不排除复数。第一,第二等词语用来表示名称,而并不表示任何特定的顺序。