紧急类呼叫中心系统的冗余架构设计

杨诗华

0 引言

笔者长期从事某紧急类呼叫中心系统建设与运维工作，见证了某紧急类呼叫中心系统的建设及发展，随着笔者所在的紧急类呼叫中心承载越来越多的全市各委办局的联动响应业务，为市民提供快速处警和为民服务，除了受理刑事、治安等案件外,还为群众提供快捷、有效的“急、难、险”综合服务。作为提高响应处置效率的工具，紧急类呼叫中心系统也被要求24小时不间断运转。

紧急类呼叫中心系统故障可能会造成极为严重的后果。减少系统的停机时间，就可以极大地减少产生的损失。在许多应用场合，系统的冗余设计得到广泛应用，它可以有效地避免或减少应用系统的停机时间，保证运行的连续性，消除或减少所造成的各类损失。

冗余通常指通过多重备份来增加系统的可靠性。指重复配置系统的一些部件，当系统发生故障时，冗余配置的部件介入并承担故障部件的工作，由此减少系统的故障时间。

本文旨在通过对某紧急类呼叫中心系统某些环节冗余设计的阐述，描述如何有效提高紧急类呼叫中心系统的可靠性及稳定性。

1 某紧急类呼叫中心系统概况

某紧急类呼叫中心系统负责受理全市紧急类报警电话，并通过系统流转分县局、业务单位和联动单位处置[1]，如图1所示：

图1 紧急类呼叫中心工作流程图

系统实现了从电话接警、报警信息采集、地图辅助定位、接警单处警流转等功能。系统部署的硬件包括排队调度交换机、接警台、处警台和数据、通信、接入应用等服务器。系统按受理台类型分为接警台、班长台、综合处警台、二级处警台等，多层次实现接警单的流转与处置，接警台完成接警单登记后，按照规定流程通过网络将警单传送到有关二级处警台，二级处警台则通过网络反馈处警情况并传送到综合处警台，由其干预、指挥，班长台对接警台实现实时监控。同时作为接警系统辅助功能，系统还具有报警电话定位、多方通话、骚扰电话限制、重复报警关联归并、查询统计、春节模式等功能，确保警情得到快速准确处置。

1.1 某紧急类呼叫中心系统具体实现

某紧急类呼叫中心系统由CTI中间件、消息中间件和通用业务组件组成[2]，如图2所示：

图2 紧急类呼叫中心组件

CTI中间件主要是实现多种设备的接入，包括PBX、传真、录音、IVR、无线等[3]。

消息中间件是面向分布式应用的消息中间件，主要功能是在应用程序之间传送消息。消息中间件提供多种通信方式，同时也可对传送的消息进行监控、管理。

通用业务组件即Objects业务逻辑组件和底层通用组件。即把许多紧急类呼叫中心应用普遍需要的功能抽象成公共的设计，以com组件的方式提供给客户端调用。

从服务构成角度来讲，整个系统由通讯服务、坐席服务、CTI、二级分配服务、IVR、录音等组成[4]。

2 紧急类呼叫中心系统冗余架构分析

纵观整个应用系统各个环节，笔者认为冗余设计分为3个层面，一是硬件设备的双机冗余；二是应用层面的多路径冗余；三是系统整体的双活中心冗余[5]。由于第一和第三层面的冗余架构是较为通用的技术设计，本文只做简单描述，重点对涉及应用层面的应用级冗余涉及进行详细描述。

2.1 硬件设备的双机冗余

硬件设备的双机冗余一般是基于的两台服务器的热备，双机高可用按工作中的切换方式分为：主-备方式（Active-Standby方式）和双主机方式（Active-Active方式），主-备方式即指的是一台服务器处于某种业务的激活状态（即Active状态），另一台服务器处于该业务的备用状态（即Standby状态)。而双主机方式即指两种不同业务分别在两台服务器上互为主备状态（即Active-Standby和Standby-Active状态）。

结合紧急类呼叫中心系统的实际情况，本文中提及的硬件设备的双机冗余是指对关键应用的服务器实行双机热备份，增加接处警能力，提高系统性能，即一台工作主机运行，备份主机对工作主机实时监控和存储数据，一旦工作主机停止工作，备份主机自动接管主机工作（无须人工参与，系统不间断工作），硬件设备的双机冗余的目的在于保证数据不丢失和系统不停机。

2.2 应用层面的多路径冗余

2.2.1 处警冗余路由

