分布式服务架构

分布式服务架构（精选8篇）

分布式服务架构 第1篇

经过近年的探索发展, 中国网络游戏产业已经进入一个平稳较快发展的新阶段。2008年, 我国网络游戏出版产业实现销售收入183亿元。在全球经济危机的严重冲击下, 网络游戏产值同比呈现出逆势增长的势头。毫无疑问, 网络游戏已经构成了IT行业中新兴的利润增长点。巨大的市场需求吸引了国家和社会的极大关注, 越来越多的专业游戏开发商介入其中。由于各种的原因, 我国的游戏产业起步较晚, 目前尚处于快速发展阶段, 许多技术尚不成熟。随着网络游戏玩家的日益增多, 网络游戏服务器端承受着严峻的性能考验和负载压力。为了提供良好的服务品质, 网络游戏服务器端的设计显得尤其重要。进行游戏服务器端网络通信架构以及关键技术的研究, 对于游戏产业的发展和游戏的开发都有积极的意义。

1 MMORPG游戏服务器

大型多人在线角色扮演游戏 (MMORPG) 是在当前网络游戏中的主流游戏类型。由于要支持数以万计乃至数十万甚至上百万玩家的同时在线, 同时还要处理玩家的战斗、场景地图、角色升级等游戏业务逻辑, 以及世界聊天、组队等玩家之间的互动交流, 为玩家提供丰富的交互体验及流畅的游戏体验。相对于休闲类网游来说, MMORPG本身游戏设计方面的特性就决定其对游戏服务器要求更高。要想达到以上要求, 靠单一的服务器是不可能完成的, 需要将整个游戏服务划分为多个模块单元分散到多台分布式服务器去协同处理, 通常称之为服务器组。要想达到优秀的性能, 除了硬件上的要求外, 合理的服务器架构是一款MMORPG服务器组成败的关键。通常, 服务器组架构的主要评价标准有:

(1) 稳定性

稳定性是一款MMORPG服务器组最基本也是最重要的要求。为人数众多的游戏玩家提供24小时不间断的、稳定的游戏服务对服务器的硬件及软件设计方面提出了严峻的挑战。服务器架构的不合理将可能导致服务器卡机、崩溃、数据丢失等严重问题, 直接造成游戏玩家的流失。

(2) 高效性

服务器组的工作效率主要表现为服务器系统吞吐能力的大小。目前, 单台游戏服务器一般能承受2000至5000千人同时进行游戏。一个硬件配置相同的服务器区组, 对于某些游戏可以同时支持5万人在线, 对于另一些游戏却只能支持2万人同时在线, 这就是服务器架构不同造成的效率上的差异。

(3) 可扩展性

可扩展性是衡量一个服务器组架构优劣的一个重要指标。游戏的变化日新月异, 游戏内容也会经常更新, 这均要求游戏服务器能方便地扩展以适应新的游戏要求。例如, 随着一个区组玩家人数的增多, 能否通过增加某些服务器后进行简单的配置即能实现快速扩容?游戏类型从收费转为免费后能否方便地使用商城消费服务器取代计时收费服务器?这些就是对服务器组扩展性的要求。

(4) 可开发性

服务器的架构设计不仅要考虑系统运行时的效率, 也要考虑开发时的工作效率, 这需要综合衡量系统开发人员的能力、架构设计的复杂度、各个模块的耦合度等, 使各个开发人员能相互并行地、协同地工作但又不至于相互依赖。架构设计者必须很好地把握需求及工作细分的粒度, 以保证开发人员以最适合自己的方式开发出最适合自己的系统。

(5) 可维护性

从运营的角度来讲, 服务器的可维护性至关重要。服务器必须提供便利的方式对游戏进行管理和维护。如果一次系统数据备份都要耗费大量人力物力, 如果一次普通的游戏更新就要停机两三天, 那么这个服务器的架构是难以得到运营商的认可的。

2 设计方案

2.1 设计目标

(1) 稳定。服务器组内的各服务器均能长时间稳定、高效地运行, 基本不会出现服务器异常崩溃的情况。各服务器间通信顺畅、游戏逻辑服务器间资源及玩家负载均衡。

(2) 可扩展。服务器组能方便扩展, 易引入新的功能模块, 应对玩家人数的增长只需简单增加游戏逻辑服务器即可完成。

(3) 低耦合。各个主要功能均抽象为一个模块, 并且不依赖于具体实现, 分别由独立的服务器运行, 尽量做到低耦合, 以应对底层实现的变化。

2.2 拓扑结构

如图1所示, 整个服务器组由一台AAA服务器 (AAA Server) 、一台控制服务器 (Control Server) 、一台数据库服务器 (DB Server) 、一台聊天服务器 (Chat Server) 、一台支持服务器 (Support Server) 及若干游戏逻辑服务器 (Game Server) 组成。

2.3 主要功能模块说明

2.3.1 AAA服务器

由于网络游戏的账号授权等工作比较重要, 因此将该功能模块运行在一个独立服务器上, 称之为AAA服务器。类似于其他网络通信中的AAA服务器, 它用于处理玩家登录时的账号验证、授权及登记工作。该服务器直接与玩家的客户端打交道, 并在必要的时候向控制服务器请求所需的信息。

2.3.2 控制服务器

服务器组的控制中心, 它记录了各个服务器的网络通信地址、游戏逻辑服务器间的资源分布及玩家承载情况等。控制服务器主要用于保障各个服务器间的正常通信, 以及游戏逻辑服务器间的资源及玩家负载平衡。

2.3.3 游戏逻辑服务器

游戏逻辑服务器是整个游戏服务器的核心, 它为玩家提供具体的游戏逻辑, 如玩家升级、场景地图、战斗逻辑等。玩家登录后一般直接同一个游戏逻辑服务器打交道。根据区组玩家人数的多少, 游戏服务器一般由多台拥有独立逻辑功能的服务器组成。因此, 简单增加游戏逻辑服务器的数量即可有效解决玩家人数增长的压力。

2.3.4 数据库服务器

考虑到玩家数据的重要性, 数据库服务被抽象为DBA模块在单独的服务器上进行运作。DBA提供统一的接口供游戏逻辑服务器存取玩家数据, 而不用考虑数据库底层的具体实现。具体的数据库系统可以使用Oracle、My SQL、Sql Server等, 并且可以做到替换方便。

2.3.5 聊天服务器

MMORPG游戏具有交互性强的特点, 因此在各个玩家间会传递大量的交互数据, 如果这些数据均由游戏逻辑服务器来处理, 势必会严重影响游戏逻辑服务器的效率。因此, 通常由单独的服务器服务来处理玩家的交互工作, 我们称之为聊天服务器。

2.3.6 游戏支持服务器

游戏支持服务器主要提供一些辅助性的游戏支持服务, 如GM功能等。

3 服务器组的工作

整个服务器组构成了一个完整的游戏服务提供者, 区组内的各个服务器需要协同工作才能提供完备的游戏服务。

3.1 服务器组的启动

服务器组启动时控制服务器最先启动, 其次是除了游戏逻辑服务器外的其他服务器依次启动。由于游戏逻辑服务器有多台, 并且启动时需要创建各自需要承载的资源, 因此启动过程较为复杂些, 具体如下:

