踏出雲端應用程式規畫的第一步

在前一回中，我們談到了「天下大勢，分久必合，合久必分」的歷史輪迴，其中以炙手可熱的關鍵詞「雲端計算」舉例做為說明。接下來，就讓我們來討論一下「雲端計算」在應用程式設計上，究竟會有什麼樣的改變和影響。

雲端計算最核心的觀念，在於將計算的重心擺在雲端。

何謂「雲端」？即雲所在的那一端。在網路領域中，時常用雲朵的圖案來代表網際網路，所以，「雲端計算」一詞，即代表透過網際網路取用計算資源的一種計算型態。

倘若只抽象化到站在這個觀點上來看，便是從歷史的脈絡中可以理解，這種計算方式早在之前，便是人們已經使用過的模式。

不過，現今的雲端計算，有一些新的元素在裡頭，這些元素不見得是新技術、新想法，在過去的研究文獻或探討中，這些想法或技術或許早就出現過，但如今「雲端計算」這個詞語，將所需的相關觀念集合在一塊，形成一個整體的想法。

我們處於一個可以持續連網的時代
為什麼在這個階段，將計算擺到雲端上，又再度成為一個趨勢呢？

其中有一個重要的關鍵在於行動裝置的盛行。這些行動裝置，像是智慧型手機、平板電腦、小筆電等等，計算力雖然還是遠勝昔日的桌上型電腦，但是相較於今日的個人電腦，仍然算是計算力薄弱的計算裝置，這使得在此類的裝置上進行大量沉重的計算並不恰當。

同時，由於無線區域網路愈來愈普及，加上3G網路基礎建設愈來愈完備，這構成了一個重要的先決條件──裝置幾乎無時無刻都能處理連網的狀態。這麼一來，計算力較為薄弱的行動裝置透過網路取用計算資源，便成了順理成章的選擇。

此外，因為使用者大多會在不同的裝置間切換，例如，在辦公室中使用筆記型電腦工作，接著在離開辦公室後，可能還會透過手上的智慧型手機讀取電子郵件，或者是利用即時通軟體和同事、朋友交換訊息。回到家後，或許還會打開像是iPad之類的平板電腦，在客廳中閱讀、上網、順便回覆郵件。由於每個使用者都可能運用多個裝置處理事務，但是，使用者又會希望在這些不同的裝置上都能處理相同的一組資料（例如電子郵件、或者是自己的記帳試算表）。

為了避免資料同步的麻煩及問題，將資料、以及對資料的計算操作統一放置在雲端，同樣也成了十分理所當然的想法。

雲端計算並非所有應用程式的救贖，而從以上的描述不難看出，究竟何種應用程式類型適用雲端計算的觀念來設計、能從雲端計算的觀念獲得好處。

如何規畫應用程式執行的所在
雲端計算對應用程式開發所產生的第一項衝擊，便是讓應用程式的設計者思考，將應用程式切割成為兩個部分，一部分在裝置端，另一部分則擺放至雲端。

那麼究竟應當如何切割呢？這是程式設計者在決定運用雲端計算觀念來開發應用程式時馬上會面臨到的下一個問題。要回答這個問題，你必須思考，將程式擺放到雲端上，究竟具備了什麼優勢。

雲端相較於行動裝置端，計算力更為充足，而且有值得信賴的電力供應，網路連線不僅更為穩定，可運用的頻寬也更大，儲存空間當然更為穩固、容量也高出許多。這便是將程式放置到雲端可以獲得的好處。如果你的應用程式中，有一部分需要重度的計算、耗時的計算，那麼將它們放到雲端上，便會比擺到裝置端來得理想；如果你的應用程式中，有一部分需要頻寬較大、較穩定的連網環境，或者，需要更大、更保險的儲存空間，那麼要將這部分程式放置於何處，我想答案也很明顯。

例如，你打算開發一套電子書的系統，讓使用者可以透過各種裝置閱讀電子書。在你的應用程式功能規畫中，希望讓使用者輸入某個關鍵字，就能搜尋出來本文中含有該關鍵字的書籍，那麼這麼功能會放在雲端或者是裝置端呢？裝置端的儲存空間不可能存放所有的書籍，更別提要提供所有書籍全文檢索的功能，必須建立索引，而全文檢索的繁重運算量也不適合放在裝置端進行了。基於儲存空間、計算量的考量，你會將這一部分的計算程式畫分至雲端。

那麼什麼樣的程式適合畫分至裝置端呢？裝置端的優勢在於能和使用者直接溝通，能呈現聲光效果，能藉由便利的輸入方式獲得使用者的操作命令。換言之，處理使用者介面的程式碼十分適合畫分到裝置端。此外，如果計算量不是很繁重，而計算本身又必須有即時的反應，那麼此種類型的程式碼，也適合放在裝置端。

用MVC的模式來協助畫分程式責任範圍
有一個設計模式叫做MVC，將應用程式畫分為三個責任各異的部分──Model（資料模型）、View（檢視）、Controller（控制器），其中Model代表的資料本身的表示方式以及操作資料的事務邏輯、View則負責資料的呈現。Controller則處於Model及View之間，負責控制應用程式的流程，它負責處理事件並回應事件「事件」，當Model中的資料改變時，負責更新View中的內容，相反的，當使用者透過View操作資料時，也將他所做的變動同步反映至Model中的資料。

當我們運用雲端的觀念時，我認為MVC的模式能協助我們畫分應用程式的所在究竟在雲端或裝置端。最極端的情況，我們可以把View全部都放在裝置端，Model全部都放在雲端，當然Controller介於其中。

也就是說，裝置端僅負責做畫面的呈現、接收來自於使用者的輸入或操作。操作、計算資料的工作，全部都丟上雲端來完成。當裝置端需要存取資料，便透過網路，要求位在遠端的雲端程式處理，並由它們回傳計算結果，接著再由裝置端的程式進行計算結果的呈現。

當然，正如前段所述，這是「極端」的情況，幾乎不讓裝置端上的程式處理太過「正經」的程式碼。但裝置端並非毫無計算能力，只是較弱罷了，但真要上場殺敵，也不是全無辦法。

有時候，你還是會選擇將部分的資料、以及部分處理資料的程式碼放置在裝置端。主要的原因是，透過網路連繫雲端上的程式碼，會需要付出網路通訊的延遲作為代價，當應用程式需要呈現的資料結果必須反應速度夠快時，便不太適合總是調派雲端上的程式碼相助。

在這種情況，可以將少部分的資料及處理資料的程式碼置放在裝置端。舉例來說，應用程式可能需要頻繁的取用資料，雖然「正港」的資料在雲端，但是，為了提供更快的反應速度，可以在裝置端設計資料的快取機制，當使用者介面要呈現資料時，便可逕自快取取用，如此，存取速度便較透過網路取得來得快上許多。

當我們打算套用雲端計算的概念時，所面對的第一個問題，便是如何畫分程式的責任範圍，在本回中先討論此一議題，之後再讓我們繼續談雲端。