携程：上万坐席呼叫中心异地双活架构及系统设计

《携程：上万坐席呼叫中心异地双活架构及系统设计》要点：
本文介绍了携程：上万坐席呼叫中心异地双活架构及系统设计，希望对您有用。如果有疑问，可以联系我们。

作者简介：

沈强
携程旅行网 ?通信技术中心高级经理
拥有十几年的呼叫中心系统建设和运维管理经验,经历了携程呼叫中心系统架构的多次转型设计,使之从单一系统逐步演进到异地冗灾、异地双活,从单品牌到多平台的融合架构设计.目前负责携程上万座席呼叫中心的产品管理和架构设计工作.

序言

之前,我先拜读了《Google SRE》 这本书的几个章节,我对这些章节中的内容非常认同,特别是基于自动化运维以及故障响应时间的阐述,感同身受.

今天我讲的这个技术实现就是一个非常接地气的案例,很好了诠释了 Google SRE 的理念,下面我会结合携程实际的技术实现方案,进行详细的讲解.

今天演讲分为三块内容：

• 首先,介绍一下携程呼叫中心系统的整体架构,因为携程主要是以呼叫中心起家,当时呼叫中心占整个业务订单量70% 以上,因此呼叫中心在我们的业务里面,起到非常重要作用.
• 其次,讲解一下携程呼叫中心异地双活的架构,整个过程中会涉及到各个层面的双活架构设计.
• 最后,讲解一下座席介入端的异地双活的系统设计.

一、呼叫中心在携程

就像刚才举手的同学不是特别多,大家对呼叫中心这个系统还不是特别了解,因此我先简单介绍一下呼叫中心的基本的架构,由于各个厂家或者说各个公司对于呼叫中心的设计不一样,可能会有一些架构不一样,因此此次基本上以携程的基本架构作为一个模板进行的说明.

对于呼叫中心系统,主要一个系统就是 PBX 系统,这个 PBX,类似于运营商的语音交换机,只是用于企业端,功能比较简单一点,主要实现语音媒体的处理和呼叫排队.

第二个系统就是 CTI 系统,就是电话和电脑的集成,等于是我们在电脑和电话之间建立的一个中间件,还包括 IVR,录音等系统,当然有些平台这些系统会从 CTI 中独立出来.

最后一点就是 CRM 系统,当然各个企业业务定义不同,携程的 CRM 是一个订单的业务系统,包括酒店、机票、度假等等.可能在运营商,他们更多是一个客服系统,这里面会有业务差别,但从整体架构上面来说其实都是相似的,以下是架构图.

在这个架构图中,描述了 PBX,CTI 和 CRM 的组网结构和关系图,另外我们增加了远程座席和在家办公,上海的成本越来越高,很多的座席希望回家乡上班,但是没有一个好的工作或者是一个相对合适的平台.对于在家办公而言,大家花在交通上的成本很高,希望能在家办公,这也是借鉴从美国引进的一些成熟理念,因此我们新增这两种座席办公的途径.

前面介绍了一些呼叫中心的架构,下面讲解一下携程呼叫中心的一些高可用架构相关大纪事.

携程呼叫中心成立以来,总共经历了三次大的调整,第一次是2007年公司大楼搬迁,呼叫中心系统也要搬迁到新大楼,由于当时系统硬件的设计限制和成本考虑,无法做到无缝搬迁,所以搬迁过程中我们整个呼叫中心业务中断了两个小时.这两个小时中断从现在来说可能是不可想象的,说明当时我们的高可用架构还不够完善.

第二次调整是2010年,我们在南通建了一个新的大楼,同时我们也按新架构重构了呼叫中心系统,从平台上实现了异地双活设计,并且将中继路由以及其他业务进行模块化的分拆,各模块之间全部通过SIP协议进行连接,每个模块之间再采用异地双活的设计,因此各个模块可以在异地灵活组合搭配,充分体现系统可靠性.

最后当系统正式启用的后,两地系统同时工作,对业务没有任何影响,系统无缝衔接.

最后一次是今年,我们在上半年对座席客户端进行了一个改造,因为原先我们在做设计的时候,平台这边我们都已经做到了全部的异地双活,但是在客户端由于历史的原因,我们的一些分机全部是模拟的线路,模拟的线路如果想异地切换的话,技术上没法实现.

因此我们从2014年进行统一登录平台的建设,经历一年多的一些优化和改进,我们在今年上半年就实现了一个座席端的异地双活的设计.

二、呼叫中心异地双活架构简介

刚才对携程的呼叫中心系统做了一个简短的介绍,下面把呼叫中心异地双活的架构设计做一下简单的描述.

异地双活衡量标准,我们从自己的业务的角度定了两个级别的标准：

• 区别异地灾备
• 故障恢复时间

当出现故障时,我们启用备份,但经常出现备份无法正常工作,或者不能完全接替主应用.而双活我们是两个系统实时存活的,切换时,只是负载增加,其他的功能模块都一样.对于故障恢复时间,我们希望故障恢复快速,只有快速恢复,对用户几乎透明或无感知,才是真正的双活.

我们根据这两个概念定义了一个我们的架构分层或者说这个技术实现的一个标准.

针对这两个标准我们将系统分成三个层面进行设计实现：

• 公网接入层
• 应用层
• 座席接入层

公网接入层和运营商线路相关,双活设计原理很简单,基本上都是在运营商端配置,主要涉及以下内容：

• 话务中继两地接入
• 智能网平台(可配置三个路由)
• 按百分比/主叫号码区域
• SIP 语音中继

只是对运营商,如果不提出你的一些想法和设计要求的话,他也不一定帮你去做,因为这样对他的成本会高很多.我们当时在上海和南通两地分别找了电信和联通,总共四家运营商.对于运营商我们要求上海和南通分别都有中继接入的,然后通过运营商的智能网平台将我们的话务进行分配.

运营商智能网平台有多个话务分流的策略,可以根据你的需求进行话务的分配：按百分比进行分配,或按照主叫号码归属的区域进行分配.这样企业可以根据自己的业务需求,规划自己的话务分配逻辑设计.

我们考虑到话务费用成本问题,采用了根据主机号码所处的区域进行分布的策略.因为我们不希望上海的话务分配到南通,产生长途费用.

（编辑：ASP站长网）