随着云计算的升温，电信运营商也明确提出要积极推进云计算在数据业务上的落地与实施。那么如何将电信业务根据云计算技术的特点进行架构设计才是合适的呢?首先,我们分析下电信行业的云计算其定位是什么，是为了更好地支持业务定制，还是为了节省资源和增加灵活度，还是希望对外出租资源？基于业务产品自身的特点来看，不同产品的忙闲时不一样，不同时段的资源需求波动大，比如短信产品节假日比平时高峰时繁忙5~10倍。所以本文从如何节约资源和增加灵活度的角度来探讨下多业务云的架构设计。

同时，业务系统的组成包括计算资源、存储资源、网络资源、接入资源等多种资源，在业务云的场景下，所有的这些资源，需要可以通过线性叠加而增加其资源量，从而线性地提升系统的处理能力。同时，系统也应具备高可配置性、高性能、动态可伸缩的特性。本文主要从计算和存储两个方面来考虑如何架构多业务云。

一、计算云的设计

设计指导思想一：对于业务的部署关系到计算资源的分配和调度，这个相对来说比较复杂；而存储资源本身的分配和调度也比较复杂，但计算和存储之间可以通过脚本或API来关联，不管脚本或API是否是标准接口。所以，简单起见，进行多业务云架构设计时可以把计算资源和存储资源分开考虑，如图1所示：

图1计算云和存储云的逻辑架构

计算云中，业务处理是关键模块，需要具备快速部署、动态加载、灵活伸缩、在线扩容等特点，但实际上业务处理只是执行者，管理中心和调度中心才是计算云的真正核心。管理中心主要负责设备管理、业务管理、在线升级管理、在线扩容管理、调度策略管理等功能，调度中心则需要根据系统CPU、内存、磁盘空间、话务量等资源情况在一定的控制策略下进行计算能力、存储能力的调度，如果说云计算中的资源可以是公共的，调度中心和管理中心则一定是私有的，这也是真正体现设备提供厂家技术水平和考验设备稳定性的关键点。所以这两部分一定要反复斟酌，充分考虑设备性能、配置灵活度、策略响应速度、系统安全性等多个方面，逻辑上管理中心和调度中心是两个不同的功能实体，物理上可以合设。

设计指导思想二：语音类业务对实时性要求非常高，计算资源集中建设后需要解决网络传输带宽、处理流程增加等方面带来的影响，对业务本身提出了更高的要求；而数据类业务相对来说更接近互联网业务，其设备利用既不均衡也不充分，所以对云计算技术更加渴望，这也符合运营商将多业务云分阶段实现时首先想到数据业务的思路。

如下是融合WAP网关、彩信、短信等业务的一朵多业务云的总体架构：

图2多业务云的总体架构

首先，应用要想能很好地借助云技术，必须尽量多地实现业务和逻辑的分离。引入分布式数据库和分布式文件系统后，也需要更进一步考虑应用各模块的独立性和并发性。当然，如果应用愿意改变原来使用标准SQL做数据查询的习惯，则分布式物理数据库并不是必须包括的部分，基于将数据进行恰当的组织并对文件和记录做尽量多的索引，再加上内存库的配合，物理数据库完全可以被替代。
    其次，作为业务云的个体，单一产品需要做相应的改变。其产品内部实现，需要更改竖井式的系统架构为水平式，这里有两个思路：1）进程拆分，除了将业务流程拆分成多个超线程外，还包括将实现某一功能的单一线程扩充成多个，实现并行计算；2）以一定量的业务能力作为调度单元，通过增加业务调度中心实现业务的调度，以业务处理能力的分布来屏蔽业务流程集中带来的紧耦合。

再次，传统的设计思路是尽量提升单台设备的处理能力，通常用双机模式来保障系统的稳定性，即便是后来的集群技术，也希望单机处理能力高以减少集群节点数量。

如果借鉴云计算技术来做设计，那我们就要主动考虑如何用多台低端设备并行起来实现我们的业务，并且是在每个层面都应当考虑众多处理节点的横向可缩放性，而不是一个单独处理节点的效率。这样我们的系统规模就能快速地缩小和放大。

最后，多业务总体架构图中也考虑到了虚拟化的应用，因为虚拟化技术能有效降低程序跨平台的需求，也能提升系统的快速部署能力。为实现计算资源的弹性和无限镜像，通过将计算资源虚拟化，程序员不用再关心它们是如何被复用和共享的。

虚拟化技术将物理资源转化为便于切分的资源池，符合云计算的基本条件；同时虚拟化给资源以动态调配的能力，符合云计算按需分配的要求。对于X86平台来说常见的虚拟化有如下三种方式：全虚拟化、半虚拟化、硬件辅助虚拟化。我们在做架构设计时同样要考虑清楚系统将依托于哪种虚拟化方式。比如亚马逊的 EC2允许用户控制从内核到应用程序的几乎所有的软件栈，但这种底层适用性使亚马逊很难提供自动的可扩展性和容错性，因为与语义相关的复制和其他状态管理问题是高度依赖于应用的。再比如谷歌的AppEngine是专门针对传统的Web应用程序的，使得其应用程序结构能够清楚地分为无状态的计算层和有状态的存储层，其自动缩放和高可用性机制都很方便。

然而以下两种情形下，并不一定必须用到虚拟化技术：对外出租的是应用，而不是计算云部分，且该出租的应用相对比较专业；容量超过单台物理设备的处理能力，且应用本身通过硬件的简单堆叠就能实现。

二、存储云的设计

构建存储云时，同样要考虑好预期，希望能象磁阵一样对外提供标准存储接口还是希望能象数据库一样对外提供标准SQL？简单说这两者的区别就在于存储云是否包含分布式数据库。基于本文开始时的分析，现阶段应用仍由运营商提供，对于应用的二次开发也是由专业人员完成，所以目前只需要提供标准存储接口就足够了，更深入或更专业的功能由应用自行考虑。

对于电信业务来说，最简单而且也最容易想到的借鉴云计算并行处理技术的就是对日志的处理。日志的入库和查询具备一个写多个读的特点，非常适合用分布式文件系统+MapReduce 技术来实现。而统计报表由于统计源的多样性、统计数据跟时间结合紧密、报表的定制化等特点，当前阶段并不适合用云计算来实现。
对于日志入库和查询，可以依据如下流程图所示来进行设计。

特点是采用开源的MapReduce技术，其框架由TaskMgr和TaskJob组成，TaskMgr由主备双机构成，主要作用是调度各TaskJob的任务执行；TaskJob接受TaskMgr的管理，获取任务，进行任务分解、执行以及最后的聚集执行。

对于存储而言，通常一个文件由多个Chunk来存放，每个Chunk按64kB的大小分成块。重点考虑下数据的一致性，每个块有32位的校验和 ，校验和在数据写入CHUNKSEVER时，由CHUNKSERVER计算出校验和，与数据分别存放。当读数据时，CHUNKSERVER检查数据和校验和，校验错误，则通知应用和MASTER，从其他CHUNKSERVER获取数据（校验可在CLIENT端完成），并完成副本的重新创建。当主 MASTER的元数据更改后，需要及时同步到备MASTER，实现双机备份，MASTER根据新的日志文件文件大小，对元数据进行备份，从内存中倒入本地硬盘或（copy on write技术），形成检查点。对于元数据的更改，MASTER都会产生日志文件，在硬盘进行保存 。这样，当系统崩溃后，MASTER可以根据备份元数据和检查点后的日志文件，对元数据进行快速恢复。