基于云协作平台的客户端设计与实现本科毕业论文.docx

基于云协作平台的客户端设计与实现本科毕业论文.docx

《基于云协作平台的客户端设计与实现本科毕业论文.docx》由会员分享，可在线阅读，更多相关《基于云协作平台的客户端设计与实现本科毕业论文.docx（37页珍藏版）》请在冰豆网上搜索。

基于云协作平台的客户端设计与实现本科毕业论文

题目：

基于云协作平台的客户端设计与实现

基于云协作平台的客户端设计与实现

摘要

云协作平台其理论依据来源于云计算，是基于互联网，将共享的软硬件资源和信息,通过云资源调度管理系统（JHscheduler），按需提供给计算机和其他设备，并对这些设备进行管理。

云协作平台通常提供通用的通过浏览器访问的应用，软件和数据可存储在数据中心。

浏览器和服务器结构虽然简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本，然而浏览器和服务器结构也有一些自身无法克服的缺点。

现如今，浏览器种类繁多，良莠不齐，这样，就引发了一个很难做到平衡的问题——浏览器的兼容性问题，还有一个根问重要的是：

如果要将本地的一些应用程序集成到云平台，浏览器就显得捉襟见肘了。

客户端的出现恰恰解决了以上问题。

本文基于云协作平台，以浏览器实现的功能为设计参考，重点在于节省系统软硬件资源，避免不同浏览器带来的浏览器兼容性问题，增强云协作平台前端的可扩展性，并为客户端增加一些与服务端交互的工具，提高云协作平台的用户体验和产品的认可度。

客户端的实现是以观察者模式为设计模式，以QTGUI为开发框架，使用Thrift，Boost等第三方工具库。

做到与浏览器端高度一致，与服务器端接口兼容，又具有客户端特色的云协作平台的用户前端软件。

通过几个月的学习和努力，熟悉了服务器端的运行机制，以及服务器和浏览器的交互过程，在此基础上参考浏览器端实现的用户操作界面，实现了与浏览器端功能相同的客户端。

经过测试，运行稳定，可以投放使用。

关键词:

云协作平台；JHscheduler；客户端；QTGUI

DesignandImplementationoftheClientOnCloudCollaborationPlatform

Abstract

Cloudcollaborationplatformthetheoreticalbasisfromthecloudcomputing,Internetbased,willbesharedhardwareandsoftwareresourcesandinformationbeprovidedtocomputersandotherequipment,andmanagementofthesedevices.Cloudcollaborationplatformsusuallyprovidegenericapplicationthroughthebrowser,softwareanddatacanbestoredinthedatacenter.Thebrowserandtheservermechanismwhilesimplifyingtheclientcomputerload,reducethecostandtheworkloadofsystemmaintenanceandupgrading,reducingtheoverallcostoftheuser,butthebrowserandserverstructurealsohassomecannotovercomeitsownshortcomings.Nowadays,thebrowsertypes,uneven,somegoodandsomebad,so,itraisesaverydifficultproblem--thebrowserbalancecompatibilityissues,thereisaroottoaskimportant:

ifsomeapplicationsintothecloudplatformlocal,thebrowseristightlyelbow.Theclienthassolvedaboveproblems.

Inthispaper,cloudbasedcollaborationplatform,thebrowserfunctionsasadesignreference,Throughresourceschedulingmanagementsystem（JHscheduler），focusedonsavingthesystemsoftwareandhardwareresources,avoidbrowsercompatibilityproblemscausedbycloudbrowser,enhancedcollaborationplatformfront-endscalability,andtoincreasethenumberofinteractivetoolsfortheclientandserver,improvetherecognitionofcloudcooperationplatformuserexperienceandproductthe.Theclientisrealizedbytheobserverpatternisadesignpattern,usingtheThrifttoQTGUIasthedevelopmentframework,Boost,andthreepartytoollibrary.Todowiththebrowserandtheserverishighlyconsistent,compatibleinterface,userfrontendsoftwarecloudcollaborationplatformandclientcharacteristics.

