一種多服務端HTML5 Web Worker遷移系統(tǒng)設計與實現(xiàn)

王 昭 鄧浩江 胡琳琳 郭志川

1(中國科學院聲學研究所國家網(wǎng)絡新媒體工程技術研究中心 北京 100190)2(中國科學院大學 北京 100190)

0 引 言

HTML5標準使得Web應用功能越來越強大的同時，Web應用也越來越復雜，資源消耗越來越多，而智能終端中計算、存儲、電量等多種資源受限，這可能會降低應用性能，影響用戶體驗。計算遷移是解決此類問題的有效方法，它通過將應用中計算密集型任務遷移到服務端運行來提高應用性能，提升用戶體驗。

Web Worker是HTML5提供的一個JavaScript多線程解決方案，Web Worker在當前JavaScript的主線程中，使用Worker類加載一個JavaScript文件來創(chuàng)建一個新的工作線程。Web Worker工作原理如圖1所示，Web應用主線程UI Thread和Web Worker子線程獨立工作，并通過消息機制進行通信，子線程不能訪問應用的DOM樹結(jié)構(gòu)。HTML5 Web Worker引入之前，所有計算均在應用主線程進行，一些耗時的計算任務會影響應用的及時響應。引入Web Worker后，可以將一些大計算量代碼交由Web Worker并行執(zhí)行，使得應用主線程可以及時響應。

圖1 Web Worker工作原理圖

Web Worker相對獨立，而且其執(zhí)行的是計算相關任務，不涉及UI相關的操作，這些特性使其成為面向web應用計算遷移的重點研究對象?，F(xiàn)有Web Worker遷移[1，2，3，4，5，6，7，8]都是將Web Worker遷移到單種服務端，即單個服務器端或由多個設備組成的類似集群的服務端。但不同種類的服務端各有優(yōu)勢，遷移到單個服務器對服務器的處理能力要求較高，遷移到局域網(wǎng)內(nèi)單個服務器帶來的時延小，但應用場景受限，遷移到云端單個服務器可能會帶來比較大的延時；遷移到多個設備組成的集群可以充分利用多個設備的資源，對單個設備的處理能力要求不高，但是實現(xiàn)復雜度高，而且對集群穩(wěn)定性要求較高，遷移到云端集群同樣可能會帶來比較大的延時。

智能終端設備移動性強，網(wǎng)絡狀況波動相對較大，這導致單種服務端很可能無法滿足智能終端Web Worker遷移的需要。為此，本文設計并實現(xiàn)了一種多服務端HTML5 Web Worker遷移系統(tǒng)，充分利用多種服務端的優(yōu)勢和資源，將Web Worker遷移到單個服務器和由周圍終端設備組成Docker Swarm集群兩種服務端，并通過實驗驗證了遷移系統(tǒng)的有效性。

1 相關研究

目前HTML5 Web Worker遷移相關的研究主要分成兩類。一類是對Web應用透明的Web Worker遷移方法；另一類是對Web應用不透明的Web Worker遷移方法。Web Worker透明遷移的優(yōu)點是對Web應用透明，無需改動Web應用，缺點是實現(xiàn)復雜，依賴Web平臺的特殊實現(xiàn)；Web Worker非透明遷移的優(yōu)點是實現(xiàn)簡單，可輕易跨平臺，缺點是需要改動Web應用。

文獻[1]中提出一種對Web應用透明的Web Worker遷移方法，該方法通過在Web瀏覽器中添加代理模塊將Web Worker創(chuàng)建請求發(fā)送到服務端，同時添加遷移決策模塊決定是否向云端遷移。文獻[2]中同樣提出了一種通過代理模塊實現(xiàn)的Web Worker透明遷移方法，但沒有詳細設計和具體實現(xiàn)。

文獻[3-6]中遷移思想和方法基本類似，都是使用javascript實現(xiàn)的非透明遷移。文獻[4]中提出了WWF框架，將客戶端Web Worker遷移到單個PC端。文獻[3]對WWF框架的設計與實現(xiàn)進行了詳細描述，其基本思想是自定義Web Worker接口來代替標準Web Worker接口，接口實現(xiàn)中基于HTML5 websocket通信機制將Web Worker創(chuàng)建請求及參數(shù)發(fā)送給服務端，服務端接收請求后創(chuàng)建并運行Web Worker，并將運行結(jié)果通過websocket返回給客戶端。其主要不足在于該框架需要對Web應用做多處改動，Web應用中除了要包含實現(xiàn)的WWF庫，還要對每一行Web Worker創(chuàng)建代碼進行修改，對應用開發(fā)者不夠友好。

