【文章內(nèi)容簡(jiǎn)介】 本地的一些應(yīng)用程序集成到 云 協(xié)作 平臺(tái)，瀏覽器就顯得捉襟見肘了。客戶端的出現(xiàn)恰恰解決了以上問題。 課題設(shè)計(jì)的目的和意義 瀏覽器能夠?qū)崿F(xiàn)的功能，客戶端同樣也可以實(shí)現(xiàn)，但這并不是說，客戶端就可以完全取代瀏覽器來實(shí)現(xiàn)與云平臺(tái)的交互，完成生產(chǎn)實(shí)踐。瀏覽器旨在其靈活性，可移動(dòng)性，而客戶端旨在其高度的集成性，以及其普適性，即可以集成操作系統(tǒng)上的所有應(yīng)用，更方便的為用戶提供服務(wù)；普適性在于操作系統(tǒng)的較為明確，程序開發(fā)有的放矢，這樣也大大降低了開發(fā)成本，和開發(fā)、維護(hù)周期。客戶端 /服務(wù)器結(jié)構(gòu)能充分發(fā)揮客戶端 PC 的處理能力，很多工作可以在客戶端處理后再提交給服務(wù)器，這樣可以提高工作效率，縮短工作時(shí)間，使云平臺(tái)能夠更高效 、快捷的工作。 客戶端 /服務(wù)器結(jié)構(gòu)在數(shù)據(jù)安全性方面也明顯高于瀏覽器 /服務(wù)器結(jié)構(gòu)，可以較為容易地實(shí)現(xiàn)多層認(rèn)證。 課題的主要研究工作 由于云協(xié)作平臺(tái)的瀏覽器版已經(jīng)實(shí)現(xiàn)，而客戶端版是盡量和瀏覽器版保持一致，因此， 熟悉服務(wù)器端運(yùn)行機(jī)制 和瀏覽器版的基本結(jié)構(gòu)使得開發(fā)客戶端 變得有的放矢，也就相對(duì)容易的多了。服務(wù)器端的為 java web 實(shí)現(xiàn)，客戶端實(shí)現(xiàn)是用C++實(shí)現(xiàn)，兩者之間需要一個(gè)可以相互調(diào)用的接口。除此之外，從服務(wù)器端拿到的數(shù)據(jù)列表需要顯示在客戶端的對(duì)話框頁面，而這些數(shù)據(jù)列表是在瀏覽器端已經(jīng) 2 實(shí)現(xiàn)的，在對(duì)話框上能夠 直接顯示 web 頁面，就使得開 發(fā)工作量減輕許多，這樣也為客戶端節(jié)省了響應(yīng)時(shí)間。 論文結(jié)構(gòu)安排 本論文共有四章，具體組織如下： 第一章：通過對(duì)已經(jīng)實(shí)現(xiàn)的云協(xié)作平臺(tái)的 Web 端功能分析，提出客戶端開發(fā)的目的和意義， 此次研究的主要任務(wù)，以及本次論文的組織 結(jié)構(gòu) 。 第二章：主要介紹 資源調(diào)度管理系統(tǒng)（ JH scheduler）和 開發(fā)本系統(tǒng)所采用的相關(guān)技術(shù)，包括 設(shè)計(jì)模式中的 觀察 者 模式， Thrift 庫 、 Boost 庫 以及 QT GUI 編程等。 第三章： 系統(tǒng)需求分析，其中包括用戶 需求分析、 性能需求分析 、 數(shù)據(jù)需求分析 。 第四章 ： 系統(tǒng)概要設(shè)計(jì) ，從軟件體系結(jié)構(gòu)，數(shù)據(jù)庫設(shè)計(jì)，系統(tǒng)功能模塊設(shè)計(jì)等方面敘述。 第五章：系統(tǒng)詳細(xì)設(shè)計(jì)與實(shí)現(xiàn) ，用戶登錄頁面，操作界面，以及各個(gè)功能模塊的實(shí)現(xiàn)。 第六章：系統(tǒng)測(cè)試 第七章：總結(jié) 2 課題設(shè)計(jì)的關(guān)鍵技術(shù) 3 2 課題設(shè)計(jì)的關(guān)鍵技術(shù) 云協(xié)作平臺(tái) 是通過資源調(diào)度管理系統(tǒng)，統(tǒng)一對(duì)用戶作業(yè)需求進(jìn)行動(dòng)態(tài)管理、分配資源的協(xié)作的系統(tǒng)。一般是基于互聯(lián)網(wǎng)，也有用專業(yè)網(wǎng)的情況。云協(xié)作平臺(tái)的主要功能是：分工合作、資源控制、作業(yè)管理等功能。 資源調(diào)度管理系統(tǒng)簡(jiǎn)介 資源調(diào)度管理系統(tǒng) (以下稱 JH Scheduler)是一個(gè)集資源監(jiān)控和分布式應(yīng)用調(diào)度為一體的云計(jì)算的基礎(chǔ)架構(gòu)管理中間件，利用 JH Scheduler 可以快速的建立起一個(gè)完整企業(yè)級(jí)應(yīng)用服務(wù)平臺(tái)。它可以監(jiān)控、調(diào)度、管理網(wǎng)絡(luò)上的 10 臺(tái)到上千臺(tái)不同操作系統(tǒng)的服務(wù)器、工作站和虛擬機(jī)，把它們作為云計(jì)算資源集中管理起來為多種類型的應(yīng)用軟件提供統(tǒng)一服務(wù)平臺(tái)。 JH Scheduler 具有完備的和可擴(kuò)展的資源定義、監(jiān)控等功能，包括硬件資源、操作系統(tǒng)、軟件許可證資源、存儲(chǔ)資源等等，并且為應(yīng)用軟件提供多種接口來使用這些云計(jì)算資源，從而輕易實(shí)現(xiàn)應(yīng)用軟件的并行分布式運(yùn)行和彈性 計(jì)算，完成從傳統(tǒng)的以服務(wù)器為中心的計(jì)算模式向以應(yīng)用服務(wù)為中心的計(jì)算模式遷移。 JH Scheduler 支持多種類型應(yīng)用軟件的通用中間件，包括 CAD/CAE 軟件、制造業(yè)設(shè)計(jì)軟件、石油勘探分析軟件、模擬仿真軟件、科學(xué)計(jì)算軟件等，這些不同類型的應(yīng)用軟件可以同時(shí)使用 JH Scheduler 管理的應(yīng)用集群，從而實(shí)現(xiàn)計(jì)算資源的充分共享。 由 JH Scheduler 管理的應(yīng)用集群系統(tǒng)具有高可用性，用戶可以配置多個(gè)管理節(jié)點(diǎn)，即使只有一個(gè)JH Scheduler 管理節(jié)點(diǎn)正常運(yùn)行，應(yīng)用集群服務(wù)也不會(huì)宕機(jī)，做到應(yīng)用服務(wù)的全天候可 用，為用戶和應(yīng)用提供最佳的計(jì)算服務(wù)。 為了使計(jì)算資源得到高效使用， JH Scheduler 內(nèi)置多種高效的管理調(diào)度策略，包括先來先服務(wù)、用戶 /用戶組資源配額管理、基于隊(duì)列的優(yōu)先級(jí)設(shè)置、資源公平共享調(diào)度、獨(dú)占式作業(yè)調(diào)度、搶占式作業(yè)調(diào)度等，基于這些策略， JH Scheduler把應(yīng)用軟件的每一次執(zhí)行實(shí)例作為一個(gè)作業(yè)來進(jìn)行調(diào)度和管理，并為管理員和作業(yè)的用戶提供方便的作業(yè)狀態(tài)監(jiān)控和友好的用戶界面。此外， JH Scheduler 還有可擴(kuò)展的接口，可以為特殊的管理調(diào)度需求定制策略。 由 JH Scheduler 管理的應(yīng)用 集群系統(tǒng)具有高可靠性，作業(yè)在沒有資源的情況下將在系統(tǒng)中排隊(duì)等待資源。即使在執(zhí)行過程中計(jì)算節(jié)點(diǎn)出現(xiàn)故障， JH Scheduler 仍然可以把作業(yè)重新調(diào)度到其它機(jī)器上繼續(xù)執(zhí)行。 作為云計(jì)算基礎(chǔ)架構(gòu)產(chǎn)品， JH Scheduler 與其基礎(chǔ)之上的 Web portal 產(chǎn)品提供安全友好的用戶管理和使用界面；通過與 JH License Manager 集成管理應(yīng)用集 群系統(tǒng)的許可證資源，并提供專門針對(duì)許可證資源的先進(jìn)調(diào)度；通過與 JH Analytics 集成為用戶提供豐富的資源使用和作業(yè)調(diào)度報(bào)表功能，以及詳盡靈活的計(jì)費(fèi)系統(tǒng)。 JH Scheduler 產(chǎn)品的總體結(jié)構(gòu)如圖 所示。 4 圖 JH scheduler 總體結(jié)構(gòu)圖 觀察者模式簡(jiǎn)介 概述 觀察者模式 有時(shí)被稱作發(fā)布 /訂閱模式，觀察者模式定義了一種一對(duì)多的依賴關(guān)系，讓多個(gè)觀察者對(duì)象同時(shí)監(jiān)聽某一個(gè)主題對(duì)象。這個(gè)主題對(duì)象在狀態(tài)發(fā)生變化時(shí)，會(huì)通知所有觀察者對(duì)象，使它們能夠自動(dòng)更新自己。 解決的問題 將一個(gè)系統(tǒng)分割成一個(gè)一些類相互協(xié)作的類有一個(gè)不好的副作用，那就是需要維護(hù)相關(guān)對(duì)象間的一致性。我們不希望為了維持一致性而使各類緊密耦合， 這樣會(huì)給維護(hù)、擴(kuò)展和重用都帶來不便。觀察者就是解決這類的耦合關(guān)系的。 模式中的角色 抽象主題（ Subject）：它把所有觀察者對(duì)象的引用保存到一個(gè)聚集里，每個(gè)主題都可以有任何數(shù)量的觀察者。抽象主題提供一個(gè)接口，可以增加和刪除觀察者對(duì)象。 具體主題（ ConcreteSubject）：將有關(guān)狀態(tài)存入具體觀察者對(duì)象；在具體主題內(nèi)部狀態(tài)改變時(shí)，給所有登記過的觀察者發(fā)出通知。 抽象觀察者（ Observer）：為所有的具體觀察者定義一個(gè)接口，在得到主題通知時(shí)更新自己。 5 具體觀察者（ ConcreteObserver）：實(shí)現(xiàn)抽象觀察者角色所要求的更新接口，以便使本身的狀態(tài)與主題狀態(tài)協(xié)調(diào)。 模式解讀 實(shí)現(xiàn)觀察者模式有很多形式，比較直觀的一種是使用一種 ―注冊(cè) ——通知——撤銷注冊(cè) ‖的形式。 如 圖 詳細(xì)的描述了這樣一種過程 ： 圖 觀察者模式實(shí)現(xiàn)過程 觀察者 （ Observer）將自己注冊(cè)到被觀察對(duì)象（ Subject）中，被觀察對(duì)象將觀察者存放在一個(gè)容器（ Container）里。 被觀察 被觀察對(duì)象發(fā)生了某種變化（如圖中的 SomeChange），從容器中得到所有注冊(cè)過的觀察者，將變 化通知觀察者。 撤銷觀察 觀察者告訴被觀察者要撤銷觀察，被觀察者從容器中將觀察者去除。 觀察者將自己注冊(cè)到被觀察者的容器中時(shí)，被觀察者不應(yīng)該過問觀察者的具體類型，而是應(yīng)該使用觀察者的接口。這樣的優(yōu) 點(diǎn)是：假定程序中還有別的觀察者，那么只要這個(gè)觀察者也是相同的接口實(shí)現(xiàn)即可。一個(gè)被觀察者可以對(duì)應(yīng)多個(gè)觀察者，當(dāng)被觀察者發(fā)生變化的時(shí)候，他可以將消息 一一通知給所有的觀察者?；诮涌?，而不是具體的實(shí)現(xiàn) ——這一點(diǎn)為程序提供了更大的靈活性。 模式總結(jié) 優(yōu)點(diǎn) 觀察者模式解除了主題和具體觀察者的耦合，讓耦合的 雙方都依賴于抽象，而不是依賴具體。從而使得各自的變化都不會(huì)影響另一邊的變化。 缺點(diǎn) 依賴關(guān)系并未完全解除，抽象通知者依舊依賴抽象的觀察者。 6 適用場(chǎng)景 當(dāng)一個(gè)對(duì)象的改變需要給變其它對(duì)象時(shí)，而且它不知道具體有多少個(gè)對(duì)象有待改變時(shí)。 一個(gè)抽象某型有兩個(gè)方面，當(dāng)其中一個(gè)方面依賴于另一個(gè)方面，這時(shí)用觀察者模式可以將這兩者封裝在獨(dú)立的對(duì)象中使它們各自獨(dú)立地改變和復(fù)用。 Thrift 庫 Thrift 簡(jiǎn)介 Thrift 是一個(gè)跨語言的服務(wù)部署框架，最初由 Facebook于 2020 年開發(fā)， 2020年進(jìn)入 Apache 開源項(xiàng)目。 Thrift 通過一個(gè)中 間語言 (IDL, 接口定義語言 )來定義RPC 的接口和數(shù)據(jù)類型，然后通過一個(gè)編譯器生成不同語言的代碼（目前支持C++,Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C, Cocoa, Smalltalk 和OCaml） ,并由生成的代碼負(fù)責(zé) RPC 協(xié)議層和傳輸層的實(shí)現(xiàn)。 Thrift 架構(gòu) 圖 Thrift 架構(gòu) Thrift 實(shí)際上是實(shí)現(xiàn)了 C/S 模式，通過代碼生 成工具將接口定義文件生成服務(wù)器端和客戶端代碼（可以為不同語言）， 從而實(shí)現(xiàn)服務(wù)端和客戶端跨語 言的支持。用戶在 Thrift 描述文件中聲明自己的服務(wù)，這些服務(wù)經(jīng) 過編譯后會(huì)生成相應(yīng)語言的代碼文件，然后用戶實(shí)現(xiàn)服務(wù)（客戶端調(diào)用服務(wù)，服務(wù)器端提服務(wù)）便可以了。其中 protocol（協(xié)議層 , 定義數(shù)據(jù)傳輸格式，可以為二進(jìn)制或者 XML等）和 transport（傳輸層，定義數(shù)據(jù)傳輸方式，可以為 TCP/IP 傳輸，內(nèi)存共享或者文件共享等）被用 作運(yùn)行時(shí)庫 。 7 支持的數(shù)據(jù)傳輸格式、數(shù)據(jù)傳輸方式和服務(wù)模型 （ 1）支持的傳輸格式 TBinaryProtocol – 二進(jìn)制格式 . TCompactProtocol – 壓縮格式 TJSONProtocol – JSON 格式 TSimpleJSONProtocol –提供 JSON 只寫協(xié)議 , 生成的文件很容易通過腳本語言解析。 TDebugProtocol – 使用易懂的可讀的文本格式，以便于 debug （ 2）支持的數(shù)據(jù)傳輸方式 TSocket 阻塞式 socker TFramedTransport – 以 frame 為單位進(jìn)行傳輸，非阻塞式服務(wù)中使用。 TFileTransport – 以文件形式進(jìn)行傳輸。 TMemoryTransport – 將內(nèi)存用于 I/O. java 實(shí)現(xiàn)時(shí)內(nèi)部實(shí)際使用了簡(jiǎn)單的ByteArrayOutputStream。 TZlibTransport – 使用 zlib 進(jìn)行壓縮， 與其他傳輸方式聯(lián)合使用。當(dāng)前無 java實(shí)現(xiàn)。 （ 3）支持的服務(wù)模型 TSimpleServer – 簡(jiǎn)單的單線程服務(wù)模型，常用于測(cè)試 TThreadPoolServer – 多線程服務(wù)模型，使用標(biāo)準(zhǔn)的阻塞式 IO。 TNonblockingServer – 多線程服務(wù)模型，使用非阻塞式 IO（需使用TFramedTransport 數(shù)據(jù)傳輸方式） Thrift 使用 （ 1） 編譯安裝： ./configure –》 make –》 make install （ 2） 利用 Thrift 部署服務(wù) 主要流程：編寫服務(wù)說明，保存到 .thrift 文件 –》根據(jù)需要，編譯 .thrift 文件，生成相應(yīng)的語言源代碼 –》根據(jù)實(shí)際需要，編寫 client 端和 server 端代碼。 a） .thrift 文件編寫 一般將服務(wù)放到一個(gè) .thrift 文件中，服務(wù)的編寫語法與 C 語言語法基本一致，在 .thrift 文件中有主要有以下幾個(gè)內(nèi)容：變量聲明、數(shù)據(jù)聲明（ struct）和服務(wù)接口聲明（ service, 可以繼承其他接口）。 b） client 端和 server 端代碼編寫 client 端和 server 端代碼要調(diào)用編譯 .thrift 生成的中間文件。 在 client 端，用戶自定義 CalculatorClient 類型的對(duì)象（用戶在 .thrift 文件中聲明的服務(wù)名稱是 Calculator，則生成的中間代碼中的主類為 CalculatorClient），該對(duì)象中封裝了各種服務(wù)，可以直接調(diào)用（如 ()） ,然后 thrift 會(huì)通過封裝的 rpc 調(diào)用 server 端同名的函數(shù)。 在 server 端，需要實(shí)現(xiàn)在 .thrift 文件中聲明的服務(wù)中的所有功能，以便處理 client 發(fā)過來的請(qǐng)求。 如圖 所示 。 8 圖 client 端和 server 端的書寫 Boost 庫 Boost 庫簡(jiǎn)介 Boost 庫是一個(gè)可移植、提供源代碼的 C++庫，作為標(biāo)準(zhǔn)庫的后備，是 C++標(biāo)準(zhǔn)化進(jìn)程的開發(fā)引擎之一。 Boost 庫由 C++標(biāo)準(zhǔn)委員會(huì)庫工作組成員發(fā)起，其中有些內(nèi)容有望成為下一代 C++標(biāo)準(zhǔn)庫內(nèi)容。在 C++社區(qū)中影響甚大，是不折不扣的 ―準(zhǔn) ‖標(biāo)準(zhǔn)庫。 Boost 由于其對(duì)跨平臺(tái)的強(qiáng)調(diào)，對(duì)標(biāo)準(zhǔn) C++的強(qiáng)調(diào)，與編寫平臺(tái)無關(guān)。大部分 Boost 庫功能的使用只需包括相應(yīng)頭文件即可，少數(shù)（如正則表達(dá)式庫，文件系統(tǒng)庫等）需要鏈 接庫。 Boost 的 log 庫 （ 1） 相關(guān)