(1) 加载并启动逻辑服务功能模块;

(2) 向控制服务器请求需要在本服务器上创建的资源信息;

(3) 尝试创建所有资源直至成功;

(4) 通知控制服务器本服务器启动成功。

当所有游戏逻辑服务器启动成功后, 控制服务器通知AAA服务器所有准备工作已经完成, 可以允许玩家登录。

3.2 玩家登陆流程

图2描述了玩家登录时服务器组的处理流程:

3.3 游戏逻辑服务器之间的通信

在一个服务器区组中, 由于玩家及资源均分布在不同的游戏逻辑服务器上, 因此, 游戏逻辑服务器间的互访问是很频繁的。使用类似于ARP协议的网络访问模型, 可以极大提高游戏逻辑服务器间的访问效率:

(1) 每个游戏逻辑服务器均向控制服务器注册自己的网络地址 (IP及端口) 。

(2) 每个游戏逻辑服务器均缓存下最近访问过的其他游戏逻辑服务器的网络地址。

(3) 访问其他游戏逻辑服务器时, 先通过缓存查找, 查找不到时向控制服务器请求, 并在缓存中记录下该地址。

(4) 缓存的地址超过一定的时间间隔后清空, 以保证缓存的地址信息真实有效。

4 结束语

本MMORPG服务器组模型已经在某网络游戏中得到应用, 并且取得了良好效果。在一个配置10台游戏逻辑服务器的区组中, 可以支持约3~4万人同时在线。由于各主要的功能模块均独立运行在不同的服务器上, 使得各服务器负荷较低, 保证了运行时效率, 同时也使得整个服务器组更稳定、更易扩展。

参考文献

[1]贺冯政.网络游戏服务器通信架构及关键技术研究[D].成都:电子科技大学, 2008.

[2]吴拥民.MMORPG服务器软件体系结构研究——非形式化构造[J].计算机工程与应用, 2006 (32) .

[3]吴拥民, 徐戈.游戏子系统的模块化设计[J].福建电脑, 2005 (10) .

[4]吴拥民, 陈宏展.MMORPG服务器软件体系结构研究——构造模型的演化[J].昆明理工大学学报 (理工版) , 2008 (6) .

[5]phoenixsh.高效网游服务器实现探讨[EB/OL].http://blog.csdn.net/phoenixsh.

[6]黄庆荣.分布式网络模型的研究及其在开发TroBus中的应用[D].福州:福州大学, 2003.

[7]徐晓飞.基于软硬件协同的机群互连系统通信协议的研究[D].西安:西北工业大学, 2004.

分布式缓存GemFire架构介绍 第2篇

5.1缓存事务

每个事务都有其私有的工作区域。事务开始时，数据将被拷贝到私有区域，直到事务提交。若提交时没有冲突，则数据从私有区域拷贝回原区域。这样事务就可以并发地修改缓存了。

分布式服务架构 第3篇

随着多媒体技术和网络技术的飞速发展,基于软件化的手段可实现分布式环境下多点间的语音通信。但在大规模多人实时通讯系统中,由于说话人所处环境不同、设备不同、网络条件不同,采集的语音质量也存在较大差别,影响了实时通讯的效果,存在较大程度的语音失真、延迟等现象。针对该问题,本文综合运用声音处理和网络通信技术,基于客户机/服务器(Client/Server,C/S)的架构构建了一套语音通信系统,利用Kafka和Storm搭建大规模消息分发和实时数据流处理系统,并利用网络通信技术实现了语音的打包、传输与解包。同时,针对冗余的语音数据将造成网络负担的问题,以及时延、抖动和丢包等问题给出具体的解决办法,有效降低语音失真、延迟等问题。

1 分布式云服务平台架构设计概述

1.1 分布式云服务平台架构设计简介

云计算是以服务概念为主的新型计算方式,利用现有的强大网络、计算和存储资源提供计算、存储和平台服务,并具有良好的可扩充性和稳定性。当前,有大量的应用直接在物理机器构建的系统,比如分布式系统,这类系统通常按最大的业务量来架建,存在非常大的资源浪费。

云计算是基于分布式技术和网格技术构建的,因此非常适合分布式应用系统在其上运行。分布式系统对节点的动态调整是自动适应的,非常适合在云计算环境下部署,动态地使用云平台提供的虚拟资源,使应用系统可以适合不同时期计算需求,最大化资源利用。应用系统在云计算环境下部署需要确保系统平稳运行并能随业务量动态调整。

1.2 分布式云服务安全架构发展趋势

尽管在云计算环境中已经有一定的监控能力,但这类监控平台不能识别业务的真实需求。一套完整的应用于云计算环境下的基于分布式应用系统的监控平台,用于捕获分布式应用节点的资源利用情况和负载能力,辅以人工配置策略,实现动态调度云计算资源,使用应用充分利用云计算环境的弹性计算能力,同时该系统还监控节点系统运行状态和应用状态,对应用系统运行时异常有主动告警的能力,全面监护,实现无人值守的云端部署。监控平台采用Java构造,以实现跨平台监控能力,该监控平台通过配置正则表达式实现对应用审计信息进行监控,全面监控应用节点。监控中心通过JDBM框架实现数据快速统计,以监控节点异常情况,并通过对监控数据平滑,辅以人工神经网络以准确判断应用系统是否需要对节点数量进行调整。

整个平台框架,实现了对分布式应用系统的全面监控,并实现告警输出,同时实现了可自调节反馈的机制,与云计算环境很好的融合,为分布式应用系统在云计算环境下部署提供了一种非介入方法。该监控平台利用一个二维平滑矩阵将监控数据进行有效的平滑,再经过人工神经网络以最有效的方式实现特殊应用系统的复杂环境,并与人工制定的策略形成反馈,不断提升整个系统云端资源的利用率。

近年来,随着基于网络的语音通讯需求的不断提升,基于分布式云服务平台架构的语音实时通讯系统应用该监控平台,验证了平台的设计思想,并对应用环境和运行效果进行展示,展示了云计算环境下应用监控平台后动态调整指令产生的时刻,并经过较长时间云计算环境下的运行考验,证明该应用系统可以很好的适合分布式应用系统在云计算环境下的监控。通过该系统,可以直接将分布式应用在云计算环境下部署,充分利用云计算环境的强大计算能力和弹性能力。

2 分布式云服务安全架构语音实时通讯中应用

基于分布式云服务安全架构的语音实时通讯系统,越来越成为互联网实时语音通讯系统的主要的发展方向,目前已经应用于互联网虚拟社区语音互动交流等应用中。

2.1 主要实现方法

通过设计的两台计算机间的语音通信软件,实现了全双上语音通信。PC-PC的语音传输,需要麦克风、音响。声卡等设备就可以通过IP网实现这种应用。这种Vo IP方案的显著优点就是可以支持多媒体通信,主要适用于计算机用户。其原理是利用电话软件把送入话筒的声音进行编码压缩、分组,变成IP数据报,经Intemet网络传送;接收端利用软件进行解码,还原成原来的信号后送到扬声器中。由于软件所需要的设备较为简单,尤其是随着计算机的日益普及、各种硬件设备不断发展;局域网不断增加;通信信道容量不断增加;计算机CPU处理能力不断增强;具有人工智能的可即插即用软件代码技术的出现等等,这些都为Vo IP的发展提供了强有力的技术支持。