文獻[5]中提出的WWOF框架和WWF基本思想一樣，但是WWOF設計更加詳細，對WWF中的通信機制進行了完善，還增加了錯誤控制，并對遷移過程中的時間代價和能量代價進行了分析。Web應用只需增加一行代碼包含WWOF庫即可實現(xiàn)Web Worker遷移。文獻[6]將客戶端Web Worker遷移到云端服務器，其基本思想和文獻[3]一致。

文獻[7]在文獻[3]中提出的WWF框架的基礎上進行了改進，提出了A-WWF，將Web Worker遷移到由多個設備組成的類似集群的服務端。它將WWF服務端作為一個manager，manager可以提供遷移服務，也可以將客戶端的遷移請求轉(zhuǎn)發(fā)給其他的服務節(jié)點，可以提供遷移服務的節(jié)點需要在manager節(jié)點上進行服務注冊，通信方式同樣使用websocket。其不足之處在于需要對Web應用做多處改動，而且實現(xiàn)比較復雜。

文獻[8]對文獻[3]中提出的遷移框架的通信方式做了改變，不使用HTML5 websocket，而是使用HTML5 WebRTC。在上述提到的使用websocket實現(xiàn)的遷移方法中，服務端需要有HTML5 websocket server端實現(xiàn)來完成遷移，客戶端和服務端的通信方式是典型的C/S模式。使用HTML5 WebRTC后，遷移過程中的通信方式從websocket定義的C/S模式變成了P2P模式，客戶端和服務端都使用WebRTC進行通信，而且服務端不再需要進行復雜的設計，只需要有瀏覽器便可實現(xiàn)遷移。但是，HTML5 WebRTC是為實時音視頻通信設計的，開銷比較大，遷移效果不是很好。

此外，除了HTML5 Web Worker遷移相關研究，文獻[9]研究了Web應用中HTML5 Web Worker數(shù)量、CPU數(shù)量/架構(gòu)和應用性能之間的關系，指導Web應用開發(fā)者創(chuàng)建合適數(shù)量的Web Worker來獲得最佳應用性能。

目前關于Web Worker遷移的研究都是將客戶端Web Worker遷移到單種服務端，但是不同的服務端各有優(yōu)勢，單種服務端很可能無法滿足智能終端的遷移需要，而且如果存在多種可用的服務端資源。現(xiàn)有研究無法充分利用這些服務端資源，根據(jù)需要選取合適的服務端進行Web Worker遷移。因此，面向HTML5 Web Worker非透明遷移，本文首先實現(xiàn)了將Web Worker遷移到單個服務器，然后又提出并實現(xiàn)了一種新的遷移思路，將客戶端Web Worker遷移到周圍多個終端設備組成的Docker Swarm集群上，Docker Swarm集群中的多個節(jié)點共同為一個客戶端提供遷移服務。Docker作為一種輕量級虛擬化技術，非常適用于嵌入式集群，而Docker Swarm在Docker虛擬化基礎上又增加了資源編排功能。與遷移到云端服務器相比，該方法有更小的服務延遲；與遷移到客戶端周圍單個強力設備相比，該方法可以充分利用周圍多個處理能力一般的終端的資源。

2 Web Worker遷移系統(tǒng)設計

2.1 遷移到單個服務器

圖2是遷移到單個服務器的系統(tǒng)架構(gòu)圖，包含客戶端和服務端兩部分?？蛻舳擞蒞eb瀏覽器、自定義實現(xiàn)JS框架和Web應用三部分組成。服務端由JS運行環(huán)境、服務端主線程和Web Worker子線程三部分組成?？蛻舳撕头斩耸褂肏TML5 websocket進行通信。

圖2 遷移到單個服務器系統(tǒng)架構(gòu)圖

客戶端中，Web瀏覽器支持Web應用運行，目前主流的瀏覽器均支持HTML5標準，它包含各HTML5標準的平臺實現(xiàn)。圖2中顯示的是該系統(tǒng)涉及到的Web Worker和websocket平臺實現(xiàn)。Web瀏覽器除了包含各HTML5標準平臺實現(xiàn)，還向上提供各HTML5標準對應的JS接口以供Web應用調(diào)用，如Web應用可以通過調(diào)用標準的Web Worker接口來使用Web瀏覽器提供的HTML5 Web Worker功能。自定義實現(xiàn)JS框架包含兩部分：第一部分對標準Web Worker接口進行自定義實現(xiàn)；第二部分Client websocket使用HTML5 socket和服務端進行通信。Web應用通過調(diào)用標準Web Worker接口來創(chuàng)建Web Worker，現(xiàn)有Web應用只需添加一行代碼包含自定義實現(xiàn)JS框架即可實現(xiàn)Web Worker遷移，其他代碼無需任何改動。