Throughseveralmonthsofstudyandwork,familiarwiththeoperationmechanismoftheserver,andtheserverandbrowserinteractionprocess,theuseroperationinterfaceonthebasisofbrowserimplementation,achievedwiththesameclientbrowserfunction.Aftertesting,stableoperation,canbeputinuse.

KeyWords:

Cloudcollaborationplatform;JHscheduler;Theclient;QTGUI

1绪论

1.1课题设计背景

2006年8月9日，google首席执行官埃里克·施密特（EricSchmidt）在搜索引擎大会（SES San Jose 2006）首次提出“云计算”（CloudComputing）的概念。

之后包括Google、IBM、雅虎、惠普、英特尔，以及戴尔在内的世界顶尖级IT公司为推动和发展云计算不遗余力，争先恐后。

云计算理论逐步成熟和结构趋于完整，基于云计算的产品应运而生，云协作平台就是其中的一个典型。

云协作平台其理论依据来源于云计算，自然是基于互联网，将共享的软硬件资源和信息,通过运行于服务器端的资源调度管理系统（JHscheduler）统一协调，按需提供给计算机和其他设备，并对这些设备进行管理。

云协作平台通常提供通用的通过浏览器访问的应用，软件和数据可存储在数据中心。

浏览器和服务器结构虽然简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本，然而浏览器和服务器结构也有一些自身无法克服的缺点。

现如今，浏览器种类繁多，良莠不齐，这样，就引发了一个很难做到平衡的问题——浏览器的兼容性问题，还有一个更为重要的是：

如果要将本地的一些应用程序集成到云协作平台，浏览器就显得捉襟见肘了。

客户端的出现恰恰解决了以上问题。

1.2课题设计的目的和意义

浏览器能够实现的功能，客户端同样也可以实现，但这并不是说，客户端就可以完全取代浏览器来实现与云平台的交互，完成生产实践。

浏览器旨在其灵活性，可移动性，而客户端旨在其高度的集成性，以及其普适性，即可以集成操作系统上的所有应用，更方便的为用户提供服务；普适性在于操作系统的较为明确，程序开发有的放矢，这样也大大降低了开发成本，和开发、维护周期。

客户端/服务器结构能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器，这样可以提高工作效率，缩短工作时间，使云平台能够更高效、快捷的工作。

客户端/服务器结构在数据安全性方面也明显高于浏览器/服务器结构，可以较为容易地实现多层认证。

1.3课题的主要研究工作

由于云协作平台的浏览器版已经实现，而客户端版是尽量和浏览器版保持一致，因此，熟悉服务器端运行机制和浏览器版的基本结构使得开发客户端变得有的放矢，也就相对容易的多了。

服务器端的为javaweb实现，客户端实现是用C++实现，两者之间需要一个可以相互调用的接口。

除此之外，从服务器端拿到的数据列表需要显示在客户端的对话框页面，而这些数据列表是在浏览器端已经

实现的，在对话框上能够直接显示web页面，就使得开发工作量减轻许多，这样也为客户端节省了响应时间。

1.4论文结构安排

本论文共有四章，具体组织如下：

第一章：

通过对已经实现的云协作平台的Web端功能分析，提出客户端开发的目的和意义，此次研究的主要任务，以及本次论文的组织结构。

第二章：

主要介绍资源调度管理系统（JHscheduler）和开发本系统所采用的相关技术，包括设计模式中的观察者模式，Thrift库、Boost库以及QTGUI编程等。

第三章：

系统需求分析，其中包括用户需求分析、性能需求分析、数据需求分析。

第四章：

系统概要设计，从软件体系结构，数据库设计，系统功能模块设计等方面叙述。

第五章：

系统详细设计与实现，用户登录页面，操作界面，以及各个功能模块的实现。

第六章：

系统测试

第七章：

总结

2课题设计的关键技术

云协作平台是通过资源调度管理系统，统一对用户作业需求进行动态管理、分配资源的协作的系统。