在以上处理过程中,要用到一系列的网络接口以及缓冲区来处理数据,但是当前还没有一种固定的和通用的策略能够完全解决Vol P应用中的Qo S问题。本文就存在的问题进行了分析,并给出了一组解决问题的策略。

2.2 可能存在的问题

2.2.1 时延、抖动和丢包三者之间的关系

从网络的角度来看,时廷、抖动和丢包三者同时制约于网络的运行状况,当网络的服务质量下降时,三者均迅速恶化,从终端处理的角度来看,时延。抖动和丢包三者之间又相互影响,比如:在终端处理中,为/减小抖动带来的影响,就要采用抗抖动缓冲区,这就引入了额外的时延;为了减小迟到的语音包数量,可以延迟语音的回放,但也会引入额外的时延;为了采用丢包恢复技术,往往需要利用后续帧信息,这样也就引入了一定的时延;如果抖动效应加强,势必会引起迟到的语音包数量增多。为了解决好话音质量出问题,就必须在这三者当中权衡。

2.2.2 缓冲区机制对语音实时传输性能的影响

缓冲区机制对语音实时传输性能的影响也就是对语音从采样到回放这一时间延迟的影响,特别是当为了满足内存分配的需求而移动全局内存块和抛弃可抛弃的内存块时,消耗的系统时间将对一些实时性操作产生严重影响,在语音实时通信中,用扩大内存的有效的页面技术和磁盘交换技术将不再适用,因为这些语音数据块不能放在真正的主存中以满足实时性要求,需要通过设计数据结构和信息列表实现优化的缓冲机制。

同时缓冲机制对语音的连续性也有很大影响,如果定制的录音缓冲区过小,就会使录制的语音帧过小,从而使语音不连贯。对内存资源的过度占用将导致系统资源的不足。因此需要一种既高效利用内存,又尽量减少语音传输时延的缓冲区管理机制。

2.2.3 网络分组信息的丢失

分组丢失对语音质量有非常大的不良影响。当语音经过—个使用分组丢失作为手段来管理数据网络阻塞的略由器的,这是很麻烦的。对于TCP的数据,端站简单地重新发送丢失的数据并降低它们的通信速率,缓解阻塞,保证数据正确性,而对于UDP协议的语音,没有时间进行重新发送,所以Vol P系统只能适应这种丢失。除了由于中间网络部件引起的分组丢失外,语音网络中由于超出抖动缓冲区的可忍耐的到达延时也引起分组丢失。

在分组被丢失的情况下,如果语音分组丢失是随机的、不相关的,当前的语音编码器的声码器在分组丢失率小于10%的情况下,简单的办法是在丢失包的间隔处插入最后接收到的包,仍能恢复出质量可接受的语音信号。当然,也可以设计出优化的缓冲区,从而前向纠错以减少对语音质量的影响。

2.3 网络协议的选择策略

实时语音的特点:实时性要求高,且允许语音数据在一定的范围内出错;IP语音的特点:由于IPV4不能够提供服务质量保证,所以丢包率和抖动是不可预知的,并且把它们带到了上层协议——IP/UDP中。TCP的特点:能提供面向连接的流传输,可靠性很高,但是会占用网络较多的资源;UDP的特点:能提供无连接的数据包传输,不可靠,对网络的资源占用较少。

由于TCP在传输数据前建立的是虚链路,它不能保证各个语音包在相等的时间内到达,即无法避免话音抖动现象。而且当网络状况不佳时,也无法避免丢失语音包,即使重传也有可能无法满足语音的实坷性。更有甚者,它的窗口技术也会造成较大的附加抖动。

至于UDP,则有可能出现语音包的丢失、重复和失序(好在语音通信允许出错),话音抖动现象也无法避(比TCP好),效率较TCP要高。但需要在应用层增添排序、抗抖、抗重复和抗丢包等功能。所以,对于网络时延较大的场合,一般选用UDP来传输语音包;而在网络负载较小的场合,TCP更为方便。

3 结束语

分布式服务架构 第4篇

关键词：分布式架构,视频服务器,播出系统设计

一播出视频服务器的应用趋势

硬盘播出系统已经不再是一个陌生的名字, 提到这个名字我们首先想到的是自20世纪90年代“数字化硬盘播出系统改造”给广播电视播出系统带来的革命变化, 其次不得不提到的是在数字化硬盘播出系统中的核心视频服务器, 当IT技术逐渐进入广播电视领域, 到视频服务器广泛应用, 使得广电行业能够轻松实现从模拟到数字, 从磁带到硬盘、从标清到高清、从单一频道运行到多频道运行的转换。视频服务器在广电行业中的应用已近10年, 在这近10年的时间里, IT技术已经成熟应用在广电行业各个软硬件技术中, 视频服务器发展过程中也同样经历了硬件系统、软件系统的更新换代。视频服务器的发展经历了硬件架构从集中架构到分布架构, 存储从单机存储到集中存储, 编解码系统从硬件编解码到软件编解码的发展过程。

从图1可以清楚地看到, 集中式硬件架构中视音频编解码处理、存储阵列管理、RS422控制管理等软硬件模块, 都需要依赖于系统总线完成命令数据、视音频文件流、网络传输等任务, 因此系统总线的负载及系统带宽的大小是集中式硬件结构的发展瓶颈, 节目存储传输也因服务器架构限制主要完成视频服务器之间的节目镜像拷贝。

早期的视频服务器产品如:AVID公司PINNACLE M e d i a S t r e a m系列、T H O M S O N公司P R O F I L E系列、SEACHANGE公司MediaCluster服务器系列等视频服务器在实际应用中常见的系统搭建方式有单机结构、主备冗余备份结构、分散式结构及集中存储结构, 如图2所示。

无论是主备冗余结构、还是分散式、集中存储结构, 视频服务器之间与存储阵列使用光纤进行连接, 通过视频服务器内部FC通道管理模块完成编解码通道数据传输与节目素材内部拷贝传输, 光纤连接为内部节目素材传输提供了高速稳定的传输通道, 但是对外部全台网管理系统、二级内容存储管理系统支持因没有外部连接网关的管理, 视频服务器本身又无法直接完成FTP传输, 因此在实现播出系统与外部存储管理系统连接时无法提供具有良好稳定性、高速传输的解决方案。

分布式硬件架构将视频服务器的视音频编解码处理与端口控制 (视频服务器客户端) 、文件系统管理及网络传输控制 (视频服务器服务器端) 、存储阵列管理与传输 (存储系统) 从硬件层进行分离, 将原有内部系统总线移至系统外部, 各端点之间使用LAN/FC进行连接, 形成SAN、ISICS等内部高速传输系统, 对外使用FTP方式与外部存储系统连接。视音频节目可以通过FTP方式与视频服务器系统进行高效调度, 如图3所示。

分布式硬件架构视频服务器其特点为:

1. 灵活扩展性:重新定义灵活性

