云通讯业务的架构演进实践

互联网的繁荣促进了云通讯的飞速发展，它的各种功能及应用已经遍布网络。但由于通讯领域的多样性和复杂性，行业从业者在进行云通讯业务的架构建设时也会遇到一些问题。

云之讯从 2014 年开始做云通讯业务，通过这几年的实践，它在对外提供分布式的呼叫中心的资源与平台支持伤，在云通讯业务的架构演进逻辑以及未来的架构建设上，都具有非常宝贵的经验积累。我们希望借以下两篇文章的集锦传播，将云之讯在云通讯技术探索之路上所走过的“坑”及其在这些“坑”上所摸索出的最新解决方案，无条件的分享给 InfoQ 的朋友们；也希望身处通讯行业或专注于云服务架构工作的你，能从此次分享中收获最佳实践、最佳案例。

云通讯业务如何做架构建设

云通讯最核心的价值就是将传统的通讯能力进行互联网化，通过标本的接口开方嵌入到各种移动应用中去，来解决移动开发者和中小企业在通讯能力中遇到的各种问题。考虑到云通讯行业的背景和业务特点，以及公司的定位和快速发展的需求，云之讯的架构演进主要有两个过程：一是先异化再同化；二是先从集中化的服务再到分布式服务。

异化还是同化，关键在于从哪个角度看，同时，不同的业务形态和公司定位会导致不同的选择。

先集中化服务再分布式服务主要是因为云通讯业务有几个特点：1、实时性要求高，如音视频业务的实时性要求一般都是在十毫秒级的，丢包率也在 5% 以内，可靠性要求高；2、通讯能力差异化，国内有很多不同的运营商，它们的能力以及接口形式是有差异的，这就导致在开展云通讯业务过程中会存在一个全国性调度的问题，需要具备全国性调度能力。

在实践中，云之讯的架构建设也不是一蹴而就的，也经历了从多业务垂直分层到多业务水平分层的过渡演变。

多业务水平分层阶段

随着公司业务地发展，云之讯逐渐走向了一个同化的过程，公司通过水平分层的考虑把公共化的一些组建抽取出来，做成集群。比如，我们把调度层的一些能力抽出来做一些集群，接入集群就可以接入各种协议；对于音视频介入也是一样的，我们做成路由的集群，这个集群能满足各种音视频的需要。在一些公共的内容上我们也会抽出一些公共的组建，比如我们把所有涉及到一些业务的健全，像用户管理、计费、录音、语音识别这些能力，做成一种中间件，通过这种方式把不同形态的业务和公共平台分离开。另外还有运营、日志分析、安全运营等，我们也会做成公共的统一的运营平台，以支撑所有不同类型的业务去发展。

阅读原文请点击

如何突破呼叫中心的关键技术

单一语音平台是呼叫中心的过去需求，随着融合通讯与 IP 语音的发展，客户越来越需要全媒体的呼叫中心，其包含传统的语音、APP 网页以及高终端的浏览器。随着行业技术和客户技术的发展，未来的呼叫中心将是一个全用户的平台，它构建在云计算上，并融合物联网和互联网发展成一全业务的呼叫平台。

云之讯的呼叫中心建立了一个分布式的运营中心，其接到最近网关，在长途传输过程中，任何网络抖动造成的变量变差问题，都可以在靠近用户、网关的地方部署云之讯的媒体网关，消除抖动带来的影响。

随着行业技术和客户技术的发展，云之讯认为，未来的呼叫中心将是一个全用户的平台，它构建在云计算上，并融合物联网和互联网发展成一全业务的呼叫平台。

互联网模式下呼叫中心的部署和结构

新一代呼叫中心有两大设计理念，一是信令与媒体分离，二是业务与控制分离。

信令与媒体分离可解决以下技术难题：

• 单独提升信令可靠性，重点节点做到主备切换，通过集群部署和分布式部署预防异地容灾；
• 媒体节点集群部署，故障可自动切换；
• 分布式部署保证了机房的故障自动切换到异地。

而业务与控制分离解决的难题显而易见：

• 根据不同用户的不同业务，灵活部署和开展业务，在标准的接口基础上构建不同的应用，方便客户接入。
• 业务逻辑各自独立部署，防止故障蔓延。

阅读原文请点击