基于云协作平台的客户端设计与实现本科毕业论文(编辑修改稿)

基于云协作平台的客户端设计与实现本科毕业论文(编辑修改稿)内容摘要：

本地的一些应用程序集成到 云 协作 平台，浏览器就显得捉襟见肘了。 客户端的出现恰恰解决了以上问题。 课题设计的目的和意义 浏览器能够实现的功能，客户端同样也可以实现，但这并不是说，客户端就可以完全取代浏览器来实现与云平台的交互，完成生产实践。 浏览器旨在其灵活性，可移动性，而客户端旨在其高度的集成性，以及其普适性，即可以集成操作系统上的所有应用，更方便的为用户提供服务；普适性在于操作系统的较为明确，程序开发有的放矢，这样也大大降低了开发成本，和开发、维护周期。 客户端 /服务器结构能充分发挥客户端 PC 的处理能力，很多工作可以在客户端处理后再提交给服务器，这样可以提高工作效率，缩短工作时间，使云平台能够更高效 、快捷的工作。 客户端 /服务器结构在数据安全性方面也明显高于浏览器 /服务器结构，可以较为容易地实现多层认证。 课题的主要研究工作 由于云协作平台的浏览器版已经实现，而客户端版是尽量和浏览器版保持一致，因此， 熟悉服务器端运行机制 和浏览器版的基本结构使得开发客户端 变得有的放矢，也就相对容易的多了。 服务器端的为 java web 实现，客户端实现是用C++实现，两者之间需要一个可以相互调用的接口。 除此之外，从服务器端拿到的数据列表需要显示在客户端的对话框页面，而这些数据列表是在浏览器端已经 2 实现的，在对话框上能够 直接显示 web 页面，就使得开 发工作量减轻许多，这样也为客户端节省了响应时间。 论文结构安排 本论文共有四章，具体组织如下： 第一章：通过对已经实现的云协作平台的 Web 端功能分析，提出客户端开发的目的和意义， 此次研究的主要任务，以及本次论文的组织 结构。 第二章：主要介绍 资源调度管理系统（ JH scheduler）和 开发本系统所采用的相关技术，包括 设计模式中的 观察 者 模式， Thrift 库 、 Boost 库 以及 QT GUI 编程等。 第三章： 系统需求分析，其中包括用户 需求分析、 性能需求分析 、 数据需求分析。 第四章 ： 系统概要设计 ，从软件体系结构，数据库设计，系统功能模块设计等方面叙述。 第五章：系统详细设计与实现 ，用户登录页面，操作界面，以及各个功能模块的实现。 第六章：系统测试 第七章：总结 2 课题设计的关键技术 3 2 课题设计的关键技术 云协作平台 是通过资源调度管理系统，统一对用户作业需求进行动态管理、分配资源的协作的系统。 一般是基于互联网，也有用专业网的情况。 云协作平台的主要功能是：分工合作、资源控制、作业管理等功能。 资源调度管理系统简介 资源调度管理系统 (以下称 JH Scheduler)是一个集资源监控和分布式应用调度为一体的云计算的基础架构管理中间件，利用 JH Scheduler 可以快速的建立起一个完整企业级应用服务平台。 它可以监控、调度、管理网络上的 10 台到上千台不同操作系统的服务器、工作站和虚拟机，把它们作为云计算资源集中管理起来为多种类型的应用软件提供统一服务平台。 JH Scheduler 具有完备的和可扩展的资源定义、监控等功能，包括硬件资源、操作系统、软件许可证资源、存储资源等等，并且为应用软件提供多种接口来使用这些云计算资源，从而轻易实现应用软件的并行分布式运行和弹性 计算，完成从传统的以服务器为中心的计算模式向以应用服务为中心的计算模式迁移。 JH Scheduler 支持多种类型应用软件的通用中间件，包括 CAD/CAE 软件、制造业设计软件、石油勘探分析软件、模拟仿真软件、科学计算软件等，这些不同类型的应用软件可以同时使用 JH Scheduler 管理的应用集群，从而实现计算资源的充分共享。 由 JH Scheduler 管理的应用集群系统具有高可用性，用户可以配置多个管理节点，即使只有一个JH Scheduler 管理节点正常运行，应用集群服务也不会宕机，做到应用服务的全天候可 用，为用户和应用提供最佳的计算服务。 为了使计算资源得到高效使用， JH Scheduler 内置多种高效的管理调度策略，包括先来先服务、用户 /用户组资源配额管理、基于队列的优先级设置、资源公平共享调度、独占式作业调度、抢占式作业调度等，基于这些策略， JH Scheduler把应用软件的每一次执行实例作为一个作业来进行调度和管理，并为管理员和作业的用户提供方便的作业状态监控和友好的用户界面。 此外， JH Scheduler 还有可扩展的接口，可以为特殊的管理调度需求定制策略。 由 JH Scheduler 管理的应用 集群系统具有高可靠性，作业在没有资源的情况下将在系统中排队等待资源。 即使在执行过程中计算节点出现故障， JH Scheduler 仍然可以把作业重新调度到其它机器上继续执行。 作为云计算基础架构产品， JH Scheduler 与其基础之上的 Web portal 产品提供安全友好的用户管理和使用界面；通过与 JH License Manager 集成管理应用集 群系统的许可证资源，并提供专门针对许可证资源的先进调度；通过与 JH Analytics 集成为用户提供丰富的资源使用和作业调度报表功能，以及详尽灵活的计费系统。 JH Scheduler 产品的总体结构如图 所示。 4 图 JH scheduler 总体结构图 观察者模式简介 概述 观察者模式 有时被称作发布 /订阅模式，观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。 这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。 解决的问题 将一个系统分割成一个一些类相互协作的类有一个不好的副作用，那就是需要维护相关对象间的一致性。 我们不希望为了维持一致性而使各类紧密耦合， 这样会给维护、扩展和重用都带来不便。 观察者就是解决这类的耦合关系的。 模式中的角色 抽象主题（ Subject）：它把所有观察者对象的引用保存到一个聚集里，每个主题都可以有任何数量的观察者。 抽象主题提供一个接口，可以增加和删除观察者对象。 具体主题（ ConcreteSubject）：将有关状态存入具体观察者对象；在具体主题内部状态改变时，给所有登记过的观察者发出通知。 抽象观察者（ Observer）：为所有的具体观察者定义一个接口，在得到主题通知时更新自己。 5 具体观察者（ ConcreteObserver）：实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题状态协调。 模式解读 实现观察者模式有很多形式，比较直观的一种是使用一种 ―注册 ——通知——撤销注册 ‖的形式。 如 图 详细的描述了这样一种过程 ： 图 观察者模式实现过程 观察者 （ Observer）将自己注册到被观察对象（ Subject）中，被观察对象将观察者存放在一个容器（ Container）里。 被观察 被观察对象发生了某种变化（如图中的 SomeChange），从容器中得到所有注册过的观察者，将变 化通知观察者。 撤销观察 观察者告诉被观察者要撤销观察，被观察者从容器中将观察者去除。 观察者将自己注册到被观察者的容器中时，被观察者不应该过问观察者的具体类型，而是应该使用观察者的接口。 这样的优 点是：假定程序中还有别的观察者，那么只要这个观察者也是相同的接口实现即可。 一个被观察者可以对应多个观察者，当被观察者发生变化的时候，他可以将消息 一一通知给所有的观察者。 基于接口，而不是具体的实现 ——这一点为程序提供了更大的灵活性。 模式总结 优点 观察者模式解除了主题和具体观察者的耦合，让耦合的 双方都依赖于抽象，而不是依赖具体。 从而使得各自的变化都不会影响另一边的变化。 缺点 依赖关系并未完全解除，抽象通知者依旧依赖抽象的观察者。 6 适用场景 当一个对象的改变需要给变其它对象时，而且它不知道具体有多少个对象有待改变时。 一个抽象某型有两个方面，当其中一个方面依赖于另一个方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立地改变和复用。 Thrift 库 Thrift 简介 Thrift 是一个跨语言的服务部署框架，最初由 Facebook于 2020 年开发， 2020年进入 Apache 开源项目。 Thrift 通过一个中 间语言 (IDL, 接口定义语言 )来定义RPC 的接口和数据类型，然后通过一个编译器生成不同语言的代码（目前支持C++,Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C, Cocoa, Smalltalk 和OCaml） ,并由生成的代码负责 RPC 协议层和传输层的实现。 Thrift 架构 图 Thrift 架构 Thrift 实际上是实现了 C/S 模式，通过代码生 成工具将接口定义文件生成服务器端和客户端代码（可以为不同语言）， 从而实现服务端和客户端跨语 言的支持。 用户在 Thrift 描述文件中声明自己的服务，这些服务经 过编译后会生成相应语言的代码文件，然后用户实现服务（客户端调用服务，服务器端提服务）便可以了。 其中 protocol（协议层 , 定义数据传输格式，可以为二进制或者 XML等）和 transport（传输层，定义数据传输方式，可以为 TCP/IP 传输，内存共享或者文件共享等）被用 作运行时库。 7 支持的数据传输格式、数据传输方式和服务模型 （ 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 数据传输方式） Thrift 使用 （ 1） 编译安装： ./configure –》 make –》 make install （ 2） 利用 Thrift 部署服务 主要流程：编写服务说明，保存到 .thrift 文件 –》根据需要，编译 .thrift 文件，生成相应的语言源代码 –》根据实际需要，编写 client 端和 server 端代码。 a） .thrift 文件编写 一般将服务放到一个 .thrift 文件中，服务的编写语法与 C 语言语法基本一致，在 .thrift 文件中有主要有以下几个内容：变量声明、数据声明（ struct）和服务接口声明（ service, 可以继承其他接口）。 b） client 端和 server 端代码编写 client 端和 server 端代码要调用编译 .thrift 生成的中间文件。 在 client 端，用户自定义 CalculatorClient 类型的对象（用户在 .thrift 文件中声明的服务名称是 Calculator，则生成的中间代码中的主类为 CalculatorClient），该对象中封装了各种服务，可以直接调用（如 ()） ,然后 thrift 会通过封装的 rpc 调用 server 端同名的函数。 在 server 端，需要实现在 .thrift 文件中声明的服务中的所有功能，以便处理 client 发过来的请求。 如图 所示。 8 图 client 端和 server 端的书写 Boost 库 Boost 库简介 Boost 库是一个可移植、提供源代码的 C++库，作为标准库的后备，是 C++标准化进程的开发引擎之一。 Boost 库由 C++标准委员会库工作组成员发起，其中有些内容有望成为下一代 C++标准库内容。 在 C++社区中影响甚大，是不折不扣的 ―准 ‖标准库。 Boost 由于其对跨平台的强调，对标准 C++的强调，与编写平台无关。 大部分 Boost 库功能的使用只需包括相应头文件即可，少数（如正则表达式库，文件系统库等）需要链 接库。 Boost 的 log 库 （ 1） 相关。