*本文系作者特别为CTI论坛所撰写

　　传统自建呼叫中心的资源是独享，其接入的中继线路数量直接决定了它的最大并发通话处理量。其系统结构相对单一，一般只需要在中继线路满负荷工作的情况下，找出系统中的“短板”，针对性的优化，并保障其他服务正常，就能通过压测。

　　租用型呼叫中心实质是集中大量的呼叫中心资源，然后将这些资源虚拟出来给不同的租户独立使用。众多租户使用的是同一套资源，其中必定会有资源竞争、共享等问题。所以租用型呼叫中心的系统结构比传统自建呼叫中心要复杂的多，压力测试自然也就麻烦得多。
　　为了让多租户同时且独立的使用系统，在合力金桥软件的“7x24租用型呼叫中心系统”里面，模块都是严格的按功能来划分的，一个模块就是一种服务，如话务的路由服务、CTI服务、媒体服务等，而模块实例化出来的节点就是服务提供者。每个模块都有许多的实例节点，每种节点都有n+1的备份，任何一个节点出现问题，都能迅速的用其它同类型节点或备用节点来接管它的工作，使故障能迅速的解决；在系统做横向扩展时就是复制这些节点而已。每个租户的具体功能也就分散到了各个模块的各个节点中，从各个模块中取一个或多个节点出来就组成一套完整的呼叫中心。
　　这样的架构设计把本来一个用户独占的资源共享出来给多个用户一起使用，提高了资源的使用率；资源的管理、扩展、备份也比较清晰和简单。但只要是共享，肯定就会有竞争。在呼叫中心里面最主要的竞争就是通话的线路。因为外呼是坐席发起的，坐席的数量相对固定，所以外呼线路的竞争是不太激烈的。而呼入却是客户主导的，一旦某个租户呼入量陡增，它就会抢占其它租户的各种资源。所以不仅要按坐席比例来控制这个租户的呼入，同时还需要保证这个租户所在节点不会超过稳定运行的压力上线。
　　7x24租用呼叫中心有海量的中继线路接入，将这些中继线路的量放到任何一套单独节点中，肯定会让这些节点崩溃。所以在压力测试中，我们测试的不是整个系统最大能承受多大的量，而是要压测出每一套节点所能承受的最大量以及每个节点稳定运行的压力上限。
　　在7x24租用型呼叫中心里，我们主要测试如下几个方面：
　　模拟呼入压测整个平台
　　所有租户的呼入都是走的同一批中继线，系统需要根据被叫号码将呼入路由到对应租户所在的节点去处理。所以整个平台的呼入压测主要是看在所有中继线路在跑满的情况下路由模块是否能正常工作。
　　模拟呼入压测单套节点
　　这一套节点类似于传统自建的呼叫中心，测试方法也和传统自建呼叫中心类似。模拟呼入来压测，找出其中的“短板”节点，针对性的进行优化，直到整套节点所能承受的压力范围达到我们的要求。
　　模拟呼入压测单个节点
　　在一套节点中，每类节点都会有一个或多个。节点的功能类型决定了它的并发处理能力。比如录音模块，其功能比较单一，而媒体处理节点功能比较复杂，对系统的CPU资源要求较高，同样的硬件环境下录音节点能承受多个媒体处理节点的通话量。所以在一套节点里面只会有一个录音节点，而由多个媒体处理节点。
　　我们需要针对每类节点都测试出其处理能力的上限，然后合理的组织这些节点。
　　压测估算带宽资源
　　在合力金桥7x24租用型呼叫中心里，坐席和呼叫中心系统是不在一起的。坐席通过互联网和呼叫中心系统相连接，通过互联网来交互业务数据和通话数据。所以在租用型呼叫中心里面还有一个很重要的资源就是带宽。带宽的支出主要分两部分，一部分是业务数据，一部分是通话数据。压测的目的就是测试出通话的并发情况和坐席在线情况同带宽支出的比例，以便在运营中根据坐席数量来调整平台的带宽。
　　通过上述的测试，得到这些数据之后，再做两方面的防备：

1. 中继呼入的路由节点会根据这个量来做分配，一套节点的量达到临界点之后，就不能再给它分配来电了。

　　作者简介：北京合力金桥软件 互联网业务部 技术总监 蔡质斌
　　毕业于武汉大学，2005年在方正春元负责财政综合业务系统中指标系统的开发。2006-2007年在IBM BBP项目组进行VOIP和SIP软电话方面的开发。2008年开始在合力金桥软件技术责任有限公司担任系统架构师，负责CTI和Saas呼叫中心的架构设计和研发工作。
　　声明:本文为作者特别为CTI论坛所撰写，转载请注明出处！

作者供稿 CTI论坛编辑整理