服務端中，JS運行環(huán)境支持服務端JavaScript代碼運行，如HTML5 websocket服務端實現(xiàn)，HTML5 Web Worker標準實現(xiàn)等。服務端主線程包含兩部分：第一部分Server websocket接受客戶端websocket連接請求和消息；第二部分調(diào)用標準Web Worker接口創(chuàng)建Web Worker子線程。Web Worker子線程接收服務端主線程消息并將執(zhí)行結(jié)果返回給服務端主線程。

客戶端和服務端使用標準HTML5 websocket進行通信。針對不同的功能，一共定義了三種不同的消息類型，其類型和功能如表1所示。通過JS消息對象的特定屬性標志不同消息類型，由于HTML5 websocket只能發(fā)送數(shù)字和字符串，因此消息對象發(fā)送前先使用JSON.stringify()進行序列化，接收到消息后先使用JSON.parse()進行反序列化。

表1 通信消息類型和功能

圖3是客戶端主線程、服務端主線程及其對應的一個Web Worker線程之間的工作流程圖。下面結(jié)合工作流程圖對Web Worker遷移過程進行分析。

圖3 遷移系統(tǒng)中各線程工作流程圖

Web Worker標準接口包括Web Worker創(chuàng)建接口、通信接口和銷毀接口。Web Worker創(chuàng)建時需要一個JS文件名作為參數(shù)，因此JS框架中Web Worker創(chuàng)建接口自定義實現(xiàn)時，首先和服務端創(chuàng)建websocket連接，連接成功后將創(chuàng)建Web Worker需要的JS文件的內(nèi)容或該JS文件的url通過websocket消息發(fā)送給服務端，這一過程如圖3中①②③所示。Web Worker通信接口和銷毀接口自定義實現(xiàn)中，直接通過websocket將相應的消息發(fā)送給服務端。這一過程分別如圖3中⑤和⑨所示。

服務端主線程接收到websocket消息后先進行消息類型解析，如果消息類型是Web Worker創(chuàng)建消息，則解析消息內(nèi)容，獲取創(chuàng)建Web Worker需要的JS文件，然后調(diào)用標準Web Worker創(chuàng)建接口創(chuàng)建Web Worker子線程，這一過程如圖3中④所示。如果消息類型是通信消息，則解析消息內(nèi)容，并將消息內(nèi)容通過調(diào)用標準Web Worker消息發(fā)送接口將內(nèi)容發(fā)送給相應的Web Worker子線程，這一過程如圖3中⑥所示。如果消息類型是銷毀消息，則調(diào)用標準Web Worker銷毀接口銷毀相應的Web Worker子線程，這一過程如圖3中⑩所示。當Web Worker子線程運行結(jié)束后，將運行結(jié)果通過Web Worker消息接口發(fā)送給服務端主線程，服務端主線程接收到消息后，獲取消息內(nèi)容并通過websocket將運行結(jié)果轉(zhuǎn)發(fā)給客戶端主線程，客戶端主線程接收到消息后，Web應用中相應的消息響應函數(shù)得到響應，這一過程如圖3中⑦⑧所示。

由客戶端JS框架中自定義Web Worker創(chuàng)建接口實現(xiàn)可知，客戶端每個Web Worker創(chuàng)建請求對應客戶端和服務端一個websocket連接，對應服務端一個Web Worker子線程。因此，服務端特定websocket連接接收消息后，可以輕易將消息轉(zhuǎn)發(fā)給特定的Web Worker子線程，或者銷毀掉特定的Web Worker子線程。因為每個websocket連接對應服務端一個Web Worker子線程，當websocket連接關閉或出錯關閉時，即使客戶端沒有發(fā)送Web Worker銷毀消息，同樣需要銷毀掉相應的Web Worker子線程以節(jié)約服務端資源。

2.2 遷移到Docker Swarm集群

圖4是客戶端web應用中HTML5 Web Worker遷移到Docker Swarm集群系統(tǒng)架構(gòu)圖。其中客戶端部分和遷移到單個服務器時相同。Docker Swarm集群作為服務端由多個工作節(jié)點組成，每個工作節(jié)點中可以創(chuàng)建多個容器，每個容器中JS運行環(huán)境支持服務端主線程運行來提供遷移服務。Docker Swarm集群中有一個Swarm manager節(jié)點負責管理集群中的多個節(jié)點，它接收客戶端的遷移請求，并將遷移請求轉(zhuǎn)發(fā)給合適的工作節(jié)點去做，Swarm manager節(jié)點本身也是工作節(jié)點。

圖4 遷移到Docker Swarm集群系統(tǒng)架構(gòu)圖

遷移到單個Docker Swarm集群和遷移到單個服務器的不同主要在于服務端實現(xiàn)。首先設計創(chuàng)建容器需要的腳本Dockerfile，在Dockerfile中安裝必要的軟件及組件，并運行服務端遷移服務代碼；然后創(chuàng)建Docker Swarm集群服務，選擇創(chuàng)建服務副本數(shù)量，副本數(shù)量即集群中要創(chuàng)建的容器數(shù)量，表示有多少容器提供遷移服務。多個容器在多個工作節(jié)點上的分布和多個Web Worker遷移請求的在多個容器中的分配機制是由Docker Swarm按照一定的負載均衡策略決定的。