一般是基于互联网，也有用专业网的情况。

云协作平台的主要功能是：

分工合作、资源控制、作业管理等功能。

2.1资源调度管理系统简介

资源调度管理系统（以下称JHScheduler）是一个集资源监控和分布式应用调度为一体的云计算的基础架构管理中间件，利用JHScheduler可以快速的建立起一个完整企业级应用服务平台。

它可以监控、调度、管理网络上的10台到上千台不同操作系统的服务器、工作站和虚拟机，把它们作为云计算资源集中管理起来为多种类型的应用软件提供统一服务平台。

JHScheduler具有完备的和可扩展的资源定义、监控等功能，包括硬件资源、操作系统、软件许可证资源、存储资源等等，并且为应用软件提供多种接口来使用这些云计算资源，从而轻易实现应用软件的并行分布式运行和弹性计算，完成从传统的以服务器为中心的计算模式向以应用服务为中心的计算模式迁移。

JHScheduler支持多种类型应用软件的通用中间件，包括CAD/CAE软件、制造业设计软件、石油勘探分析软件、模拟仿真软件、科学计算软件等，这些不同类型的应用软件可以同时使用JHScheduler管理的应用集群，从而实现计算资源的充分共享。

由JHScheduler管理的应用集群系统具有高可用性，用户可以配置多个管理节点，即使只有一个JHScheduler管理节点正常运行，应用集群服务也不会宕机，做到应用服务的全天候可用，为用户和应用提供最佳的计算服务。

为了使计算资源得到高效使用，JHScheduler内置多种高效的管理调度策略，包括先来先服务、用户/用户组资源配额管理、基于队列的优先级设置、资源公平共享调度、独占式作业调度、抢占式作业调度等，基于这些策略，JHScheduler把应用软件的每一次执行实例作为一个作业来进行调度和管理，并为管理员和作业的用户提供方便的作业状态监控和友好的用户界面。

此外，JHScheduler还有可扩展的接口，可以为特殊的管理调度需求定制策略。

由JHScheduler管理的应用集群系统具有高可靠性，作业在没有资源的情况下将在系统中排队等待资源。

即使在执行过程中计算节点出现故障，JHScheduler仍然可以把作业重新调度到其它机器上继续执行。

作为云计算基础架构产品，JHScheduler与其基础之上的Webportal产品提供安全友好的用户管理和使用界面；通过与JHLicenseManager集成管理应用集

群系统的许可证资源，并提供专门针对许可证资源的先进调度；通过与JHAnalytics集成为用户提供丰富的资源使用和作业调度报表功能，以及详尽灵活的计费系统。

JHScheduler产品的总体结构如图2.1所示。

图2.1JHscheduler总体结构图

2.2观察者模式简介

2.2.1概述

　　观察者模式有时被称作发布/订阅模式，观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。

这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。

2.2.2解决的问题

　　将一个系统分割成一个一些类相互协作的类有一个不好的副作用，那就是需要维护相关对象间的一致性。

我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。

观察者就是解决这类的耦合关系的。

2.2.3模式中的角色

　　抽象主题（Subject）：

它把所有观察者对象的引用保存到一个聚集里，每个主题都可以有任何数量的观察者。

抽象主题提供一个接口，可以增加和删除观察者对象。

　　具体主题（ConcreteSubject）：

将有关状态存入具体观察者对象；在具体主题内部状态改变时，给所有登记过的观察者发出通知。

　　抽象观察者（Observer）：

为所有的具体观察者定义一个接口，在得到主题通知时更新自己。

　　具体观察者（ConcreteObserver）：

实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题状态协调。

2.2.4模式解读

实现观察者模式有很多形式，比较直观的一种是使用一种“注册——通知——撤销注册”的形式。

如图2.2详细的描述了这样一种过程：

图2.2观察者模式实现过程

观察者

（Observer）将自己注册到被观察对象（Subject）中，被观察对象将观察者存放在一个容器（Container）里。

被观察