视频服务器系统在增加编解码通道或存储容量的时候, 不需要淘汰或增加大量无关设备, 并且系统在更换和扩充时无需停止工作, 始终确保用户的原始投资。系统冗余、网络带宽、上下载端口、存储容量可以依据用户需求单独或一起扩展。系统扩展方式简单, 无需淘汰设备, 无需打开机箱, 在大部分情况下不需要停机就可以完成系统扩展, 最大限度地节约系统成本, 保证了系统间断正常播出。

2. 网络配置简化:系统配置简化性

使用分布式系统架构, 有效地避免因系统网络规模不断增长, 而出现系统配置复杂度增加。当系统发生故障时, 因分布式系统将系统区域根据功能进行划分, 规避了因规模庞大, 结构复杂, 而导致很难迅速定位的问题。

3. 系统安全性:系统安全性因分布而提高

分布式系统架构对视音频编解码、节目存储管理、文件系统管理、内外部网络传输管理进行功能及硬件区域划分, 因此当某一部分出现问题不会影响整体系统正常应用。

二北京电视台新台播出视频服务器方案设计

1. 播出系统网络总体架构

北京电视台新台播出系统设计是以数字化为基础, 网络化为核心, 并按照新台设备系统规划, 一期将完成6+3套标清和1个高清频道的系统建设。

为了使播出系统节目存储、播出安全、可靠和稳定, 我们在设计方案中采用了分级存储的方式, 如图4所示。将播出网络系统划分为各功能子系统, 由播出二级存储、播出节目紧急上载、播出服务器系统与播出节目素材传输、及播出控制组成。将播出服务器系统与上载服务器系统分离, 并设播出二级存储。这样做的好处是各子系统功能单一, 可以分担风险。

其中播出二级存储是连接媒资系统播出库和播出服务器系统的桥梁, 其存储容量可保存15天节目, 目的是用来对媒资播出库起到备份的作用。另外, 播出服务器系统和上载服务器系统节目存储容量分别按3天考虑。

2. 服务器系统选型

按照北京电视台新台制播网络系统整体设计规划, 为了实现使播出网络与全台以媒资存储为核心的制播网络系统的互联互通, 对于播出服务器设备, 在满足安全可靠播出要求的同时, 还要考虑以下几点。

●要求服务器系统设计能够满足开放式要求, 系统对外数据传输端口应采用工业级标准的千兆以太网接口规范, 支持FTP、CIFS等文件传输协议;

●要求服务器设备采用标准开放的文件格式, 以实现媒资系统存储的节目文件格式与播出视频服务器文件格式一致, 达到互联互通;

●播出服务器系统要求具有足够的对外数据传输带宽。以保证系统在满足正常播出的情况下, 通过网络与外部迁入或传出节目素材;

●播出服务器系统要求便于扩展。可支持在线的存储容量扩展, 可方便地增加视频编解码通道数量, 为系统以后的升级提供可能;

●播出服务器系统关键设备要求采用冗余设计。如:连接控制单元 (存储控制器) 、电源、风扇等。要求系统硬件无单一崩溃点, 以保证系统在任一个硬盘或解码板出现故障时的不间断播出;

●播出服务器系统设备要求便于在线维护和检修。系统关键部件包括电源、风扇、硬盘等, 要求可支持热插拔。并当遇到系统检修或关断电源后, 重新启动时, 系统数据应具有较快的重建恢复时间。

基于以上考虑, 我们经过对服务器设备的广泛调研, 最终确定播出系统视频服务器采用汤姆逊公司生产的K2视频服务器产品。

K2有单机版视频服务器, 最多可容纳4路编解码通道, 并具有双向功能, 通过不同的产品配置, 实现SD标清或HD高清的播出。采用这种视频服务器搭建播出系统, 由于运用简单, 可以减轻管理的复杂度, 并且维护便利, 适用于少数频道播出的应用。

基于分布式硬件架构的设计理念, K2视频服务器系统典型的结构是由K2客户端、K2服务器和K2硬盘存储阵列三部分组成的。它相当于是将编解码通道从K2单机视频服务器产品主机中外移出来, 组成一个单独K2客户端, 形成编解码通道与服务器分离, 并还可以采用外部存储, 形成典型的K2ISCSI SAN存储的播出服务器系统。

经过这种服务器产品的不同组合, 可以构成K2产品不同的组网方式:Level 1、Level 2、Level 3、Level 2R、Level3R等。这种分布架构的优点是可以满足电视台不同频道数规模的应用和各种需求, 客户端、服务器和硬盘阵列数量可以灵活配置, 方便组合。很容易实现通过增加服务器、客户端等来扩充系统通道数、扩充系统带宽和存储容量。

3. 播出服务器系统设计

根据K2视频服务器产品能够灵活组合的优势。每套K2标清单机配置4路双向编解码通道, 3个双向编解码通道用于节目播出, 多出的1个双向编解码通道可以做播前节目审看。因此, 我们6个标清频道的主/备播出采用4台K2单机视频服务器完成。由于K2服务器产品还可组建不同的SAN架构系统, 所以6个标清频道的第二备份播出服务器系统, 我们是采用K2 Level 2的单SAN架构。其中3个客户端, 共12个通道。用于第二级备份播出6个通道, 备份频道的备份播出3个通道。这样的好处是可以实现6个频道节目素材共享, 并且随着今后频道的增加, 便于扩展。

对于高清频道, 考虑在前期1个高清频道的节目量并不大, 因此一期先将播出与上载合二为一。采用两套K2单机视频服务器, 每台服务器配置两个双向编解码通道, 1个用于上载, 1个用于播出。

对于播出节目上载系统, 根据北京电视台新大楼制播网络的整体流程, 播出网络内部的节目上载系统虽仅为应急节目上载, 但也要求起到对媒资播出库节目上载的补充和备份作用。因此, 我们在设计时, K2 Level 3 SAN存储架构的视频服务器系统提供了比较好的解决方式。

如图5所示, 5台K2 ISCSI共享存储客户端完成10路上载和10路监看, 并且为了保证系统无单一溃点, 我们选择了K2 Level 3 SAN分布式服务器存储系统架构, 采用双交换机、2对主/备服务器主机 (共4台) , 和双控制卡存储主机箱, 构成了完全冗余的单SAN存储视频服务器系统。可以保证系统上载和对外FTP视频文件传输的总带宽要求, 而且上载系统在任意客户端 (视/音频I/O) 、交换机、服务器以及存储盘阵出现故障时, 系统其他的所有硬件部分仍能正常工作, 而不会导致整个系统瘫痪。

总之, 北京电视台新大楼播出服务器系统方案结合了多种分布式视频服务器系统架构的优势, 因地制宜按照北京台设备系统具体情况配置出符合要求的系统方案。其特点是全程无单一崩溃点, 在关键环节采取多重保护, 始终将安全播出放在首位。并在融合广电技术与IT技术的基础上, 为实现新台播出系统全网络化管理流程奠定了基础。

三结束语

现代分布式软件工程架构分析与探讨 第5篇

本文详细的分析了两层C/S体系架构和三层B/S体系架构模式的原理及作用, 并且探讨系统架构的优劣势。