紧急类呼叫中心系统的处警指令是由两台并行工作的分配服务器来完成的，曾经出过两次故障是由于两台并行工作的分配服务器的备份算法存在缺陷，导致两台分配服务器都不能正常工作，从而使得接处警指令无法下达到分局及联动单位，影响正常接处警长达4个多小时。虽然该缺陷目前已经得到了修复，但是为了增强系统的可靠性，还是很有必要在原有的处警机制上补充增加处警的冗余路由。

2.2.2 架构设计

在市局指挥中心系统中增加一台二级数据分配服务器及相关软件，区别于原有的消息通信机制，通过数据服务的方式，在二级分配服务器或者通信服务器发送故障时，将警情发送给分局，如图3所示：

图3 实现架构图

“二级数据分配服务”主要用于对全市各个分局指挥中心提供数据分配服务，而在分局增加“二级数据接入服务”，获取处警至该分局警情数据，同时利用最大限度利用分局原有的紧急类呼叫中心系统，实现分局的接处警业务。通过这样的冗余方式，对分局的原有接处警业务基本无影响，且分局可通过原有系统将警情下达到基层所队，分局和基层所队均利用原有的软件进行接处警。处警冗余路由与主路由的区别在于主路由的二级分配服务是基于TCP/IP通信实现的实时消息交互，而处警冗余路由的二级数据分配服务，则是一种定时获取服务的方式，会有秒级的数据延迟。

2.2.3 工作模式

2.2.3.1 正常情况下的工作流程

指挥中心在受理报警电话后，向分局下达处警指令。处警指令信息首先发送到二级分配服务器，通过对处警指令的分析，判断出该指令的目标分局后，二级分配服务器将处警指令信息发送的对应的分局二级接入服务器上。二级接入服务器接到处警指令后，将该处警信息分配到分局接警台。

2.2.3.2 通信故障情况下的工作流程

当二级分配服务器出现故障无法向分局发送处警指令时，系统以数据服务的方式提供处警指令下达渠道。此时，分局二级数据接入服务器从二级数据分配服务器获取接处警数据，而市局指挥中心和分局指挥中心处理过程和正常模式基本一致。

当市局通信服务出现故障导致无法向分局发送处警指令时，市局指挥中心与分局指挥中心的接处警业务数据交换也是通过二级数据分配服务器和二级数据接入服务器交换数据。但与二级分配服务器出现故障不同的地方在于，市局指挥中心接警台需要通过手工刷新接警列表，才能显示接处警业务数据的变化信息。

2.3 实现方式

通在通信服务器或二级分配服务器发生故障时，接警坐席将接处警数据写入数据库中，在这种情况下，通过增加数据分配服务实现市局与分局的数据交换。

2.3.1 增加二级数据分配服务

二级数据分配服务主要功能为二级数据接入服务器提供数据访问接口，允许二级数据接入服务器通过此服务接收和确认市局处警指令和警情信息，并将分局或联动单位的反馈信息提交给市局。

主要功能如下：

提供警情服务接口，允许分局二级数据接入服务通过此接口获取处警至本分局的警情数据

提供处警指令接口，允许分局二级数据接入服务器通过此接口获取分局的中心处警质量

提供反馈接口，允许分局二级数据接入服务器通过此接口提交反馈数据和反馈消息应答

市局业务消息广播，在通信服务器正常的情况下，将分局提交的指令接收确认消息以及反馈消息广播给所有接警台

日志监控，日志记录和跟踪分局接入服务器的数据访问情况

提供管理员切换功能，允许分局二级数据接入服务器通过此服务获取警情数据和提交反馈

2.3.2 增加二级数据接入服务器

二级数据接入服务主要的功能为连接二级数据分配服务，通过访问二级数据分配服务获取分配到本分局的接处警数据，确保不影响分局指挥中心的原有业务流程。

主要功能如下：

通过二级数据分配服务器获取警情数据

通过二级数据分配服务器接收和确认处警指令

通过二级数据分配服务器提交二级反馈信息

连接二级接入服务器，转发二级接入服务器的业务消息，实现分局与市局的接处警业务

2. 3.3 修改中心接警台软件

当通信服务器发生故障时，市局指挥中心与分局指挥中心的数据交换都是基于数据库；而接警台需要获取最新的警情数据、处警接收确认状态和分局反馈信息都需要从数据库中刷新数据。因此中心接警台软件需增加完善刷新列表数据的功能。

2.3.4 离线接、处警设计

在核心服务器发生故障，包括CTI服务器、通信服务器、数据库服务器和二级分配服务器发生故障，但市局指挥中心网络与分局指挥中心网络正常的情况下，中心接警台启动离线接处警模式，允许接警台将处警数据之间发发送给分局。

3.5 架构设计

