云呼叫中心大容量高可用平台架构实践

　　开放化的语音平台结合场景化的应用，使得云呼叫中心平台对容量和稳定性提出了更大的要求。如何满足客户弹性业务需求，应对业务时段峰值?下面就以某订餐业务模型为例，探讨下云呼叫中心架构该如何应对？
　　某外卖业务模型

某外卖业务流量图

　　每天中午11:00-12:30，晚上17:00-19:00订餐业务高峰，极不均衡

　　在智能云呼叫中心平台设计之初，我们根据平台客户的业务需求特点，对平台架构设计确认了如下几点原则：

　　1.平台架构应基于开放成熟的云IaaS服务；

　　2.在云端进行架构设计时要保持悲观，假设所有事物都会发生故障。换句话来说，架构需要面向故障的自动化恢复来设计，实施和部署。平台任何模块必须是HA架构，消除单点模块；

　　3.应用云IaaS服务与IDC机房由DX专线组成混合架构云；

　　4.分布式架构，必须非常容易扩容，支持自动弹性伸缩；

　　5.平台中模块之间的关系降低耦合，便于业务的快速演进；

　　6.以业务监控、日志和统计为运营核心构建平台；

　　7.具备跨机房级别的高可用结构；

　　8.完善的完全机制，自我保护与服务降级能力；

　　凭借“云中优势”进行系统组网。

　　基于云平台的架构在组网结构上具备明显的商业优势。体现在几乎为零的启动成本，灵活的资源按需付费模式，快速的扩容上线能力等方面。

　　在技术层面云平台架构也存在明显优势。可实现自动化构建和部署，自动扩展无需人工干预，可将测试持续注入到开发过程各个阶段，实现改进的可预测性。

　　天润融通智能云呼叫中心平台，基于AWS云/阿里云+DX直连IDC组建的混合架构云，既能利用云平台的“云中优势”又能兼容特殊应用让平台的运行上线无缝切换。在网络架构上，将核心机房和落地机房通过专线打通，形成环线。其中任何一点的专线故障都可以通过整体的网络调度，由其他专线或互联网进行切换传送，从而不影响业务的正常运转。

高可用的组网结构图

　　在基础IaaS云服务上构建大容量高可用的系统。

　　在基础IaaS云服务方面，AWS与阿里云差别不大，以下仅以AWS为例说明如何在基础IaaS服务之上构建大容量高可用的系统。

　　目前智能云呼叫中心平台架构基于AWS所提供的3层基础服务：

　AWS云平台组件服务

　　第一层。 基础计算、存储和网络组件，包括EC2，S3，EBS，VPC和DX等等。其中S3服务由AWS提供11个9的持久性，DX专线采用2条互为备份的1G直连保证了网络性能。

　　第二层。高可用的数据库RDS，Cache，SNS和SQS应用组件，支持跨机房的高可用和可灵活扩容。实时处理部分全部使用Rediscache降低数据库压力，大量使用SQS做异步化处理实现削峰填谷。

　　第三层。应用层的ELB负载均衡器，AutoScaling弹性伸缩，以及完善的监控和日志服务。系统各模块首先全部是无状态的，AutoScaling的应用使得通过ELB收集采样来的当前负载和伸缩策略相结合，能够动态调整EC2的实例个数，当业务高峰时启动大量实例承接业务，而低谷时减小实例降低成本。

　　在平台架构设计中必须意识到，故障和故障切换是作为系统架构的一部分存在的。通过AWS/阿里云等云环境提供的容错架构，大大降低了系统运维方面的复杂性，实际上这部分架构是由云环境完成了。与基础硬件故障设计一样，平台软件方面也必须进行故障切换的架构设计，比如：如果一个模块down掉，平台上的应用怎么办？如果接口请求超时或异常怎么处理？如果突发请求超过系统容量又怎么办？

　　我们的经验是基于SOA面向服务的架构理念，构建组件之间的关键是减小组件之间的依赖。如果一个组件挂了没有响应或响应时间过长，系统中其他组件应该能继续工作。组件之间尽量相互独立，通过异步交互方式使用消息队列设计组件间的接口。这样即使某些功能暂时不能用，整个系统仍然继续运行，当出问题的组件恢复后仍然可以使用消息队列中的数据恢复运行状态。

　　基于SOA面向服务的架构理念，我们解耦和拆分构建了大量的生态子系统，系统之间通过API调用构建完整的功能生态链，比如NOSS网管中心，BOSS营帐中心，NMC码号中心，TTS-proxy语音合成中心，SMSC短信平台等等，整体架构如下图所示意:

整体架构图

　　除了整体生态系统层面做了解耦和面向微服务架构的拆分工作，智能云呼叫中心核心交换平台也进行了大量微模块拆分。共计拆分了25个子系统，其中主要的子系统如下：