1 C/S架构

C/S体系架构模式是分布式管理系统发展初期广泛的使用的系统架构之一, 其包括两个关键的组成部分, 分别是系统客户端和系统服务器端, 其中客户端可以为用户提供应用系统操作界面, 登录操作系统, 发起系统逻辑业务请求;服务器端是系统的核心, 由Web服务器、应用服务器和数据库服务器沟通, 能够解析用户发出的逻辑业务请求, 将用户的不同服务请求发送不同的服务器, 分别是应用服务器和数据库服务器, 以便其能够处理并且反馈响应结果。由于当前许多用户的使用的计算机硬件配置的非常强大, 可以有效的帮助服务器处理逻辑业务, 其可以帮助用户解决服务器的压力, 降低服务器系统的通信需求, 降低系统的开销要求, 因此很多分布式系统软件采用两层的C/S体系架构。C/S体系架构适用于局域网环境, 通信传输过程中采用带宽较高, 响应时间较短, 具有较好的处理效率, 提高用户的可感性[1]。

尽管C/S体系架构模式应用广泛, 并且有许多优点, 随着互联网用户的迅速扩展, 政企单位的职工等用户通常会出差在外, 需要登录系统, 必须安装客户端, 否则无法使用;另外, 随着系统功能的丰富和完善, 系统使用用户也在迅速上升, 此时C/S体系架构就不适合系统应用, 需要重新开发系统, 采用更加先进的B/S架构。

2 B/S架构

随着时代的发展, 网络用户越来越多, 应用程序也越来越多, 需要采用先进的系统架构模式, 将系统集成在一起, 通过IE浏览器登录系统, 并且无需按照任何客户端程序, 以便能够方便具有不同计算机专业技术水平用户使用[2]。为了解决上述问题, 许多计算机学者经过研究, 提出了B/S体系架构模式, 该架构模式包含三个重要的组成部分, 包括浏览器、Web服务器、数据库服务器等, 其中浏览器又被称为表示层, Web服务器被称为逻辑业务处理层, 数据库服务器被称为数据处理层[3]。每一层的功能如下所述:

(1) 表示层:表示层就是用户和其分布式系统的交互接口, 并采用友好图形给各个用户提供输出输入服务, 通常采用用户浏览器实现操作, 所以, 用户所填入的信息由表示层向逻辑业务处理层发出各种请求操作, 逻辑业务处理层对客户端请求进行响应, 并在用户浏览器中输出反馈的结果。

(2) 逻辑业务处理层:逻辑业务处理层是在B/S体系架构模式中数据处理层与表示层间的一层, 该层主要对系统应用模型进行封装, 并为数据处理层与表示层提供数据库的链接服务, 针对用户浏览器请求, 对系统服务器端数据库进行连接, 并把处理的结果返回于用户浏览器。

(3) 数据处理层:数据处理层是B/S模型中的最底层, 主要负责的功能包括数据定义、修改、维护等, 且对接受到的用户浏览器数据请求实行处理以及回复。

B/S体系架构是当前分布式应用系统采用的主流架构技术, 分布式管理系统采用该架构时, 用户无需按照客户端应用程序, 只需要在IE浏览器中输入服务器地址即可登录系统实施各种操作, 具有良好的应用性能。但是随着分布式系统集成移动计算、云计算等技术, 仅仅采用B/S系统架构逐渐不能满足系统应用需求, 因此, 未来分布式系统架构的发展趋势包括以下两个方面:基于C/S、B/S发展混合架构模式, 提高管理系统的响应性能;基于云计算技术, 研究分布式透明云计算架构, 便于分布式系统应用。

3 结语

随着计算机软件设计技术的快速发展, 软件技术得到长足的进步, 尤其面向对象、云计算等软件工程开发、分布式计算技术诞生和应用, 大规模的提升了软件的复杂性, 一个好的软件系统架构能够大幅度提升软件系统的服务性能, 将会得到更多的研究和改进。

摘要：随着网络的快速发展, 分布式软件系统得到了广泛的应用。分布式系统设计架构采用两层C/S、三层B/S等架构模式, 更加适用于用户登录使用、海量数据管理。本文基于笔者多年的分布式系统运行管理实践, 详细地分析和探讨了分布式系统采用的架构模式。

关键词：分布式系统,C/S架构,B/S架构

参考文献

[1]张晓梅, 周莎莉, 王秋生, 等.基于C/S-B/S混合架构的道路施工实验室网络管理系统[J].工业计量, 2010 (6) :12-15.

[2]林凡森.基于B/S体系架构的分布式管理系统应用设计[J].才智, 2014 (12) .

分布式网上评卷系统架构及实施方案 第6篇

众所周知, 网上阅卷作为一种全新的阅卷模式具有评卷误差小、准确高效的优点, 自本世纪初首次应用以来, 至今有十余年的历史, 现已广泛应用于国内的普通高考、成人高考、自学考试、中考及其他社会化考试领域, 如各级人事考试机构的公务员考试、会计资格考试及其他职称考试。此外, 网上阅卷系统还在大中学校有广泛的应用, 取得了广泛的社会效益。

考虑到阅卷过程中数据的安全性及考务管理问题, 目前常见的网上阅卷一般是在封闭的局域网内实施阅卷, 通常存在以下难以解决的问题:

1) 局域网场地与计算机数量的限制:针对某些大型考试, 同时在线的评卷人数很大, 往往超过几千人。在这种情况下, 单个的局域网内的阅卷场地在物理空间上可能难以容纳如此众多的计算机与阅卷老师, 而且在计算机网络的组织、布置与施工上也存在相应的困难。

2) 阅卷后勤管理与费用方面的限制:针对某些大型考试, 在线阅卷人员可能达到数千人。如果同时在一个封闭的环境中阅卷, 在解决技术门槛的基础上还需考虑阅卷人员的吃住行等后勤保障问题。显然, 对于组织协调数千人阅卷老师的吃住行及安全后勤保障问题绝非易事, 且极有可能在后勤保障方面的费用超过预算。

3) 对于某些特殊考试的特殊评卷要求考虑, 某些考试需要在阅卷时要求不同的题与题之间是相互隔离的。

2 分布式网上阅卷解决方案

基于以上现实情况, 我们必须在满足常见的局域网或一般的广域网阅卷的基础上, 设计一种基于分布式网上阅卷的实施模式, 使之适应某些特殊的考试。

针对以上提到的评卷模式, 我们设计了两种分布式评卷模式。具体如下:

方案一:评卷数据集中控制但评卷点多点分布, 即所有的评卷数据集中在考试机构的数据中心机房, 评卷点分布在不同的物理地域, 中心机房与各个评卷点之间采用专线或VPN方式联网, 系统结构如下图1所示。

在这种评卷模式下, 评卷数据集中在中心机房进行管理, 可以确保评卷数据的安全可靠, 评卷点分布在不同的物理地域, 既避免了集中评卷时可能存在的机位不足或场地有限的问题, 也有利于针对评卷人员的后勤保障的实施。