当接警台处于离线接处警的模式，即电话能分配进来，但无法写入数据库。此时，接警台录入的警情通过点对点的方式，直接发送到指定的分局，分局可以接收和确认处警指令和部分反馈数据；在系统正常运转后，可以通过手工同步工具将分局的反馈数据同步至市局，确保接处警业务数据的一致性。

3 实现方式

离线接处警通过修改中心接警台软件和二级接入服务软件，实现中心接警台直接处警到分局的功能。同时需增加数据同步工具，将故障期间的分局反馈数据同步到市局数据库中。

3.1 修改中心接警台软件

实现离线接处警模式，需要修改接处警软件，允许接警台选择离线接处警模式，在这种模式下，接警员可实现将接警信息采用文件方式存放于本地，并通过预先维护的二级接入通信端口，以点对点的方式处警至分局，并提供本地通信端口，接收来自分局的处警接收和确认消息。

提供中心接警台离线接处警功能，允许接警员选择离线接处警模式

接警台在本地保存接警信息

接警台直接处警到分局

接收分局的处警确认消息

3.2 修改二级接入服务

在离线接处警模式下，接警台直接处警到分局接入服务，需要对二级接入服务进行修改，允许接警台处警到分局。

新增通信服务端口，提供点对点通信方式

动态维护接警台通信端口，允许将处警确认和接收消息反馈给对应的接警台

3.3 修改基础数据维护软件

在离线接处警模式下，接警台直接处警到分局，需要维护分局通信列表，在点对点发送至分局时，需要通过此通信列表，选择对应的通信端口。

提供分局通信端口维护功能模块，允许系统管理员维护分局通信列表

3.4 新增警情同步工具

新增警情同步工具软件，实现将故障期间的分局反馈数据同步到市局。

提供分局数据库配置管理界面

将故障期间的反馈数据同步至市局数据库

同步接处警数据状态

故障恢复后，本地保存的数据自动同步入数据库

4 应用层面多路径冗余限制条件

应用层面的多路径冗余从紧急类呼叫中心系统的不同环节确保了应用的可持续性。处警冗余路由确保了在二级分配服务器或通信服务器异常的时候，市局与分局之间的警情能够正常上传下达；离线接处警设计确保了在市局关键服务器瘫痪、但市局指挥中心网络与分局指挥中心正常时，接警台还能够将录入的警情数据发送到指定的分局。但如果分局局部异常，则还是会造成局部处警指令无法下达，这种情况下，就需要通过分局关键服务器双机及网络冗余等方法规避相应的故障。

5 异地双活中心冗余

按照紧急类呼叫中心系统异地双活中心的架构模式，形成两地接处警席位可以共同开展接处警工作的功能模式，增加双中心之间实时状态同步、单中心发生故障时可以自动迂回到另一中心等功能，从而实现实现双活全冗余。使得任一中心发生故障均不会造成应急联动紧急类呼叫中心系统中断，以此提高紧急类呼叫中心系统的稳定性和健壮性。

异地双活中心交叉布置接处警坐席，即两中心的坐席均可分别接入本中心程控交换机和另一中心程控交换机。在正常情况下，由两个中心的程控交换机分担报警接入，接警员分散在两个中心，各自独立接警，并将各自派单。接警员不论在哪个中心，均可灵活登录两个中心接听、处置警情。若其中一个中心出现无法运转的特殊情况时，可以转移至另中心受理，确保紧急类呼叫中心工作的无缝切换和有序进行。

当然，要实现异地双活中心冗余，需涉及对外接口、设备冗余、冗余设备之间的相互通信与同步、数据库实时同步[6]、网络、运营商话务均衡接入等多个环节的冗余设计，在此就不一一阐述了。

6 结语

笔者所维护的某紧急类呼叫中心系统通过上述3个层面的冗余设计，确保了业务的稳定性及延续性，一定程度上规避了因系统故障导致的紧急类呼叫中心业务中断。当然随着信息化技术发展及对外服务要求的不断提高，系统架构优化还将继续。

[1] 姜彤.城市应急联动平台与应用软件总体架构[J].智能建筑与城市信息,2011,10.

[2] 葛黎晖,公安局指挥中心接处警座席系统的设计与实现[D].上海:上海交通大学,2011.

[3] 胡倩,报警服务行业呼叫中心系统的分析与设计[D].西安:西安电子科技大学,2012.

[4] 梁彬.突发事件应急救助指挥系统的设计与实现[D].西安:西安电子科技大学,2010.

[5] 谢悦平,王新川.计算机系统可靠性问题的研究[J].河北科技大学学报,2005,02.

[6] 陈昌元.基于数据同步的双呼叫中心设计与应用[D].长沙:湖南大学,2010.