作者简介：
沈强
携程旅行网 通信技术中心高级经理
拥有十几年的呼叫中心系统建设和运维管理经验，经历了携程呼叫中心系统架构的多次转型设计，使之从单一系统逐步演进到异地冗灾、异地双活，从单品牌到多平台的融合架构设计。目前负责携程上万座席呼叫中心的产品管理和架构设计工作。
序言
之前，我先拜读了《Google SRE》 这本书的几个章节，我对这些章节中的内容非常认同，特别是基于自动化运维以及故障响应时间的阐述，感同身受。
今天我讲的这个技术实现就是一个非常接地气的案例，很好了诠释了 Google SRE 的理念，下面我会结合携程实际的技术实现方案，进行详细的讲解。
今天演讲分为三块内容：
首先，介绍一下携程呼叫中心系统的整体架构，因为携程主要是以呼叫中心起家，当时呼叫中心占整个业务订单量70% 以上，因此呼叫中心在我们的业务里面，起到非常重要作用。
其次，讲解一下携程呼叫中心异地双活的架构，整个过程中会涉及到各个层面的双活架构设计。
最后，讲解一下座席介入端的异地双活的系统设计。
一、呼叫中心在携程
就像刚才举手的同学不是特别多，大家对呼叫中心这个系统还不是特别了解，因此我先简单介绍一下呼叫中心的基本的架构，由于各个厂家或者说各个公司对于呼叫中心的设计不一样，可能会有一些架构不一样，因此此次基本上以携程的基本架构作为一个模板进行的说明。
对于呼叫中心系统，主要一个系统就是 PBX 系统，这个 PBX ，类似于运营商的语音交换机，只是用于企业端，功能比较简单一点，主要实现语音媒体的处理和呼叫排队。
第二个系统就是 CTI 系统，就是电话和电脑的集成，等于是我们在电脑和电话之间建立的一个中间件，还包括 IVR ，录音等系统，当然有些平台这些系统会从 CTI 中独立出来。
最后一点就是 CRM 系统，当然各个企业业务定义不同，携程的 CRM 是一个订单的业务系统，包括酒店、机票、度假等等。可能在运营商，他们更多是一个客服系统，这里面会有业务差别，但从整体架构上面来说其实都是相似的，以下是架构图。
在这个架构图中，描述了 PBX，CTI 和 CRM 的组网结构和关系图，另外我们增加了远程座席和在家办公，上海的成本越来越高，很多的座席希望回家乡上班，但是没有一个好的工作或者是一个相对合适的平台。对于在家办公而言，大家花在交通上的成本很高，希望能在家办公，这也是借鉴从美国引进的一些成熟理念，因此我们新增这两种座席办公的途径。
前面介绍了一些呼叫中心的架构，下面讲解一下携程呼叫中心的一些高可用架构相关大纪事。
携程呼叫中心成立以来，总共经历了三次大的调整，第一次是2007年公司大楼搬迁，呼叫中心系统也要搬迁到新大楼，由于当时系统硬件的设计限制和成本考虑，无法做到无缝搬迁，所以搬迁过程中我们整个呼叫中心业务中断了两个小时。这两个小时中断从现在来说可能是不可想象的，说明当时我们的高可用架构还不够完善。
第二次调整是2010年，我们在南通建了一个新的大楼，同时我们也按新架构重构了呼叫中心系统，从平台上实现了异地双活设计，并且将中继路由以及其他业务进行模块化的分拆，各模块之间全部通过SIP协议进行连接，每个模块之间再采用异地双活的设计，因此各个模块可以在异地灵活组合搭配，充分体现系统可靠性。
最后当系统正式启用的后，两地系统同时工作，对业务没有任何影响，系统无缝衔接。
最后一次是今年，我们在上半年对座席客户端进行了一个改造，因为原先我们在做设计的时候，平台这边我们都已经做到了全部的异地双活，但是在客户端由于历史的原因，我们的一些分机全部是模拟的线路，模拟的线路如果想异地切换的话，技术上没法实现。
因此我们从2014年进行统一登录平台的建设，经历一年多的一些优化和改进，我们在今年上半年就实现了一个座席端的异地双活的设计。
二、呼叫中心异地双活架构简介
刚才对携程的呼叫中心系统做了一个简短的介绍，下面把呼叫中心异地双活的架构设计做一下简单的描述。
异地双活衡量标准，我们从自己的业务的角度定了两个级别的标准：
区别异地灾备
故障恢复时间
当出现故障时，我们启用备份，但经常出现备份无法正常工作，或者不能完全接替主应用。而双活我们是两个系统实时存活的，切换时，只是负载增加，其他的功能模块都一样。对于故障恢复时间，我们希望故障恢复快速，只有快速恢复，对用户几乎透明或无感知，才是真正的双活。
我们根据这两个概念定义了一个我们的架构分层或者说这个技术实现的一个标准。
针对这两个标准我们将系统分成三个层面进行设计实现：
公网接入层
应用层
座席接入层
公网接入层和运营商线路相关，双活设计原理很简单，基本上都是在运营商端配置，主要涉及以下内容：
话务中继两地接入
智能网平台(可配置三个路由)
按百分比/主叫号码区域
SIP 语音中继
只是对运营商，如果不提出你的一些想法和设计要求的话，他也不一定帮你去做，因为这样对他的成本会高很多。我们当时在上海和南通两地分别找了电信和联通，总共四家运营商。对于运营商我们要求上海和南通分别都有中继接入的，然后通过运营商的智能网平台将我们的话务进行分配。
运营商智能网平台有多个话务分流的策略，可以根据你的需求进行话务的分配：按百分比进行分配，或按照主叫号码归属的区域进行分配。这样企业可以根据自己的业务需求，规划自己的话务分配逻辑设计。
我们考虑到话务费用成本问题，采用了根据主机号码所处的区域进行分布的策略。因为我们不希望上海的话务分配到南通，产生长途费用。
运营商还有一个先进的技术方案，就是SIP中继接入。这个概念和方案其实很早就提出来了，只是运营商考虑技术风险，当时一直在运营商内部使用，没有对外推广。我们和运营商进行一些技术沟通，最终尝试接入SIP中继，在两个机房分别接入了一个SIP 中继群，负载均衡，光纤接入。
达到的效果就是线路快速扩容，无需重新施工，只需后台参数配置即可。线路主备快速切换，无需事先部署备份额外线路资源。如传统的中继接进来，我的话务要切到另外一边去，这个时候如果没有足够的线路资源的话，而话务量还是原先那么多，那就会存在电话呼损。
而如果事先预留资源的话，一直放着没用的，成本比较高。采用光线接入，直接就是百兆接入，资源充足，先期投入也就是新增几根网线，切换也非常方便，而且我们这边部署简单，无须中继网关和中继线路，只须网络交换机进行数据接入即可。这个方案我们当初跟运营商谈判时，估计当时也是第一家运营商正式开通SIP中继的公司。
总体而言，公网接入层除了SIP中继外，其他在我们企业端的设备部署也比较简单，就是两地部署，所有的线路均衡分配到不同的设备上，预防单设备故障。并且都上联到我们南通上海核心交换，由核心系统进行异地调度。
第二层是应用层，其实原理和互联网WEB应用都是相似的，细节就不再展开，唯一需要说明的就是我们的应用层跟我们的核心交换层，他是一个静态配置，就是我们原先就制订好了一个路由策略，本地访问，优先访问本地集群，如果出现故障，可以通过路由到异地的集群去，配置非常简单。
我们的四个核心也是full mapping设计，这四套我们分别部署在两地，两地都是双活的架构，任何一地出现问题，都不影响所有的业务。这个设计我们和Google SRE的介绍的理念一致，并且我们每年都会进行冗灾演练，把核心关掉，或者把集群关掉，进行观察验证。
第三层就是客户端接入层，也是我们项目的实施的重点，主要讲一下三种客户端注册登录方式：
双中心连接
轮询技术
负载均衡
因为呼叫中心他有一个语音线路，一个话机，我们设计的双中心连接的方法，就是我的话机同时接入到两个中心里面去，同时有效，按需切换。另外一个就是轮询技术，访问应用服务器，主系统有问题可以自动访问第二个。最后一个就是负载均衡，这个就不多说了，WEB应用访问。这三个技术其实我们在整个客户端都采用了。
座席端接入异地双活的必要性
下面讲一下座席接入端异地双活的必要性，携程总共有一万多的座席，如果一地系统出现重大故障，业务影响非常大。我们在这方面有很多的经验教训。在2014年，我们运维同事去机房进行巡检，结果由于工作机电源线路短路，又正好触发了电源的设计中一个bug，导致二级开关跳闸，当时我们整个呼叫中心一个大的部门业务全部垮掉了。
虽然我们快速把电源恢复起来，但是有些系统恢复不了，经过排查，发现是一些设备由于异常断电而损坏，导致我们花了很长时间处理这个问题。故障时，系统所在地我们有大量的座席，他们没法进行工作，而在另外一地系统即使我们把当地所有的人员加进去都没法解决人员不足这个问题。
后续把故障的硬件设备排除后，系统恢复，但我们花了将近两个小时，这个业务影响很大，对我们的触动也特别大，如果那个时候座席异地双活能实现，直接登录到异地系统，这个业务影响就会避免掉。
第二个就是业务需求，其实所有的业务需求类似于我们的计划内的系统的一个调整，这方面我们也有一个真实的故事，也是在去年夏天的时候，台风当时特别大，全市学校都停课。
我们大楼的物业说，这个台风可能会造成我们机房这边的漏水，所以决定在台风来的时候，把这个机房全部停电。我们当时所有的设备都在这个机房，我们这边也很头疼，经过协商以后，物业说还是不行，风险太大。
我们这边不得不安排了技术人员去通宵加班，在异地系统新增配置全部的数据，计划让我们的上海的座席登到异地系统上，花了一个通宵才把数据配好。
第二天，由于台风没有预期到来，因此没有实施这个方案，我们配置数据效果也没有验证过是否可靠，而我们花了大量的时间做这些应急处理，如果说当时系统能够登录到异地的话，这些工作我们都可以省下来，而且系统的可靠性也更高。
经历的这几个点，是我们深有感触的一些痛点，因此我们花了很多的精力整改这一套系统，做到客户端的异地双活接入。