就技术层面而言, 中心机房与各个评卷点采用专线连接或VPN连接基本相同。如果采用VPN方式连接, 需要通过路由器作为VPN网关, 通过硬件加密技术, 组建基于IPSEC的VPN, 确保数据的安全。

就经济成本而言, 如果采用专线方式相连, 则成本上要比通过VPN方式连接要高的多。因此, 最终技术方案的确定需要考虑用户方的经济承受能力及其他综合因素。

如果用VPN方式组网, 建议采用IPSEC方式进行组建, 传输数据进行加密, 以保证传输数据的安全。所有的阅卷终端设备, 不许访问互联网络。

同时, 为了防止病毒的传播与广播风暴的问题, 在阅卷点中, 对阅卷终端进行VLAN隔离, 把阅卷终端划分到不同的VLAN中, 一般来说, 我们常见的做法是每个阅卷教室划分一个VLAN, 每个VLAN分一个C类的私有IP地址段。

方案二:评卷基础数据集中控制但阅卷在各个阅卷点独立进行, 阅卷实施前根据各个阅卷点的拟分配数量和全部评卷数据打乱并下发到各个阅卷点, 确保各个阅卷点分配到的数据是随机无序的。各个阅卷点按统一的评卷误差及题型结构进行独立阅卷, 阅卷完毕后将各自的阅卷结果数据统一到考试管理机构的数据中心进行数据合成, 并产生最终的评卷结果。

此方案的网络拓扑见下图:

在这种阅卷模式下, 由于阅卷点分布在不同的物理区域, 既避免了集中阅卷时可能存在的机位不足或场地有限的问题, 也有利于针对阅卷人员的后勤保障的实施。

就数据安全性而言, 由于分配到各个阅卷点的阅卷基础数据是经过加密的、且完全随机分发, 首先确保了阅卷基础数据是不透明的, 外人无法了解待评数据的来源;待评数据是随机分发的, 所有这些措施可以保证阅卷过程的公平、公正性。

在数据的加密手段上, 我们设计了多种安全机制。首先, 对考生的准考证号信息进行加密处理, 所有在答题卡扫描及阅卷阶段考生的关键信息一律以加密的形式出现。其次考生的扫描图像命名上也采用全局流水号的方式命名。因此, 就公开的扫描及网阅基础数据而言, 外人根本无法获取某考生的真实考号及相关信息, 从根本上保证数据的安全;其次, 分发的网阅数据是经过随机算法打乱的, 确保了考生的真实来源地与阅卷地之间没任何关联, 保证了网阅过程的公平和公正性;最后通过扫描时的数字水印加密技术, 对阅卷后得到的数据再次进行水印还原检验, 检验阅卷过程中该图像是否被人为篡改过, 通过上述多重数据安全手段确保数据的安全。

3 总结

本文提出了两种分布式网上阅卷的方案, 能有效地解决集中阅卷场地不足和后勤保障困难的问题, 同时能保障数据的安全, 保证阅卷过程的公平和公正性, 具有很高的应用价值。在以后的工作中, 我们将会把图像识别, 指纹认证等技术应用到分布式网上阅卷系统中来。

参考文献

[1]万雅奇.网上阅卷数据源的拓展和应用研究[J].中国考试:研究版, 2006 (11) :42-44.

[2]王健.基于VC++的网上阅卷系统设计与实现[D].济南:山东大学, 2011.

[3]崔颖.吉林省自学考试网上阅卷系统的设计与实现[D].长春:吉林大学, 2012.

[4]黎春.基于SSH组合框架的网上阅卷系统研究与应用[D].贵阳:贵州大学, 2009.

[5]谢琪林.网上阅卷系统设计与实现[D].成都:电子科技大学, 2011.

[6]张玲.基于图像工程的网上阅卷系统的研究与设计[D].济南:山东大学, 2010.

[7]杨义在.基于J2EE架构的网上阅卷系统设计与实现[D].贵阳:贵州大学, 2008.

分布式服务架构 第7篇

关键词：分布式,管理平台,物流信息交换,SaaS

电子商务的发展改变了企业以往的销售方式和消费者的购买方式[1], 从而也推动着现代物流行业的发展。如何将物流和信息流进行有效的集成是现代物流行业发展所面临的一个问题。现阶段我国物流信息化建设取得了一些成绩, 但整体发展水平还比较低, 存在不少制约因素, 具体表现在:1) 物流信息不对称、运作管理标准不一, 集成度低和适应性差, 业务模式和运作机制还停留在传统的信息系统架构模式, 从而导致行业数据共享困难;2) 大多数物流信息系统的成本较高, 而中小企业的起点很低, 市场缺少适合中小企业起步的信息系统[2];3) 物流活动有跨企业、跨行业和跨地域的特点, 会产生大量的物流信息, 而现有物流信息系统在应对高并发、大量数据处理以及业务不断增长等方面面临着严峻的挑战。该文提出了一个基于分布式架构的物流信息管理平台 (以下简称平台) 设计, 可以有效的应对上述问题。

1 平台设计

1.1 物理架构

平台架构如图1所示包含门户网站、中心服务器、物流信息管理服务器和客户机。门户网站旨在为平台管理员、平台用户 (如物流企业) 和物流活动的其他相关人提供一个用以访问平台公共服务的互联网入口。中心服务器存储了整个平台中物流信息的索引记录, 负责物流信息的路由和交换。物流信息管理服务器在地理上分布在不同地区, 负责存储该地区的物流信息。客户机通过基于C/S结构开发的客户端程序进行物流信息的管理工作。

物流信息管理服务器与其所服务的客户机组成一个高度自治的服务节点, 在其他服务节点发生故障或者服务器之间网络中断的情况下, 不会对本地物流信息管理造成影响, 因而具有稳定性高和扩展性强的优点。平台在业务访问请求超出现有处理能力的情况下, 通过增加服务节点来对访问请求进行分流, 从而较好解决了因处理能力不足而导致的性能瓶颈问题。

以中心服务器为顶层节点, 物流信息管理服务器为子节点构成了一个层次结构的分布式物流信息交换网络。通过该网络可实现物流信息在平台内外的交换与共享。

1.2 物流信息处理规则

按照[5]中的定义, 物流信息可分为静态物流信息和动态物流信息两种。静态物流信息是物流活动中保持稳定不变的信息, 如企业、各类单据、车辆信息, RFID卡信息。动态物流信息是随物流活动运动而变化的信息, 是物流状态在某一时刻的真实反应。

在本平台中, 静态物流信息和与之相关的动态物流信息存储在同一物流信息管理服务器上, 通过静态物流信息的全局唯一编码进行关联。物流信息管理服务器、物流信息进行统一编码, 编码在整个平台中具有唯一性。索引记录是用于描述物流信息存放位置的信息, 包含物流信息的编码和所在物流信息管理服务器的地址信息。

1.3 基于Saa S模式的服务节点设计

Saa S (Software as a Service, 软件即服务) 是一种新兴的软件模式[4], 其特点是:应用软件统一部署在服务器上, 并以服务的形式向用户提供, 因而减轻了终端用户硬件开销, 减少了终端客户维护、更新和管理软件的费用[3]。采用Saa S模式构建软件可以有效的解决物流企业尤其是中小型物流企业的信息化问题。

