云通讯业务如何做架构建设（以云之讯为例）

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

为解答大家的困惑，云之讯首席技术官贾俊杰分享了《云通讯业务的架构实践》，他以云之讯的架构实践为例，详细解析了云之讯的架构演进逻辑以及未来的架构建设重点，希望借此给大家一点启发。

云之讯架构演进的两个过程

云通讯最核心的价值就是将传统的通讯能力进行互联网化，通过标本的接口开方嵌入到各种移动应用中去，来解决移动开发者和中小企业在通讯能力中遇到的各种问题。云之讯从 2014 年开始做云通讯业务，并将自己定位为一个能力最丰富的云通讯的供应商。众所周知，通讯领域的内容非常多样，包括短信、语音以及实时的互联网音视频，还有移动互联网的流量业务等。基于这点考虑，云之讯支持全量式的通讯能力的开放，是一站式的融合通讯平台。同时，云之讯也是成长最快的云通讯 PaaS 平台，成立仅两年，注册企业就近 10 万，还有数千家付费客户。

那云之讯是如何做架构建设的呢？考虑到云通讯行业的背景和业务特点，以及公司的定位和快速发展的需求，云之讯的架构演进主要有两个过程：一是先异化再同化；二是先从集中化的服务再到分布式服务。

架构演进逻辑 1：先异化再同化

异化还是同化，关键在于从哪个角度看

异化，更多地是从业务需求上面看，它更适用于创业公司。对于云通讯这类企业来讲，他们通常都有多个业务，而异化的优势就是能够快速地构建业务，降低多种业务之间在开发过程中的一些耦合性，并且能够快速地响应产品需求的变化，同时在产品需求变化的过程中，不会造成太多耦合性或关键性的影响。当然，这种方式也存在一些劣势，主要表现在人力成本和运维成本比较高，但是具体高多少，还得根据业务的类型，以及各个业务之间的耦合性还有相似性来决定。

同化更多是从底层往上看，即怎么搭建一些公共的平台，通过公共的平台适应业务的发展，它更适用于有一定规模的公司，而且它的产品需求以及业务的需求相对稳定，这样在同化的过程中就不会有太多需求的变化而导致价格的变化。按同化的方式去走，架构会相对合理，它的部署和维护成本也相对比较低，但也会引起一些多业务之间耦合的问题。

不同的业务形态和公司定位会导致不同的选择

选择异化还是同化，主要在于是从业务需求上看还是从底层平台建设以及公司内部的组织上去看，不同的业务形态以及不同的公司定位，选择也会不一样。

** 技术架构决定公司的组织形式、**组织关系

技术架构非常重要，它决定了整个公司的组织架构，组织的形式，以及不同组织之间沟通的方式和组织之间的关系。在实际工作中，我们经常会遇到在通讯系统整合过程中会有一些变革，比如有一些部门的合并或产品的合并拆解问题，但我们如何判断整个团队能不能合并到一块去或怎么合并到一块去呢？

曾在华为工作的贾俊杰就遇到过这样的问题，当时，他们的出发点就是先由架构师去做两个产品之间的技术架构分析。这个架构分析决定了这两个产品的架构能不能融合，以及怎样去融合，然后再决定这两个组织能不能合并或怎么去合并，以及后续怎么来支撑新的产品形态。而这其实就是技术架构对组织形式的一些影响。

做够用的架构，而不是做完美的架构

平台是演进出来的，而不是构建出来的。因此，在架构考虑的时候，我们采取的是做够用的架构，而不是做完美的架构。但是我们经常会碰到这样的开发人员，他认为公司原来的架构不够好，然后自己想了一个很好的架构，去跟老板讲，结果老板不做，这让他觉得公司技术没有发展，自己的技术积累也没有发现。其实造成这种冲突的原因，是开发人员和公司的思考维度不同。从公司层面，或者说从老板层面，可能更多的关注是这个架构对于业务的影响，它对业务到底有没有用，另外做这个架构，需要投入多大的人力和周期。成本的因素决定了公司到底要不要做，能不能做。而开发人员更多的是想，这个技术的架构是有多么完善，多么好。

云之讯业务架构从垂直分层到水平分层

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

(点击放大图像)

多业务垂直分层阶段

起初，云之讯以音视频通话业务为主，所以一开始做的是音视频通话产品体系，后面的短信流量也是采取垂直分层的形式去开发的。相当于每个不同的业务，都是有单独自己的一些服务的体系。独立的服务体系让每个业务都能很快地开发出来，推向市场，而且不会对原有的业务造成太多的耦合和影响。一个新产品在开发阶段，在推出市场阶段，和已经稳定的产品不一样，新产品会有更多需求的变化和不确定性，产品迭代的周期也会不一样。业务的独立可以保证我们每个业务都能快速上线，但它也造成了一些问题。因为云之讯的很多业务具有很大的相似性，如点对点的音视频业务和会议业务，短信业务和实时语音视频业务，而服务的体系、计费的逻辑、运营的平台，都是单独的，所以，我们在实际的部署和运维过程中遇到了很多问题，浪费了很多人力以及硬件成本。

(点击放大图像)

多业务水平分层阶段

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

架构演进逻辑 2：先集中化服务再分布式服务

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

未来架构建设重点：智能化架构建设

云之讯后续的构建重点，是进行智能化的架构建设。不同的业务对于智能化的处理要求都比较高，比如说短信、语音都存在非常复杂的调度机制，这种调度的机制依赖于很多历史的数据，如历史的成功率，历史的通话记录等，我们需要根据这些数据去做详细的分析。后面，我们将会把所有的数据抽取出来，包括历史的通话记录、实时文本的内容、号码标记信息等，然后去做实时地数据分析，通过一些语音识别和语音理解技术，并结合实施分析系统、离线分析系统，去进行综合性的分析。同时，云之讯也会做更多智能化的通讯业务，比如现在正在做的安全管控业务，我们会根据用户的一些历史呼叫记录以及成功率的情况去分析是不是存在骚扰的问题，做一些防骚扰的标记。另外，在资源匹配上面，我们也会根据智能分析，去了解客户需要哪种类型的资源，考虑成本和短信到达率因素，综合分析和匹配，然后找到与用户最匹配的需求。

以上就是云之讯在架构建设方面的一些考虑，希望能对各位有所帮助。但大家不一定要按照云之讯的步骤来进行，而是应该选择最适合公司定位及业务发展的架构进行建设。