王 昭 鄧浩江 胡琳琳 郭志川

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

0 引 言

HTML5標(biāo)準(zhǔn)使得Web應(yīng)用功能越來越強(qiáng)大的同時(shí)，Web應(yīng)用也越來越復(fù)雜，資源消耗越來越多，而智能終端中計(jì)算、存儲(chǔ)、電量等多種資源受限，這可能會(huì)降低應(yīng)用性能，影響用戶體驗(yàn)。計(jì)算遷移是解決此類問題的有效方法，它通過將應(yīng)用中計(jì)算密集型任務(wù)遷移到服務(wù)端運(yùn)行來提高應(yīng)用性能，提升用戶體驗(yàn)。

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

圖1 Web Worker工作原理圖

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

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

1 相關(guān)研究

目前HTML5 Web Worker遷移相關(guān)的研究主要分成兩類。一類是對(duì)Web應(yīng)用透明的Web Worker遷移方法；另一類是對(duì)Web應(yīng)用不透明的Web Worker遷移方法。Web Worker透明遷移的優(yōu)點(diǎn)是對(duì)Web應(yīng)用透明，無需改動(dòng)Web應(yīng)用，缺點(diǎn)是實(shí)現(xiàn)復(fù)雜，依賴Web平臺(tái)的特殊實(shí)現(xiàn)；Web Worker非透明遷移的優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，可輕易跨平臺(tái)，缺點(diǎn)是需要改動(dòng)Web應(yīng)用。

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

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

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

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

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

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

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

2 Web Worker遷移系統(tǒng)設(shè)計(jì)

2.1 遷移到單個(gè)服務(wù)器

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

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

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

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

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

表1 通信消息類型和功能

圖3是客戶端主線程、服務(wù)端主線程及其對(duì)應(yīng)的一個(gè)Web Worker線程之間的工作流程圖。下面結(jié)合工作流程圖對(duì)Web Worker遷移過程進(jìn)行分析。

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

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

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

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

2.2 遷移到Docker Swarm集群

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

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

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

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

3 實(shí)驗(yàn)結(jié)果及分析

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

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

圖5 RayTracing應(yīng)用中Web Worker遷移效果對(duì)比圖

圖6 ImageDecrypt應(yīng)用中Web Worker遷移效果對(duì)比圖

通過對(duì)實(shí)驗(yàn)結(jié)果進(jìn)行分析可以得出以下結(jié)論：

1) 遷移到單個(gè)服務(wù)器對(duì)應(yīng)用性能有全面提升，主要是因?yàn)榉?wù)器性能比raspberry Pi 3性能強(qiáng)，遷移后的通信開銷和計(jì)算開銷要小于不遷移時(shí)的計(jì)算開銷。

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

3) 從遷移到單個(gè)服務(wù)器的測(cè)試結(jié)果來看，如果集群中單個(gè)節(jié)點(diǎn)性能強(qiáng)于客戶端節(jié)點(diǎn)性能，worker數(shù)量少的時(shí)候，遷移到集群應(yīng)該也會(huì)有性能提升。

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

5) Ray Tracing應(yīng)用在不遷移的情況下，worker數(shù)量為4時(shí)，性能最優(yōu)，這和文獻(xiàn)[9]中得出的結(jié)論一致，因?yàn)閞aspberry Pi 3是四核的，當(dāng)worker數(shù)量多于4時(shí)，多個(gè)worker之間的資源競(jìng)爭(zhēng)使得Web應(yīng)用性能下降。

4 結(jié) 語

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