服务节点在设计上采用C/S结构、Web Service技术和Saa S模式。C/S结构可以充分利用两端硬件环境的优势, 将任务合理分配到Client端和Server端来实现, 降低了系统的通讯开销。Web Service技术具有开放性、平台独立性、松耦合性和可复用性等优点[1]。

为了给多个物流企业提供服务, 服务节点的逻辑架构分为应用服务层和基础服务层, 在数据存储上采用了数据库共享模式。应用服务层集中了用户管理、登陆、车辆管理、运单管理等核心业务, 基础服务层对应用服务层提供业务支撑, 主要包括Web Service接口、数据库访问、LDAP认证和事务管理等。在数据库共享模式下, 所有物流企业使用相同的数据库和表设计。不同物流企业的表数据通过平台分配的企业ID进行区分。

1.4 物流信息交换网络设计

物流活动具有跨企业、跨行业和跨地域的特点, 这使得物流信息需要在不同的物流信息管理服务器之间、平台内部和外部进行交换。平台通过物流信息管理服务器和中心服务器的物流信息交换软件实现信息在平台内外的交换。物流信息交换软件的模块如图2所示:

物流信息管理服务器的物流信息交换软件包含物流信息访问代理、物流信息同步和服务器间通讯接口三大模块。物流信息访问代理有三个功能:1) 当客户机访问的数据存放在别的物流信息管理服务器时, 由物流信息访问代理模块将请求发往中心服务器, 通过中心服务器的物流信息路由与交换功能从其他的物流信息管理服务器上取得所需要数据;2) 处理中心服务器转发的数据访问请求;3) 转发客户机发送的非本地物流状态信息。服务器间通讯接口用于同中心服务器进行交互, 采用Web Service技术进行开发。物流信息同步模块监控对本地物流信息的变更情况, 通过同步操作将变更信息发往中心服务器。

中心服务器的物流信息交换软件包含服务器间通讯接口、物流信息路由与交换、全局索引记录管理和门户网站交互接口四大模块。服务器间通讯接口模块用于同物流信息管理服务器进行交互。物流信息路由与交换模块处理来自门户网站和物流信息管理服务器的请求:对于路由与交换请求, 通过查询全局物流信息索引记录以确定要将该请求转发到哪一个物流信息管理服务器, 并将处理结果返回给数据请求者;对于同步请求, 则调用全局索引记录管理模块对全局索引记录进行相关处理。全局索引记录管理模块负责对全局索引记录进行查询、创建、变更等操作。门户网站交互接口以Web Service的方式为外部系统共享平台内部数据提供了访问接口。

1.5 工作流程

为实现物流信息交换, 平台定义了一套基于分布式物流信息交换网络的物流信息处理方法, 包含如下工作流程:

1) 平台用户注册

平台用户在门户网站提交注册申请, 平台管理员对申请进行审核。对于符合申请条件的用户, 平台管理员批准该申请, 并为其指定物流信息管理服务器。门户网站通过中心服务器将平台用户注册请求发送到物流信息管理服务器。物流信息管理服务器处理平台用户注册请求。

2) 门户网站查询请求处理

网站用户通过门户网站提交物流信息查询请求, 请求被转发到中心服务器。中心服务器在数据库中对物流信息的索引记录进行检索, 从检索结果获取存储该物流信息的物流信息管理服务器的地址, 然后将查询请求发送到物流信息管理服务器。物流信息管理服务器处理查询请求, 返回查询结果。

3) 客户端查询请求处理

物流信息管理服务器处理来自客户机的查询请求, 首先在本地数据库进行检索, 如果本地数据库存储了所需数据, 则将查询结果返回给客户机, 否则将请求转发到中心服务器。中心服务器对物流信息的索引记录进行检索, 从检索结果获取存储该物流信息的物流信息管理服务器的地址, 然后将查询请求发送到物流信息管理服务器。物流信息管理服务器处理查询请求, 返回查询结果。

4) 物流信息路由与转发

物流信息管理服务器处理客户机发送的动态物流信息 (如运单状态跟踪信息) 上传请求, 首先判断是否是本地的物流信息, 判断方法为与之关联的静态信息是否存放在本地, 如果是则存放在本地数据库, 否则将物流信息转发到中心服务器。中心服务器通过对物流信息的索引记录进行检索获取用于存储该物流信息的物流信息管理服务器的地址, 然后将物流信息转发到物流信息管理服务器进行存储。

5) 物流信息同步

物流信息管理服务器监控对本地物流信息进行的增加、删除操作, 一旦监测到上述状态变化, 则向中心服务器发起物流信息同步请求。中心服务器根据物流信息同步请求, 对全局索引记录进行更新。

2 结束语

本文所设计的基于分布式架构的物流信息管理平台, 旨在实现对物流信息的统一管理, 降低企业进行物流信息化建设的成本, 有效应对高并发、大量数据处理以及业务不断增长带来的性能瓶颈问题。对于该平台, 目前已经完成了一套演示系统, 经过调试运行, 表明该平台满足了之前所设想的应用需求, 并且运行良好。

参考文献

[1]杨明, 周国祥.基于Web Service的现代物流平台的设计与实现[J].安徽科技学院学报, 2010, 24 (1) :29-34.

[2]戴洪立.基于口岸物流网的物流公共信息平台建设研究[D].大连:大连海事大学, 2010.

[3]梁洁涵.SaaS模式的物流与采购一体化信息平台研究[D].北京:首都经济贸易大学, 2010.

[4]黄日胜, 周永福, 黄锡波.基于SaaS模式的现代物流管理系统的设计[J].计算机与数字工程, 2011, 39 (1) :78-79.

分布式服务架构 第8篇

近年来, 移动互联网业务如游戏、视频等访问量剧增。传统的集中式业务平台多采用IOE (IBM、Oracle、易安信公司) 架构[1], 即基于IBM小型机、Oracle数据库与EMC存储设备组合的架构, 投资成本高且扩展性受限, 难以支撑业务快速发展, 已经被百度、阿里巴巴、腾讯 (BAT) 等互联网公司逐步放弃。

为了解决业务平台面临的高并发访问、海量数据处理、高可靠运行、业务随需应变等一系列问题与挑战, 业界在实践中应用了多种技术, 包括分层架构、大规模集群、分布式缓存等。本文基于业界解决方案, 结合游戏平台业务特点, 提出了大容量分布式游戏平台架构, 有效满足移动互联网应用亿万级规模的用户并发访问和大规模数据存储等需求。

1 平台设计要素

与传统应用相比, 大型移动互联网平台应用具有以下特点:

高并发:移动互联网业务用户增长快速, 需要面对高并发用户以及长时间的大流量访问。“淘宝”2014 年“双十一”活动全天成交金额571 亿元, 其中移动端交易额243 亿元, 物流订单2.78 亿个。

高可用:系统7×24 h不间断服务, 服务的中断会带来严重的损失。2015 年携程网宕机12 h, 造成了巨大的负面影响。

海量数据:业务数据增长快速, 存储、管理海量数据, 需要使用大量服务器。Google有超百万台服务器为全球用户提供服务。

