运用云计算技术实现多业务云的架构设计

申请免费试用、咨询电话：400-8352-114

一、计算云的设计　　

1.1设计指导思想一

对于业务的部署关系到计算资源的分配和调度.相对来说比较复杂，而存储资源本身的分配和调度也比较复杂，但计算和存储之间不管脚本或API是否是标准接口，均可以通过脚本或API来关联。因此，进行多业务云架构设计可以把计算资源和存储资源分开考虑，计算云和存储云的逻辑架构如图1所示。

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

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

1.2设计指导思想二

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

图2 多业务云的总体架构

图2所示是融合WAP网关、彩信、短信等业务的多业务云的总体架构。

要想能够很好地借助云技术实现应用，首先必须尽量多地实现业务和逻辑的分离。引入分布式数据库和分布式文件系统后，需要更进一步考虑应用各模块的独立性和并发性。当然，如果应用愿意改变原来使用标准SQL进行数据查询的习惯，则分布式物理数据库并不是必须包括的部分。基于将数据进行恰当的组织并对文件和记录做尽量多的索引，再加上内存库的配合，物理数据库完全可以被替代。

其次，作为业务云的个体，单一产品需要做相应的改变。其产品内部的实现需要更改竖井式的系统架构为水平式。思路分为两个方面，一是进程拆分，除了将业务流程拆分成多个超线程外，还包括将某一功能的单一线程扩充成多个，实现并行计算；二是以一定量的业务能力作为调度单元，通过增加业务调度中心实现业务的调度，以业务处理能力的分布来屏蔽业务流程集巾带来的紧耦合。

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

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

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

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

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