遷移到Docker Swarm集群和遷移到單個服務器相比除了服務端實現(xiàn)不同外，服務方式也不同，客戶端Web應用中可能有多個Web Worker需要遷移，遷移到單個服務器的服務方式是利用一個強力節(jié)點接收并完成所有Web Worker的遷移請求，而遷移到Docker Swarm集群的服務方式是將多個Web Worker的遷移請求分發(fā)到集群中的多個工作節(jié)點來完成，對每個工作節(jié)點的處理能力要求不高。

3 實驗結(jié)果及分析

客戶端設備采用的是配置為1 GB內(nèi)存和64位四核1.2 GHz處理器的raspberry Pi 3，Web平臺為Chromium瀏覽器。服務端有兩種：一種是局域網(wǎng)中的單個服務器結(jié)點Dell PowerEdge R730服務器；另一種是Docker Swarm集群，集群由局域網(wǎng)內(nèi)四個raspberry Pi 3節(jié)點組成，每個節(jié)點創(chuàng)建容器并提供服務端遷移功能，集群中單個節(jié)點的性能和客戶端節(jié)點的性能是相同的。兩種服務端中JS運行環(huán)境均為基于V8引擎的Node.JS。Web應用測試用例有2個。測試用例1為使用Web Worker的圖形渲染應用Ray Tracing(http://nerget.com/rayjs-mt/rayjs.html)。測試用例2 Image Decrypt使用Web Worker進行圖形解密。Ray Tracing應用中不同數(shù)量的worker對應任務量是相同的；Image Decrypt應用中不同數(shù)量的worker對應的任務量是不同的，worker數(shù)量越多任務量越大。

實驗主要測試Web應用在遷移和不遷移情況下Web Worker的耗時，具體是從第一個worker創(chuàng)建開始計時，到所有worker完成計算結(jié)束計時。為了避免隨機異常值帶來的影響，圖中的數(shù)據(jù)為多次測試數(shù)據(jù)取均值。兩個Web應用的測試結(jié)果分別如圖5、圖6所示。

圖5 RayTracing應用中Web Worker遷移效果對比圖

圖6 ImageDecrypt應用中Web Worker遷移效果對比圖

通過對實驗結(jié)果進行分析可以得出以下結(jié)論：

1) 遷移到單個服務器對應用性能有全面提升，主要是因為服務器性能比raspberry Pi 3性能強，遷移后的通信開銷和計算開銷要小于不遷移時的計算開銷。

2) 遷移到集群時，在worker數(shù)量多于4時，性能提升明顯，集群的優(yōu)勢在于多個節(jié)點幫助客戶端進行計算，一個worker至少分配到集群中一個節(jié)點運行，worker數(shù)量少時集群的優(yōu)勢顯現(xiàn)不出來，通信開銷和計算開銷大于不遷移時的計算開銷；當worker數(shù)量多時，可以充分利用多個節(jié)點的計算能力幫助客戶端進行計算，因此性能提升明顯。

3) 從遷移到單個服務器的測試結(jié)果來看，如果集群中單個節(jié)點性能強于客戶端節(jié)點性能，worker數(shù)量少的時候，遷移到集群應該也會有性能提升。

4) 遷移到客戶端周圍單個服務器比遷移到Docker Swarm集群整體效果要好一些，但差別不大，這和單個服務器處理能力以及Docker Swarm集群中節(jié)點處理能力相關。遷移到周圍單個服務器比遷移到云端服務器有更小的服務延遲，因此，遷移到Docker Swarm集群和遷移到云端服務器效果應該不相上下或差別更小。

5) Ray Tracing應用在不遷移的情況下，worker數(shù)量為4時，性能最優(yōu)，這和文獻[9]中得出的結(jié)論一致，因為raspberry Pi 3是四核的，當worker數(shù)量多于4時，多個worker之間的資源競爭使得Web應用性能下降。

4 結(jié) 語

本文設計了一種多服務端HTML5 Web Worker遷移系統(tǒng)，實現(xiàn)了將智能終端Web應用中HTML5 Web Worker遷移到單個服務器和由周圍終端設備組成的Docker Swarm集群兩種服務端，經(jīng)過實驗驗證，該系統(tǒng)可以充分利用多種服務端資源，有效提升智能終端web應用性能。下一步的工作方向為對實現(xiàn)的遷移做更全面的測試，真實測試向Docker Swarm集群遷移和向云端服務器遷移的效果對比，然后研究遷移過程中的遷移策略，動態(tài)決定是否將Web Worker遷移到服務端及遷移到何種服務端。