用户接入环境复杂:面向全球用户提供服务, 用户网络环境千差万别, 国内不同运营商网络存在互通问题。

需求多变:移动互联网产品用户需求变化快速, 多采用迭代开发的模式, 快速发布新版本。微信朋友圈的研发过程为4个月, 团队完成了30 多个版本的迭代。

上述需求使得平台架构的设计需要关注性能、可用性、伸缩性和扩展性等关键要素, 具体说明见表1。

2 平台架构体系

平台采用分布式架构和层次化模块设计, 并根据移动互联网业务需求, 将公共核心业务能力 (如计费) 抽取出来, 形成可共用的对内对外服务。系统主要核心模块如图1所示。接入层负责用户客户端的接入以及互联网服务的分发, 主要包括智能DNS (域名系统) 、CDN (内容分发网) 等服务模块。业务层面向用户提供门户、计费、内容搜索等服务, 包括业务应用层和业务接口层两层;业务应用层包括用户、计费等共用功能模块;核心层包括核心接口层、核心层以及底层数据库。其中核心接口层与业务接口层对接, 供业务层调用。核心层对缓存及数据库进行封装和访问, 当数据在缓存中时直接对数据进行访问, 数据不存在缓存中时再访问数据库。

3 平台关键技术

3.1 负载均衡

随着手机游戏的快速发展和业务量的不断提高, 负载均衡是游戏平台必不可少的基础技术手段。负载均衡将负载分摊到不同的服务单元, 不仅可以实现平台的伸缩性, 又保证了服务的可用性, 还提升了响应速度, 给用户好的体验。随着硬件技术的迅猛发展, 越来越多的负载均衡硬件设备涌现出来, 如F5Big-IP、Citrix Net Scaler等, 但其价格却十分高昂, 因此一些免费又可靠的负载均衡软件方案是比较好的选择。

游戏平台首先利用DNS域名解析作为第一级负载均衡手段, 采用智能DNS技术与多线接入的方式加速异网用户的访问。智能DNS带有IP地址库, 可根据用户的源IP (网际协议) 识别和自动判断用户来源、所属运营商, 智能把用户请求重定向到用户所在运营商网络部署的服务器, 从而减少跨网流量, 加快用户的访问速度, 提升用户的体验。目前DNS解析服务提供商DNSPod提供免费的智能DNS服务。

平台可以根据用户访问情况实现IP负载均衡。通过增加用户接入点做到负载分流, 避免单负载均衡器的性能瓶颈。如对于电信用户比较多的游戏平台, 可以增加电信网络下的服务器, 通过各种负载均衡策略优化访问体验。一般常用的负载均衡算法包括轮询算法、加权轮询算法、随机算法、最少连接算法、源地址哈希算法等。

游戏平台选用免费开源软件Haproxy[2]作为负载均衡的软件解决方案。Haproxy是一种提供高可用、负载均衡、基于TCP (传输控制协议) 和HTTP应用的代理技术。作为免费开源的解决方案, Haproxy特别适用于负载大、需要会话保持或七层处理的网站, 支持虚拟主机, 可以支持数以万计的并发连接, 并且可以简单安全与当前的平台架构进行整合, 并实现Web服务器与外界隔离。在游戏平台的实践中, Haproxy对外提供HTTP代理服务, 包括游戏大厅、用户中心、计费、能力开放平台、门户等HTTP服务;对内主要用与TCP代理服务, 用于代理核心、数据层服务, 分别代理游戏核心业务、用户核心业务、数据库业务。

为了实现集群的高可用, 还需要对节点进行检测以避免单点故障, 使得节点做到双节点备份, 故障无缝热切换。游戏平台采用开源软件Keepalived[3]方案, Keepalived是一种高性能的服务器高可用或热备解决方案。

3.2 分布式架构

游戏平台采用分布式的架构设计模式, 通过分布式缓存、分布式数据库、分布式文件系统, 实现平台的高性能、高可用与高扩展性。

缓存是网站性能优化的第一解决方案, 通过将数据存储在访问速度较高的存储介质, 能有效提升用户访问速度。分布式缓存将缓存部署在多个服务器组成的集群中, 其架构主要有两种, 一种是以J Boss Cache[4]为代表的需要更新同步的分布式缓存, 一种是以Memcached[5]为代表的不相互通信的分布式缓存。对于目前的游戏平台, 需要缓存的数据量一般比较大, 采用需要同步的方案代价太大, 一般采用Memcached方案。Memcached是一套高性能的、分布式的内存对象缓存系统, 用于在动态应用中减少数据库负载, 提升访问速度。通过在内存里维护一个统一的巨大的哈希表, Memcached能够用来存储各种格式的数据, 包括图像、视频、文件以及数据库检索的结果等。

平台的数据存储需要结合游戏业务的特性进行设计。游戏业务, 尤其是手游业务所产生的数据与其他业务存在较大差别。一方面, 数据时效性突出, 手游内容和用户游玩生命周期都较短, 因此必须对业务数据实时处理;另一方面, 数据碎片化突出。非关系数据库 (No SQL) 基于非关系、分布式、可扩展的设计模式, 适合上述复杂查询场景。平台采用Mongo DB[6]来提升海量数据处理效率。Mongo DB是非关系数据库当中功能最丰富, 最像关系数据库的。其支持的数据结构非常松散, 可以存储比较复杂的数据类型。同时, 对于用户付费、购买和平台/ 游戏收入等关键经营分析数据, 依然保持结构化数据的特点, 可以采用My SQL进行处理。

平台采用NFS (网络文件系统) 作为分布式文件系统, 提供底层的存储。NFS允许一个系统在网络上与他人共享目录和文件。通过使用NFS, 用户和程序可以像访问本地文件一样访问远端系统上的文件。

4 结束语

本文介绍了大容量分布式游戏平台架构, 重点讨论了负载均衡与分布式技术。爱游戏平台是由炫彩互动网络科技有限公司 (中国电信游戏基地) 全力打造的互动娱乐平台, 采用了上述架构与关键技术。平台已经上线两年, 系统运行稳定。目前平台承载了手机游戏、电视游戏、游戏社区等多元化游戏产品, 平台用户超2 亿户, 其中月活跃用户3 000 万户, 最高并发用户数500 万户, 门户访问量十亿次, 实现了5 个9 的可用性。应用接口响应速度最高不超过500 ms, 90% 在100 ms以内;能快速响应不同运营商网络用户的服务请求, 命中率达到99.99%。实现了平台架构设计的高性能、高可用、可伸缩、易扩展的目标。

参考文献

[1]金峰.电信运营商“去IOE”的思考[J].通信世界, 2014, (3) :39.

[2]刘锴.利用HAProxy实现选课系统Web负载均衡[J].电脑知识与技术, 2011 (7) :35-36.

[3]汪海洋, 凌永兴, 包丽红, 等.基于Keepalived的高可用性应用研究[J].电子技术, 2014 (7) :21-24.

[4]郑雅萍, 张立东, 孙毅夫, 等.J BossCache缓存技术在集群系统中的应用[J].控制工程, 2008 (S2) :155-157.

[5]陈康闲.大型分布式网站架构设计与实践[M].北京:电子工业出版社, 2014:60-70.