DOI:10.6245/JLIS.2015.412/655
以前端瀏覽器為中心之雲端運算服務 模型研究
余宛儒
國立政治大學資訊管理研究所碩士 E-mail：102356019@nccu.edu.tw
關鍵詞：巨量資料；前端開發；雲端運算
【摘要】
本研究針對目前最新技術發展趨勢，提出一個以瀏覽器為中心的雲端運算服務模型。本研究 稱之「雲端服務交換器系統」，解決後端巨量資料透過緩衝區送至前端瀏覽器頁面顯示之問題並 改善傳輸速度。本研究整合 MongoDB、AngularJS、Socket.IO、Kafka、Node.js 五項元素。本 研究解決前端中JavaScript 與網頁互動之困難、前後端開發語言相容性問題、巨量資料需求造成 的伺服器負載量、前後端即時通訊效能等問題，最後達成建置網站之目的。
緒論
以下說明研究動機與研究目的。
研究動機
在目前網路世代之重大改變，即雲端與大數據，大數據的3Vs 定義是目前為止最受推崇 且最廣為人知的說法。3Vs 由 Gartner 分析師 Doug Laney 最早在 2001 年時提出，分別代表龐 大資料量（volume）、資料傳輸速度（velocity）、資料類型（variety）。
從最初定義的大數據特性到現在的廣泛運用，大數據與雲端運算已透過各種應用進入人 類生活，不管大數據是否有利可圖，無可否認的是，現今社會中已脫離不了大數據，這類雲 端應用只會越來越成熟，而生在網路世代的人們，更應該注意這些應用與改變。
近年來，網際網路快速發展，加上不同規格手持裝置出現，前端開發面臨的挑戰越來越 大，要考慮用戶端移動裝置性能的問題，也需保有傳統企業的應用。
從開發的角度而言，巨量使用者需求與海量資料的傳遞是網頁應用程式會遇到的，前端 開發語言與方式日新月異，也越來越多元，前端開發更因為Node.js 的技術興起，逐漸由單純 的前端邁向全端的開發模式。
在網路大數據，雲端應用以及行動裝置的配合下，互聯網成為目前熱門的研究議題，雲 端運算的發展需要企業的建設管理運維等模式去配套。本研究也認為，鎖定開發標準便是在 這環境下最需要達成的事情。
事實上，現今存在的前端架構與框架中在開發上有許多問題，包括前端 JavaScript 與網 頁互動之困難、前後端開發語言相容性問題、巨量需求造成的伺服器負載量問題、前後端即 時通訊之速度問題及前端與後端整合大量雲端服務的高度彈性。因此，在雲端環境下，若能 解決這些問題，便是在網路世界對開發者的一大福音。
研究目的
本研究希望從前端的角度，重新定義雲端運算服務，並發展出一套在雲端運算環境下，擁 有巨量使用者之介面管理架構。在文獻探討中探討影響前端開發的因素，並達成下列研究目的：
一、 針對目前最新技術發展趨勢，提出一個以瀏覽器為中心的雲端運算服務模型。
二、 針對此雲端運算服務模型，對前後端問題提出解決辦法。包括 JavaScript 與網頁互動之 困難、前後端開發語言相容性問題、巨量需求造成的伺服器負載量問題、前後端即時通 訊之速度問題及保留前端與後端整合大量雲端服務的高度彈性。
三、 依循本架構，實際建置網站。
文獻探討
以下文獻探討將分別說明雲端運算、雲端運算服務，以及行動裝置架構整合。
雲端運算
雲端運算是一種基於網際網路的運算方式，利用共享軟硬體資源和資訊的方式，並按需 求提供給電腦和其他裝置。Google 臺灣總經理簡立峰說：「雲端運算不是一個全新的技術，
而是一個概念，因為雲端運算本身並不代表任何一項資訊科技的技術，它是一種電腦運算的 概念。簡單的說，就是把所有的資料全部丟到網路上處理」。林姿華（2010）提到，雲端運算 中的「雲」即是我們最常使用的網際網路；「端」則是指使用者端。意指使用者運用網路服務 來完成事情的方式，雲端運算的目標是不安裝軟體，所使用的資料都來自於雲端，使用者只 需連上雲端的設備與簡單介面就完成了。
雲端運算服務
根據美國國家標準和技術研究院的定義（NIST, 2009），雲端運算服務應具備以下五個基 礎特徵：隨需應變自助服務（On-demand self-service）、隨時隨地用任何網路裝置存取（Broad
network access）、多人共享資源池（Resource pooling）、快速重新部署靈活度（Rapid elasticity）， 和被監控與量測的服務（Measured service）。
在網際網路中，雲端運算透過簡單的方式，提供服務給消費者與企業（亞州雲公司，
2011）。消費者希望取得雲端環境下帶來的資訊，企業更希望能從雲端與大數據的海量資料 中，幫助創新與加快決策，但成本一直是企業重要的考量因素，如何降低成本同時又快速的 回應客戶需求，一直是企業追求的方向之一。當然，雲端環境會遇到許多的困難，上述提到 之五種特性又被網際網路中的傳輸與速度大大影響，本研究希望針對傳輸上容易發生的問 題，加以優化處理。
在這五個特徵裡，臺灣大學計算機及資訊網路中心主任孫雅麗（2011）認為，雲端服務 有別於現在或是過往的運算服務，一個很重要的特點是如何實踐在「雲端服務的提供者能夠 提供使用者一個好像有無窮資源，可以隨時回應使用者需求」的概念。本研究認為，雲服務 提供者必須能回應使用者創造或架設在雲端還降的應用，比方說電子商務網站，這類應用藥 提供及時的需求且保證提供經濟、適當、快速的資源整合服務。
人們對雲端的概念與想像，已從三層服務提升為任何手持裝置透過網路就可從「雲」中 享受到需要的服務。雲端運算還有下列特徵：基於虛擬化技術快速部署資源或獲得服務、減 少用戶終端的處理負擔、降低了用戶對於資訊科技專業知識的依賴。
為了滿足以上三點特徵，且符合目前世代中行動裝置帶來的改變，用戶端的處理負擔多 集中於設備的不同或者運算量差異，本研究認為目前行動運算蔚為趨勢，想要化行動力為競 爭力，勢必要制訂出一套行動策略，選擇適當的行動開發工具，建立所需要的行動應用。
行動裝置與架構整合
面對今日多樣化的行動設備平台及各種大小尺寸的手機、平板，適應多樣化的前端畫面 將無可避免。雖然顯示裝置各式各樣，以致畫面需依不同裝置有所調整，但其實要顯示的內 容及背後的商業邏輯是相同的，這時強調畫面與資料封裝分離的MVC（Model-View-Controller）
架構就派上用場。MVC 架構下，檢視畫面有著可變動與擴充的彈性，易於重用的模型，擁有 良好的專業分工優點，已深獲各大軟體平台及社群所擁抱。
此外，前端畫面若使用響應式網頁技術（Responsive Web Design），同一網站的圖文內容 與資料庫能在不同尺寸或解析度的設備或螢幕上，根據使用者的裝置，以符合版面大小的樣 式來顯示網頁內容。
伴隨雲端運算普及，使得多數企業不僅已經高度接受並積極部署雲端架構，更為了將資 源使用效率拓展至極致，也開始對於混合雲懷抱更大憧憬。有許多廠商積極提倡像是OpenStack
等開放標準，讓企業用戶自行確保其應用程式與資訊都遵循一致性規律，以作為融合式雲端 架構的發展基礎。
本研究除了將雲端運算環境下作為考量，在文獻探討後，將雲端運算中特性融入在架構的 設計裡，包括動態資源調度、即時資訊呈現、虛擬化，同時保有行動裝置整合的特性，提出以 前端瀏覽器為中心之雲端運算服務模型，實際依循架構做開發，並做系統測試驗證系統效能。
研究架構
針對目前最新技術發展趨勢，提出一個以瀏覽器為中心的雲端運算服務模型。從前端角 度重新對雲運算做巨觀的定義，本研究稱之「雲端服務交換器系統」，並將之視為研究架構。
本研究將「雲端服務交換器系統」定義為以瀏覽器為核心，前端擁有大量的使用者，也就是 擁有極大量的需求（request），搭配一個極高速的中間交換器，連接後端無限量的雲運算服務 跟資料。當後端資料要送到前端時，先將運算結果送至緩衝區（buffer）儲存，再從緩衝區取 得資料送至前端，如圖1 所示。
圖1 雲端服務交換器系統
圖中資料流動方向依照編號進行，圖中編號為資料流動方向。
前端需求
1 使用者需求：前端會有大量瀏覽器同時向後端送出大量使用者需求，交由高速交換器 處理。
2 建立連線，將需求送至後端：高速交換器與後端建立連線，將需求送至後端。
後端回傳
3.1 回傳完成信號：後端依照需求運算完畢，向交換器回傳做完的訊號並同時進行 3.2。
3.2 將運算結果回傳至緩衝區：後端依照需求運算完畢，將適合前端看到的運算結果儲存 到緩衝區並同時進行3.1。
4 由使用者端去緩衝區取得資料：高速交換器接收到運算完畢通知，立即至緩衝區取得前 端頁面需要之資料。
5 頁面呈現回傳結果：使用者端將高速交換器回傳之資料在頁面中顯示。
研究架構分析
根據上節之定義，先提出中間交換器的特性並選出適合的交換器，在傳輸上，中間交換 器將此架構分成兩大部分，接著將提出中間交換器兩端待解決之問題，像是使用者如何快速 連接大量資料，或如何順暢的在前端呈現結果等，從傳輸管道與開發管理兩個角度詳述問題，
並列出解決辦法。
中間交換器
本研究在對雲運算服務定義時，特別增加了一個「交換器」的角色，一般認為的交換器 稱為Switch，在 Switch 中將每個端口看成獨立，Switch 知道封包分別該傳給哪台電腦。本研 究將中間交換器定義為「分為前後兩端，前端支援非常多不同使用者，依照使用者的需求，
對另一後端的雲進行高速的存取與資訊交換」，中間的交換器不進行運算，它處理的事情是從 使用者端取得巨量的需求，透過此交換器，取得後端無限量的雲端服務，故本研究根據其特 性，選出最適當的中間交換器。
（一）中間交換器之選擇問題
在巨量使用者的環境下，前端會擁有海量的使用者要求，中間交換器需要快速特性，但 不需要處理大量IO，只是做為一個交換中心，用以快速處理大量需求，並依照各需求的要求 取得相對應得資訊並回傳。在傳統的網路技術服務下，當每一個使用者新增一個連線請求時，
就會產生一個新的執行緒，或者等待可用的執行緒，產生新的執行緒時，會占用系統內存記 憶體，最終占用了所有的可用內存。
在雲端環境下，擁有非常多的使用者，而且每個使用者請求不一定只有一個，因此，如 何處理大量需求並減少伺服器負擔是在雲運算環境下刻不容緩的。
（二）中間交換器之選擇辦法
本研究選擇Node.js 作為中間交換器。
在語言上，Node.js 就是 JavaScript，寫程式的方法就與平常在前端寫 JavaScript 相同，擁有許 多回呼函數。另外，Node.js 對 JSON 格式資料可以直接存取，不需要煩惱轉換與是否匹配的問題。
Ryan Dahl 創造 Node.js 的目標就是創造具有即時推送能力的網站。它的特別之處在於純 粹的事件導向，且屬於非阻塞性I/O，不同於以往傳統的前後端資料傳輸處理方式，一個單一
節點就能處理非常多的需求，降低後端對於大量需求的記憶體資源需要，如圖2 所示。
本研究選擇Node.js 作為中間交換器角色，Node.js 不是一個主導網頁開發的平台，相反 的，它是一個滿足特別需求的平台。它不適合用於繁重的計算等CPU 密集型的操作。它真正 的亮點在於建置高效能、高拓展性的互聯網運用，因為它能處理龐大的且高吞吐量的開發連，
它正是符合本研究定義之雲運算架構中的中間交換器角色。
圖2 Node.js 接到使用者需求示意圖
（三）小結
有了中間交換器，就讓架構維持前端與後端分開。此時，中間交換器即時、高速的特性尤 其重要。以下從傳輸管道與開發管理方面列出本研究定義之架構中的問題與選擇之改善方法。
傳輸管道
從架構而言，交換器需要服務兩端點，傳輸管道就分為兩邊，如圖3 中紅框標示之兩個 區塊，第一區塊為瀏覽器端與交換器之間的傳輸，第二區塊為交換器與雲運算之間的傳輸。
圖3 中間交換器兩端之傳輸管道
（一）傳輸管道之問題
以下傳輸管道之問題分別依第一個區塊與第二個區塊探討。
（1）第一個區塊
第一個區塊會遇到的問題為使用者瀏覽器版本不同時傳遞方式的選擇，另外，資料傳輸 方式應改善為及時回覆。網路傳輸問題中，訊息交換通常是由客戶端透過瀏覽器發出請求，
服務器接收以及審核完請求後，將訊息進行處理並返回結果給客戶端，這個方式並無問題，
但對於需要即時性要求較高的應用程式就會顯得困擾。
面對這種狀況，HTML5 定義了 Web Socket 協定，能更好的節省伺服器資源和頻寬並達 到即時通訊。Web Socket 是瀏覽器與伺服器交換資料的方式之一，與 HTTP 最大的不同是，
它是一個持續的雙向的連線，所以沒有重新連線，重新傳送表頭等多餘的負荷，反應更即時。
雖然Web Socket 已經相當成熟，但是有些瀏覽器的版本是不支援的。
本研究在希望同時增加網頁即時性，並解決Web Socket 不是所有瀏覽器都支援的問題。
（2）第二個區塊
在第二個區塊為中間交換器與大量雲端服務整合，此區塊在傳輸上更需要高速、擴展性 等特性，速度是一大問題，因此，本研究希望統一訊息傳遞間的通訊匯流排，並在此匯流排 之下，整合雲端服務。
（二）傳輸管道之選擇
以下傳輸管道之選擇分別依第一個區塊與第二個區塊探討。
（1）第一個區塊
根據第一區塊的問題，本研究選擇Socket.IO 作為改善方法。
在技術上，Socket.IO 跟 Node.js 的事件處理方法相同，這就把第一區塊的傳輸方式與交 換器端的程式統一成相同的操作方式，讓開發團隊只需專注在處理「事件」，即可快速開發出 網頁應用程式。
在機制上，Socket.IO 主要使用 Web Socket 作為傳輸協定，當使用者的瀏覽器不支援 Web Socket 通訊協定，Socket.IO 還是可以選擇該瀏覽適合的方式傳輸資料。Socket.IO 可以消除不 同平台上傳輸方式的差異性，讓開發者更容易發展即時性的網頁應用程式。
（2）第二個區塊
本研究使用Kafka 作為前端連接後端的唯一通訊方式，統一後端系統的通訊匯流排。
（三）小結
第一區塊選擇Socket.IO，第二區塊選擇 Kafka，交換器加入此兩者，完整了兩端的訊息傳 遞方式，Socket.IO 增加即時性，第二區塊中，有任何訊息資料需交換時就透過 Kafka，有了這 層資料交換之通訊方式，前端不必煩惱後端雲運算是以何種語言或何種架構去完成，前端與後 端開發人員可單純且專注得完成自己的任務，而開發管理上問題與解決辦法將於下節做介紹。
開發管理
根據上節所述，開發上同樣也分為兩個區塊，但開發上的涵蓋範圍擴大，如圖4 中所示，
第一區塊為前端瀏覽器與中間交換器；第二區塊包含中間交換器、緩衝區與無限量之雲運算。
圖4 中間交換器兩端之開發範圍
第一區塊中，在開發上，主要與前端瀏覽器語言有關，網頁是由JavaScript 為編譯語言，
本研究希望優化JavaScript 與 HTML 的互動，並選擇適當框架管理前端程式碼。
第二區塊中，在開發上，前端不能直接存取後端雲服務的大量資料，這會造成瀏覽器端 的負擔與傳送通道間的負擔太大。下方針對如圖中所示兩大區塊，依照開發管理之難處與因 應辦法詳述。
（一）開發管理之難處
以下分別探討依第一個區塊與第二個區塊開發管理之難處。
（1）第一個區塊
第一區塊中有兩個困難，一是JavaScript 與 HTML 互動時耗費資源，二是 JavaScript 開 發時的易讀性與程式碼不易管理問題，下方將詳述之。
在網頁中，JavaScript、HTML、CSS 幾乎是目前前端開發的唯一解決方案，雖然 JavaScript 是 函數程式語言，但依舊擁有先天上的困難，即要透過DOM（Document Object Model）與網頁互動。
DOM 將網頁中各個元素（element）都變成物件（object），DOM 是對瀏覽器內所有元素、
對象的一個總稱，提供標準訪問方法，供我們對它進行操作，透過JavaScript，可以重構整個 HTML 檔案，可以添加、移除、改變或重新排列頁面上的項目。
當要改變頁面上某個東西，JavaScript 就要對 HTML 檔案中所有元素進行訪問。當要把 資料顯示出來時，必須在 DOM 與前端畫面之間做兩次的轉換，對 DOM 操作是很耗費資源 的，同時在不同瀏覽器也存在問題，故本研究希望盡可能的避免對DOM 直接操作。
關於第二點管理問題，JavaScript 的概念只有兩層：全域與區域，這讓管理上非常困難，
不適合開發大型程式，再加上 JavaScript 沒有名稱空間，不容易模組化，對於程式碼分佈並 沒有規範下來，而且允許重複定義同樣名稱的函數，有可能發生已宣告過的名字被後面的定 義覆蓋的問題，對開發非常不利，且在開發過程中，由許多複雜的程式碼構成，長久下來，
自己難以維護，又無法交付給任何接替者。
另外，在沒有模組的情況下，程式缺少 MVC 的概念，網路快速發展，不同規格的行動 裝置出現，前端面臨的考驗越來越大，MVC 的概念就越顯得重要，因為前端開發最不樂見的 即是無法專業分工或重複撰寫類似程式碼。因此，本研究希望為前端尋找一個合適的 JavaScript 框架，同時減少對DOM 的操作次數，讓功能清楚切割，讓程式易讀性相對提高。
（2）第二個區塊
第二區塊中，所有巨量資料不可能一次性地送到前端，很多資料是屬於存在後端的運算 資料，這些資料通常是被用來做繁雜的計算及演算法，或者長時間的跑模型，能夠在前端顯 示出來的資料，必定是經過一些簡化與處理，才能呈現給使用者。
前端的資料呈現涉及到的是使用者體驗（user experience），它涉及到個人使用一個特定產 品或系統或服務的有關行為、態度、與情緒。跟系統方面有關的包括實用性、易用性和效率。
如果把資料都存在後端，程式碼與資料的保護雖然可以保護得非常周延，但對於瀏覽器端的 使用者來說，如果每次都要等待很久才能從看不見的遠方的伺服器得到資料，實在非常不友 善，相當於是不好的使用者體驗。而對後端來說，每次使用者的需求，都要耗費長時間傳至 後端，中間的資源耗損也是開發團隊不樂見的。
（二）開發管理優化
以下開發管理優化分別探討第一個區塊與第二個區塊。
（1）第一個區塊
針對第一個區塊的問題，本研究選擇用JavaScript 框架解決。JavaScript 框架除了解決前 端架構的問題，還可用來彌補各種瀏覽器的差異性，讓各種瀏覽器能依照開發者寫的程式碼
運作。本研究考量了包括解決 DOM 的問題、架構的切割、功能的劃分及社群討論，決定選 擇了AngularJS，它的解決方案非常完整，網路上有非常豐富的文件與高度密集的社群討論，
本研究相信Google 開發團隊思考周延性與完整性。
AngularJS 提供的雙向資料綁定特性，是最實用的功能之一，能解決原生 JavaScript 與 DOM 溝通時，容易耗費大量資源的問題。AngularJS 使用不同的方法，嘗試補足 HTML 本 身在製作動態應用方面的不足。AngularJS 透過使用「宣告式語法」，讓瀏覽器能識別新的 語法。
AngularJS 在設計上就擁有 MVC 結構，這讓開發上多了許多便利與彈性，模型與最後在 檢視畫面中的資料表現中間可以切分開來，本研究更希望網頁能在手持裝置中呈現，故本研 究在檢視畫面使用響應式網頁技術克服終端設備的不同，使團隊開發的網頁應用程式在各種 設備中彈性調整最適合的畫面大小跟版面排版。
（2）第二個區塊
第二個區塊的問題，本研究利用架構性的改變，增加緩衝區，讓程式碼好管理。
本研究將巨量資料如何轉成適合前端可瀏覽資料，列為增加使用者體驗的範疇，採取架 構性改變作為解決辦法，而不是美工與畫面上的加強。本研究選擇 MongoDB 作為緩衝區，
透過增設緩衝區的資料存取，優化使用者體驗。緩衝區用來存放使用者能直接讀取之資料，
與後端雲運算拆開，而雲運算則將複雜運算過的資料送到前端前，會做一個篩選的動作，緩 衝區不需專注在大量運算邏輯或演算法上。另外，透過緩衝區，在前端就能把簡單的運算解 決，例如，在前端執行會員登入與驗證，就不必透過層層關卡送到後端，卻只為了驗證會員 帳號密碼是否正確，緩衝區即是存放不需要運算之資料或者前端使用者需要見到的結果。
MongoDB 屬於非結構性資料庫，採用 JSON 格式儲存，選擇與中間交換器相同的語言，
傳輸完全相容，速度非常快，故緩衝區能減少傳輸負擔，增加使用者體驗。
（三）小結
第一區塊中前端開發的問題，選擇框架解決。第二區塊中則是利用架構性的改變，增設 緩衝區。透過AngularJS 中雙向資料綁定特性，解決了原生 JavaScript 與 DOM 溝通時，容易 耗費大量資源的問題；框架的使用也讓開發程式有了適當的管理；響應式網頁技術讓應用程 式頁面擁有不同手持裝置或電腦瀏覽器都能呈現的高度彈性。
研究架構分析小結
本研究在此架構中，解決交換器兩端連線、傳輸、資料量與增加使用者體驗，圖5 為本 研究雲端服務交換器系統之展現。
圖5 雲端服務交換器系統之展現
在傳輸管道上，前端大量需求透過Socket.IO 增加即時性，後端無限多的資源與雲運算透 過Kafka 整合。Kafka 除了被用來當作傳輸機制外，部分開發者會將之視為傳送資料之媒介，
本研究為了減少 Kafka 的負擔，稍作改善，將 MongoDB 作為巨量資料之緩衝區，後端往前 端回傳資料時，會同時做兩件事情，一是透過 Kafka 單純做訊息通知，二是將前端需要之資 料存入 MongoDB。MongoDB 與 Node.js 開發語言相同，傳輸上不需擔心速度的問題，而巨 量資料存取可以透過此機制達到緩衝效果。
期待此雲端服務交換器系統此服務模型能加速開發時間，運用新穎技術，使開發團隊擁 有雲端與大數據知識與行動開發經驗，依據多變環境提供更彈性化的調整，讓此架構在雲端 運算環境下，能處理龐大資料量、改善資料傳輸速度、輕易與後端大量運算整合，最終達成 網站順利建制之目的。
系統測試
本研究將系統測試分為兩個階段，一為性能測試，運用Apache 開發之 Ab 工具，二為網 頁效能測試，運用Google 提供之 PageSpeed Insights。
性能測試
測試工具：Apache Ab
此測試的目的是要消除瓶頸，理想測試是軟體能夠在穩定的情況下進行測試，測試的過 程是順利的進行。
本研究利用兩個最簡單的參數「-c」同時連線數「-n」全部請求數，去測試同時產生大 量請求與同時有大量連線數時的處理速度。測試語法如下：
ab [-c concurrency] [-n requests] [http[s]://]hostname[:port]/path
測試結果
實際測試結果如下表1，名詞介紹如下，並發數表示同時連線數（concurrency level）；全 部請求數表示頁面總訪問數（complete requests）；每秒處理請求數（requests per second）表示 每秒平均處理多少請求；請求運行時間表示每個請求運行時間平均值（time per request），單 位為毫秒（ms），每秒網路流量表示每秒網路上流量（transfer rate），單位為 Kbytes／秒
（Kbytes/sec）。
表1 性能測試結果
測試 並發數 全部請求數 每秒處理請求數 請求運行時間 每秒網路流量 1 10 1000 402.68 2.483 746.76 2 10 2000 376.92 2.653 698.99 3 100 2000 442.03 2.262 820.03 4 100 3000 428.96 2.331 795.89 5 200 1000 353.67 2.828 667.73 6 200 2000 468.51 2.134 874.62 7 200 3000 465.12 2.15 864.09 8 250 3000 447.18 2.236 836.16 9 250 4000 478.48 2.09 891.28 10 250 5000 487.5 2.051 906.47 11 250 6000 473 2.114 878.88 12 250 7000 486.72 2.055 903.55 13 250 8000 484.83 2.063 901.42 14 250 9000 483.55 2.068 899.52 15 250 10000 489.9 2.041 910.19 16 250 15000 490.35 2.039 909.5
在表1 可以發現同時連線數與訪問數增加，在每秒處理請求數變動量不大，除了數據上 顯示系統擁有高吞吐量及高速特性，本研究也將性能測試結果中每秒處理請求數、請求運行 時間之數據做成圖表，如圖6 所示，可以看到每秒處理請求數（上方折線：參考左方Y軸尺標）
維持在400-500 之間，故每個請求運行時間（下方折線：參考右方 Y 軸尺標）也維持在 2 毫 秒左右，除了速度快速外，顯示系統穩定性非常高。
圖6 性能測試結果
網頁效能測試
測試工具：Google PageSpeed Insights
根據 Google「網頁效能最佳做法」來分析網站的效能，這是一組 Google 建議的優化前 端效能的規則，可以從這個方便的工具得到大量的資訊，其中包括一個流動裝置最佳效能的 最佳做法分析。這項工具會擷取網址兩次，一次是透過行動使用者代理程式擷取，一次是透 過電腦使用者代理程式擷取。
測試結果
測試結果分成為電腦版、行動版與使用者體驗，針對電腦版與行動版以速度規則做測試 規則，速度規則測試結果於表2 所示。使用者體驗測試則遵循適用性規則，適用性規則測試 結果於表3 中所示。
表2 速度規則測試結果
速度規則名稱 測試結果
禁止到達網頁重新導向 通過
啟用壓縮功能 通過
加快伺服器回應時間 通過
使用瀏覽器快取功能 建議修正
壓縮資源 通過
最佳化圖片 通過
為CSS 傳送進行最佳化處理 通過
優先處理要顯示的內容 建議修正
移除禁止轉譯JavaScript 需修正
使用非同步指令碼 通過
表3 適用性規則測試結果
適用性規則名稱 測試結果
避免使用外掛程式 通過
設定檢視區 通過
根據檢視區調整內容大小 通過
適當調整點按目標大小 通過
使用易讀的字型大小 通過
PageSpeed Insights 的評分範圍介於 0 到 100 之間。分數以高為佳，獲得 60 分以上及格，
獲得85 以上分數即表示網頁的執行效能良好，表 4 顯示網頁效能測試分數。
表4 網頁效能測試分數
電腦版 行動版 使用者體驗
分數 87 67 100
遵循規則 速度規則 適用性規則
在表2 與表 3 測試結果中，本研究將「移除禁止轉譯 JavaScript」規則列為優先解決之問 題，從表4 中發現，網頁效能在網頁版上測試結果良好，而行動版還需加強。
另外，由於網路連線速度快慢差異很大，因此PageSpeed Insights 只會從與網路無關的方面 來檢視網頁的效能表現，包含：伺服器配置、網頁的HTML 結構及使用的外部資源。實作建議 的解決方法應有助於提升網頁效能，不過使用者的網路連線依然是影響網頁效能的絕對因素。
總結
本研究主要是建立一個架構，提出一個以瀏覽器為中心的雲端運算服務模型。本研究稱 之「雲端運算的服務交換器系統」，結合各種技術，為前端提出一個新型的開發管理架構，該 架構具有以下特色：
系統彈性
由於各種網站或系統的多樣性，在系統實作時，可依照自行需求將此架構拆開並遵循。
高速
從前端語言到後端伺服器的選用上，本研究整合新穎技術，將 Node.js、AngularJS、
MongoDB 整合，並統一傳輸格式。Node.js 能處理龐大資料的高吞吐量特性，符合本研究定 義之雲運算架構中的中間交換器角色，讓架構維持前端與後端分開。另外，在尋求同時兼顧 開發效率和軟體效能的解決方案時，本研究認為JavaScript 在 Node.js 的加持下，成為一個不 失效能、彈性和硬體、系統的耦合度的解決方案。
效能與穩定性
為了確保此架構速度與彈性，效能與穩定性為最需要解決的重要議題。本研究採用兩種 測試，依照所得之測試數據，可得出以下幾點結論：
1. 本研究所提出之新架構，在實作後測試其速度及範圍皆可行。
2. 本研究所實作之網站在網頁版中執行效能良好。
3. 本研究所實作之網站在行動版中，執行效能中等，雖符合響應式網頁，要求更輕量的程 式，應列為後續改善項目。
未來展望
本研究因受時間與資源的限制，未能將系統建置得盡善盡美，因此在下方列出幾項建議 運用本架構實務應用之參考：
(一) 除本研究所選擇之 AngularJS 框架外，可參考其它框架，如 Ember.js、Batman.js。
(二) 系統建制牽涉到許多軟硬體資源，本研究將網站建置於單一電腦主機上，若要增強處理 速度，本研究認為可考慮增加主機數量，甚至提升為分散式平行處理。
(三) 本網站主要針對其功能與架構之可行性進行開發，對於系統後台無琢磨太深，建議增加 其管理功能，本系統目前將每位使用者視為同一等級，未來可提供不同權限之身份。
(四) 資料庫使用上，將來可嘗試將資料庫做分散式處理，甚至搭配備份，減低各個機器負擔，
並增加容錯力。
(五) 本研究對於網頁版本開發琢磨較深，在網頁性能測試時，行動版競爭力較弱，應持續優 化行動版網頁。
參考文獻
David Flanagan. (2011). JavaScript: The Definitive Guide, 6th Edition. O'Reilly Media.
Ezo=易組（1999）。MVC 如何因應變「畫」多「端」。檢自：http://goo.gl/I7EG9o
【Ezo=yizu (1999). MVC ruhe yinying bian”hua”duo”duan”. Retrieved from http://goo.gl/I7EG9o】
吳進雄（2000）。網際網路上資料庫存取之架構研究（未出版之碩士論文）。國立中興大學應用數學系，
臺中市。
【Wu, Chin-Shiung (2000). Architectural variations of internet database access (Unpublished master’s thesis).
Department of Applied Math, National Chung Hsing University, Taichung City】
李春红、高建華（2007）。使用分層模型改進 MVC 設計架構。計算機工程與設計，28(4)，766-769。
【Li, Chun-Hong, & Gao, Jian-Hua (2007). Shiyong fenceng moxing gaijin MVC shejijiagou. Computer Engineering and Design. 28(4), 766-769.】
亞州雲公司（2011）。國內企業運維模式不適合雲計算發展。檢自：http://goo.gl/Bzly6t
【Yazhouyun gongsi (2011). Guonei qiye yunweimoshi bushihe yunjisuan fazhan. Retrieved from http://
goo.gl/Bzly6t】
周冠誠（2012）。基於 MVC 架構之雲端平台設計（未出版之碩士論文）。國立暨南國際大學電機工程學
系，南投縣。
【Jhou, Guan-Cheng (2012). MVC-Architecture-Based Cloud platform design (Unpublished master’s thesis).
Department of Electrical Engineering, National Chi Nan University, Nantou County.】
周建輝、姚素红（2009）。三層架構作業管理系統的設計與實現。南通航運職業技術學院學報，4，74-77。
【Zhou, Jian-Hui, & Yao, Su-Hong (2009). The design and implementation of work management system based on three-tier architecture. Journal of Nantong Vocational & Technical Shipping College. 8(4), 74-77.】
林姿華（2010）。全世界漫步在雲端-淺談科技新知識『雲端運算』。國立高雄師範大學工業科技教育學 系，高雄市。檢自：http://goo.gl/10y8Lb
【Lin, Zi-Hua (2010). Quan shi jie manbu zai yun duan – qiant an ke ji xin zhi shi『yun duan yun suan』.
Department of Industrial Technology Education . Kaohsiung city .Retrieved from http://goo.gl/10y8Lb】
美國國家標準和技術研究院（2009）。美國國家標準與技術研究院對雲計算的定義。檢自：https://www.
cloudopenlab.org.tw/
【Meiguo guojia biaozhun he jishuyanjiuyuan (2009). Meiguo guojia biaozhun yu jishuyanjiuyuan dui yunjisuan de dingyi. Retrieved from https://www.cloudopenlab.org.tw/】
孫雅麗（2011）。並非所有的應用都適合雲端運算的環境。國立臺灣大學計算機及資訊網路中心。檢自：
http://goo.gl/kR56Y
【Sun, Ya-Li (2011). Bing fei suo you de ying yong dou shi he yun duan yun suan de huan jing. Computer &
Information Networking Center, National Taiwan University. Retrieved from http: /goo.gl/kR56Y】
張婷雅（2014）。MVC 設計樣式開發跨平台行動應用之研究（未出版之碩士論文）。國立臺北科技大學 資訊工程學系，臺北市。
【Chang, Ting-Ya (2014). The study of cross-platform mobile application developments using MVC design pattern (Unpublished master’s thesis). Department of Computer Science and Information Engineering, National Taipei University of Technology, Taipei City.】
陳樂子（2013）。基於 MVC 設計模式之中小型網站開發與設計實例（未出版之碩士論文）。臺北城市科
技大學電子商務研究所，臺北市。
【Chen, Le-Zi (2013). The design and implementation of small and medium-sized web basedon MVC design pattern (Unpublished master’s thesis). Department of Information Management, Taipei City University of Science & Technology, Taipei City.】
A Study of Cloud Computing Service Model for Front-end Browser
Wan-Ju Yu
Master Student, Department of Management Information System, National Chengchi University, Taiwan (R.O.C.)
E-mail: 102356019@nccu.edu.tw
Keywords: Big Data; Cloud Computing; AngularJS; Socket.IO; Node.js; MongoDB;
Kafka; JavaScript
【Abstract】
This research follows the trend of latest technology and puts forward a browser‐centric cloud computing service model, termed “cloud service exchange system”. This system solves the problem that the requests of the immense volume of data and the request of large data processing from back‐end to the front‐end. In the meantime, this system improves the speed of transmission via buffer. We integrate five elements, including MongoDB, AngularJS, Socket.IO, Kafka, Node.js. This study solves many problems as below:
1. The interaction between JavaScript and web front‐end.
2. The compatibility issues in programing language of front‐end and back‐end.
3. Server overloading caused by the huge amount of information on demand.
4. Instant messaging performance front‐end and back‐end.
And finally achieve the goal of creating a website.