被观察对象发生了某种变化（如图中的SomeChange），从容器中得到所有注册过的观察者，将变化通知观察者。

撤销观察

观察者告诉被观察者要撤销观察，被观察者从容器中将观察者去除。

观察者将自己注册到被观察者的容器中时，被观察者不应该过问观察者的具体类型，而是应该使用观察者的接口。

这样的优点是：

假定程序中还有别的观察者，那么只要这个观察者也是相同的接口实现即可。

一个被观察者可以对应多个观察者，当被观察者发生变化的时候，他可以将消息一一通知给所有的观察者。

基于接口，而不是具体的实现——这一点为程序提供了更大的灵活性。

2.2.5模式总结

优点

　　观察者模式解除了主题和具体观察者的耦合，让耦合的双方都依赖于抽象，而不是依赖具体。

从而使得各自的变化都不会影响另一边的变化。

缺点

依赖关系并未完全解除，抽象通知者依旧依赖抽象的观察者。

适用场景

当一个对象的改变需要给变其它对象时，而且它不知道具体有多少个对象有待改变时。

一个抽象某型有两个方面，当其中一个方面依赖于另一个方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。

2.3Thrift库

2.3.1Thrift简介

Thrift是一个跨语言的服务部署框架，最初由Facebook于2007年开发，2008年进入Apache开源项目。

Thrift通过一个中间语言（IDL,接口定义语言）来定义RPC的接口和数据类型，然后通过一个编译器生成不同语言的代码（目前支持C++,Java,Python,PHP,Ruby,Erlang,Perl,Haskell,C#,Cocoa,Smalltalk和OCaml）,并由生成的代码负责RPC协议层和传输层的实现。

2.3.2Thrift架构

图2.3Thrift架构

Thrift实际上是实现了C/S模式，通过代码生成工具将接口定义文件生成服务器端和客户端代码（可以为不同语言），从而实现服务端和客户端跨语言的支持。

用户在Thrift描述文件中声明自己的服务，这些服务经过编译后会生成相应语言的代码文件，然后用户实现服务（客户端调用服务，服务器端提服务）便可以了。

其中protocol（协议层,定义数据传输格式，可以为二进制或者XML等）和transport（传输层，定义数据传输方式，可以为TCP/IP传输，内存共享或者文件共享等）被用作运行时库。

2.3.3支持的数据传输格式、数据传输方式和服务模型

（1）支持的传输格式

TBinaryProtocol–二进制格式.

TCompactProtocol–压缩格式

TJSONProtocol–JSON格式

TSimpleJSONProtocol–提供JSON只写协议,生成的文件很容易通过脚本语言解析。

TDebugProtocol–使用易懂的可读的文本格式，以便于debug

（2）支持的数据传输方式

TSocket-阻塞式socker

TFramedTransport–以frame为单位进行传输，非阻塞式服务中使用。

TFileTransport–以文件形式进行传输。

TMemoryTransport–将内存用于I/O.java实现时内部实际使用了简单的ByteArrayOutputStream。

TZlibTransport–使用zlib进行压缩，与其他传输方式联合使用。

当前无java实现。

（3）支持的服务模型

TSimpleServer–简单的单线程服务模型，常用于测试

TThreadPoolServer–多线程服务模型，使用标准的阻塞式IO。

TNonblockingServer–多线程服务模型，使用非阻塞式IO（需使用TFramedTransport数据传输方式）

2.3.4Thrift使用

（1）编译安装：

./configure–》make–》makeinstall

（2）利用Thrift部署服务

主要流程：

编写服务说明，保存到.thrift文件–》根据需要，编译.thrift文件，生成相应的语言源代码–》根据实际需要，编写client端和server端代码。

a）.thrift文件编写

一般将服务放到一个.thrift文件中，服务的编写语法与C语言语法基本一致，在.thrift文件中有主要有以下几个内容：

变量声明、数据声明（struct）和服务接口声明（service,可以继承其他接口）。

b）client端和server端代码编写

client端和server端代码要调用编译.thrift生成的中间文件。

在client端，用户自定义CalculatorClient类型的对象（用户在.thrift文件中声明的服务名称是Calculator，则生成的中间代码中的主类为CalculatorClient），该对象中封装了各种服务，可以直接调用（如client.ping（））,然后thrift会通过封装的rpc调用server端同名的函数。

在server端，需要实现在.thrift文件中声明的服务中的所有功能，以便处理client发过来的请求。

如图2.4所示。

图2.4client端和server端的书写

2.4Boost库

2.4.1Boost库简介

Boost库是一个可移植、提供源代码的C++库，作为标准库的后备，是C++标准化进程的开发引擎之一。

Boost库由C++标准委员会库工作组成员发起，其中有些内容有望成为下一代C++标准库内容。

在C++社区中影响甚大，是不折不扣的“准”标准库。

Boost由于其对跨平台的强调，对标准C++的强调，与编写平台无关。

大部分Boost库功能的使用只需包括相应头文件即可，少数（如正则表达式库，文件系统库等）需要链接库。

2.4.2Boost的log库

（1）相关概念

∙日志记录：

一个独立的消息包，这个消息包还不是实际写到日志里的消息，它只是一个候选的消息。

∙属性：

日志记录中的一个消息片。

∙属性值：

那就是上面所说的属性的值了，可以是各种数据类型。

∙日志槽（LOGSINK）：

日志写向的目标，它要定义日志被写向什么地方，以及如何写。

∙日志源：

应用程序写日志时的入口，其实质是一个logger对象的实例。

∙日志过滤器：

决定日志记录是否要被记录的一组判断。

∙日志格式化：

决定日志记录输出的实际格式。

∙日志核心：

维护者日志源、日志槽、日志过滤器等之间的关系的一个全局中的实体。

主要在初始化logginglibrary时用到。

（2）框架结构

Boostlog的框架结构如图2.5所示：

图2.5Boostlog的框架结构

A）应用程序在图的右侧，通过一个或多个logger实例发送日志消息。

B）应用程序也可以出现在左侧，那就是一个日志的显示实例了。

C）一个日志记录的数据中会包括许多属性。

属性基本上是一个函数，它的返回值就是属性值。

比如时间不仅是一个函数（也是一个属性）。

D）有三种类型的属性集：

全局的，特定线程的，特定源的。

前两个是由loggingcore来维护的，所以不用再初始化。

全局属性集中的属性被连接到所以的日志对象上。

线程属性集中的属性会连接到把它注册到属性集时的那个线程。

源属性集由初始化日志的源来维护的，它会连接到一个特定的源上。

当一个源初始化日志对象的时候，它会从上述的三个属性集的所有属性中得到属性值。

这些值会在将来处理。

如果在不同的属性集中有相同的属性名字的时候就会造成冲突，解决冲突的方法是全局属性集的优先级最低，源属性集的优先级最高。

高优先级的属性会覆盖低优先级的属性。

E）当组合属性值的时候，loggingcore来决定一个属性是否要被送到sink中，这就是过滤。

有两层过滤，首先应用的是全局中过滤，全局过滤用来快速的过滤掉那些不需要的日志记录。

然后就是sink指定的过滤了。

每个sink都有单独的过滤器。

sink过滤器允许将一个日志记录定向到一个指定的sink。

F）如果一个日志记录至少通过了一个sink的话，它就可以用了。

这时候就是日志消息格式化的时候了。

格式化完成的日志消息和属性值一起被送到接收它们的sink中。

G）如上图所示，sink被分为前端和后端两个部分。

这是为了抽象sink的通用功能，如过滤和线程同步。

前端由日志库提供，用户不大可能再去实现它。

而后端很可能是在日志库的外面，它来实现对日志记录的处理。

如写文件，发送到网络等。

日志库提供了大部分通常用到的后端程序。

2.5QTGUI简介

2.5.1QTGUI简介和功能特点

QT提供了设计师工具，可以很方便的使用鼠标拖拽的方