使用 Microsoft Azure 網站服務架設網站服務或網站應用程式(適用 ASP.NET, PHP, Python, Node.js, Java)

文章更新: 2014/10/13

Microsoft Azure Website

Microsoft Azure 是微軟推出的雲端平台,它並不是單一功能的產品或平台,而是數十種用來建置雲端服務平台產品的集合。而 Microsoft Azure 網站服務是一個可以快速建置網站(靜態網站或網站應用程式)的平台服務(PaaS, Platform-as-a-Service),而且具有雲端平台的特性——用多少付多少,所以您不必事先估算需要的機器資源而進行採購,在網站運行的任何時間都可以動態調整資源,有需要時調高、沒需要時調低,更有效地花費服務的預算。此外,這個平台服務有著開放跨平台的使命,不論原本是使用 ASP.NET、PHP、Python、Node.js 還是 Java 撰寫的網站都可以直接放在這個平台上運行,而且支援多種部署網站的方式,所以也不限制開發人員要用什麼平台(PC、Unix-like、Mac 等皆可)、開發工具來開發網站。以下是我在 Channel 9 上錄製的影片,用來簡介 Microsoft Azure 網站服務是什麼樣的平台:

這裡我將影片提到的部份分為幾個重點來逐一介紹:

開始瞭解 Microsoft Azure 帳號之前,可以先註冊一個免費試用的 Microsoft Azure 訂閱帳號,並且試試看網站服務來運作您的網站。


做為網站的虛擬主機

使用 Microsoft Azure 來架網站最大的好處就是不必自己管理伺服器,當然也不用安裝維護作業系統或是伺服器軟體,只要把網站程式寫好了部署上去立刻就開始服務了,對於網站開發人員來說相當方便快速。

當有了 Microsoft Azure 訂閱帳戶後,便可以直接在管理後台中建立多個網站服務,一個網站就建立一個

此外,也可以安裝 Azure 跨平台命令列工具,在 console mode 下面用 script 的方式來建立網站服務:


使用 script 的方式在東亞機房建立 Azure website 並且開啟 git 部署

每個網站除了執行環境都是隔離的之外,也都可以有自己單獨的設定、使用的價格方案、以及調整需要的運算資源等等設定,所以你可以某些網站跑 ASP.NET、有一些是 PHP 或是 Python 網站等等;小的或是做為小玩具的應用可以選擇免費或共享的價格方案,而正式或商業運作的網站則可以切換到基本或標準的價格方案,互不影響。


網站可以單獨設定各種語言使用的版本等


管理後台都可以監控網站的運作狀況

如果你想專心把網站寫完之後,能夠快速地把網站丟上網路跑起來給大家用,那就一定要用 Microsoft Azure 的網站服務。

使用架站軟體架站

另一方面,如果你想用一些知名的架站軟體(如:WordPress、Drupal、Ghost 等)來架站,Azure 網站服務也提供直接從這些架站軟體來開始架網站,只要在新增網站時,選擇從組件庫,接下來便可以選擇想要使用的軟體開始一步步完成網站架設。


在 Microsoft Azure 上可以直接用各種知名的架站軟體來直接架網站

參考資料

 

部署網站

Microsoft Azure 網站服務為了達到開放、跨平台的使命,除了支援多種程式語言之外,部署網站的方式也有許多選擇,像是最簡單的 FTPWeb Deploy 之外,也支援像 TFSGit 這些版本控制來部署,或是結合 Visual Studio OnlineGitHub  、 CodePlex 或是 BitBucket  這些代碼託管的平台來做部署,甚至能使用 Dropbox 的同步機制將網站檔案同步到 Azure 上完成部署。

Microsoft Azure 網站服務支援這麼多種網站部署的方式,就是希望能夠不改變原來開發人員的開發、發佈流程,如果您原本是使用 Visual Studio 開發 ASP.NET 網站的開發人員,您依然可以在 Visual Studio 中直接發佈網站,Visual Studio 會提供發佈到 Azure 網站服務的選項(註:工具的整合需要 Visual Studio 2013 Update 2 之後搭配 Azure SDK,若是較舊的版本可以在管理後台下載發行設定檔再匯入即可):


在 Visual Studio 原本的發行網站流程中直接可以選擇 Microsoft Azure 網站服務作為發行目標

而若是使用 Git 來部署網站,只要在管理後台將網站設成可由原始檔部署,就可以當作是一個 remote repository 來推送程式碼,完成部署:


使用 git 版控流程來部署網站內容:部署位置是一個 remote repository

而使用原始碼版本控制的機制部署時還有一個好處:就是可以追蹤每一次發行記錄,並且隨時可以切換回之前的部署。

稍候我們會再介紹 Azure 網站服務內建的預備環境部署(staging)的機制。

參考資料

 

延展網站所需的資源

大多數開發人員在開發測試的階段,會先將網站設成使用免費的價格方案,在一定的使用額度下來測試網站是否能正常運作,而當正式營運後再根據實際的狀況來調整運算資源、需要的虛擬機器數量等等。而調整網站所需要的資源是任何時間都可以做的,只要到管理後台,隨時可以切換價格方案,或是虛擬機器的使用數量。


網站在 Azure 網站服務上運行後,隨時可以到後台調整需要用到多少運算資源

隨時可以根據需要調整價格方案——免費的方案有限制的流量,而且也只能使用一個 web 實體(instance);共享方案可以調整要用幾個實體運作網站;基本及標準的價格方案除了是使用保留的虛擬機器、可以調整實體的數量之外,還可以調整虛擬機器的大小。


雲端平台的特性就是能夠彈性地調整網站所需要的運算資源

自動延展

雖然網站的資源可以隨時調整很方便,但你也許會問:

「我又沒辦法時時刻刻守在管理後台前,看到需求增長時才去調整資源,萬一在我睡覺的時候網站爆紅,誰能幫我調整運算資源?」

還好 Azure 網站服務也提供了自動延展(Auto Scale)的機制,你可以根據排程,或是設定一些數值(像是 CPU 運算量)的臨界點(threshold),當數值超過臨界點時就觸發自動延展的機制,如果低於臨界點就再調整下來,一切自動化處理。


設定好自動延展的機制後,你就不必擔心網站突然爆紅而撐不住了

當然這樣的機制不會無限制地往上延展,系統還是保留了彈性讓你可以設定自動延展機制可以調整的上限及下限,以確保一切的操作都符合你的預算。


可以設定排程延展,或是根據 CPU 用量來調整

參考資料

 

Staging/Production 的部署環境分離

當預計要將網站改版更新時,開發人員一定都會想盡辦法測試,以確保新版的程式碼上線時不會發生問題,所以會建立一個與線上(一般稱為 production)環境相同的預備(一般稱為 staging)環境,在網站正式部署上線前,先把新的程式佈到預備環境,確定一切沒問題後才會佈到線上環境。Azure 網站服務內建了這個功能(目前僅提供給標準價格方案的用戶),在網站服務中可以加入多個部署位置,而其環境都是與線上環境相同,不必自己再花心力去維護預備環境(試想,如果想要有 2 個預備環境,在 Azure 網站服務上僅需按幾個按鍵即可完成,需要再開,不需要就關,如果自行架設預備環境,可以想像會多出多少成本)


在 Azure 網站服務上可以建立一個或多個部署環境

只要在管理後台的儀表板中選擇「加入部署位置」的功能,立刻就可以建立一個新的部署位置,因為是跟線上環境使用相同的虛擬機器,所以新增部署位置是不會增加任何費用的:


可以自由增加部署位置,並且決定是否要複製組態設定

新增完部署位置後,可以發現原本的網站服務會多了一個實體,而且也有它專屬的 URL 可以用來存取測試,下圖是加入了兩個部署位置的狀況:


加入新的部署位置後,每一個部署位置都有自己的設定、獨立的 URL 可以自由運用

有了這樣的機制之後,就不必再自行準備預備環境了,直接將新的程式部署到預備環境上,然後用預備環境的 URL 進入測試,確認沒有問題之後,再直接使用管理後台下方的「交換」按鈕,立刻就可以把某一個部署位置的程式與線上環境進行交換,之所以叫交換(swap),就是如果真的上線後發生問題,還是可以再次交換回來,不受影響。這個交換的動作僅需數秒鐘的時間就可以立即生效,所以用這種方式做網站改版完全不需要停機,讓你的網站可以持續運作。


按下交換按鈕後,選擇要交換的來源及目的

有了這樣的功能,將更可以滅少網站換版造成的停機損失、或是測試不完全的問題。

參考資料

 

背景程式的運作

Web 應用程式中有些運算可能會很複雜而花較多運算時間,或是必須去介接其它服務的 API 來做些事等等,這些操作可能只是一次 HTTP 要求中的其中的一份工作,但因為複雜的運算需要等待回應、介接其它服務的 API 可能會耗費更多時間或是出錯,這些都有可能會讓 HTTP 的要求時間過久,讓使用者誤以為是網站掛掉了,同時也會降低用戶的操作體驗。舉例來說,很多網站在會員註冊新帳號時,除了會把會員資料寫進資料庫中之外,可能還會去接發送郵件的系統發出確認信,如果這些動作全部都在 /signup 的操作中完成,除了可能會讓用戶等很久之外,萬一送郵件失敗,用戶的註冊經驗可能就會很差,要重新註冊可能還會有資料庫裡有重覆資料的問題。

要解決上述的問題,一個比較好的作法是——讓註冊的操作簡單只做把會員資料寫進資料庫即可,而將「寄出確認信」這個工作放進一個佇列(queue)中,背景再定期跑程式來檢查佇列中還有沒有工作要做(有沒有信要寄),確認寄信成功之後再把工作從佇列中移除,這樣一來可以讓 web 應用程式中的 /signup 操作簡化可以快速反應之外,若寄信失敗還可以稍後再重試一次,完全符合在寫雲端應用程式時,必須為錯誤發生做好準備(design for failure) 的心法。


WebJobs 是 Azure 網站服務上讓你在背景執行程式的方式

Azure 網站服務上的 WebJobs 就是為了這類型需求而提供的服務,你可以獨立於原本的 web 應用程式之外再撰寫一個在背景執行的程式(一樣可以使用 .NET、PHP、Node.js、Python、Java 甚至是 .bat 檔來撰寫),然後設定成 WebJob,讓它連續定期或是根據需要來執行。而佇列的部份,則可以搭配 Azure 儲存體服務中的佇列,或是 Azure 服務匯流排(Service Bus)的佇列來搭配使用。

參考資料

 

網站的備份及還原

所謂天有不測風雲,放在雲端的程式不代表一定不會壞(不論是哪家雲端、哪種虛擬主機業者皆是如此),所以如果網站的內容非常重要,那做好備份的工作是很重要的。Azure 網站服務也提供了備份網站的功能(目前僅提供給標準價格方案的用戶),可以定期備份網站檔案、內容到儲存體中,如果需要的話,連資料庫的內容都能備份。


Azure 網站的備份服務可以備份網站內容、設定以及資料庫內容

網站的備份可以是手動——需要的時候按下備份的按鈕來進行備份——也可以排程來自動備份,備份的內容都會儲存在 Azure 儲存體中,網站備份服務會在儲存體帳戶中建立一個 websitebackups 的容器,然後將網站內容 zip 起來儲存在裡面,所以你也可以自行取出這些備份。

而備份了之後,當然日後也可以從這些備份中直接還原網站。

參考資料

 

跨資料中心的流量管理

當網站要服務的客戶來自全球各地時,就不會只把網站放在單一資料中心了,而當您把網站放在全球多個資料中心時,又開始會想說,該怎麼把用戶導到離他最近的資料中心來提供服務呢?這時就可以使用 Azure 流量管理員(traffic manager)服務,透過流量管理員,你可以把同一個網域名稱對應到各個資料中心相同的網站應用程式,而不論是在哪裡的用戶,都是使用相同的網域名稱來存取網站,而流量管理員就會協助將用戶導到鄰近的(你有放網站的)資料中心來提供服務,避免連到較遠的資料中心而得到較長的網路傳輸時間。


使用流量管理員來智慧分配流量

除了連接到鄰近的資料中心之外,若您某個資料中心的網站發生問題,流量管理員也會自動避開導向有問題的網站,而不會讓用戶發現網站掛掉而不能使用。

參考資料

 

為網站提供 CDN

雖然可以使用流量管理員來將不同地區用戶導向不同的資料中心,但如果規模還沒那麼大,只是希望網站放在單一資料中心,而利用 CDN(Content Delivery Network)來為不同地區的用戶提供鄰近的存取複本呢?現在你已經可以使用 Azure 的 CDN 服務,除了 Azure 儲存體、Azure 雲端服務之外,也可以為 Azure 網站服務上的網站建立 CDN。這有什麼好處呢?舉例來說,你希望網站服務放在東亞的機房好服務台灣的用戶,但如果加上 CDN 的複本,因為目前 Azure 的 CDN 服務有台灣的端點,所以你只需要設定 CDN 來快取你的網站,然後把自訂網域名稱設定在 CDN 上,那麼用戶便會去存取 Azure CDN,再由 Azure CDN 來決定用哪個鄰近的端點來服務用戶,相當簡單。


可以為你 Azure 上的儲存體、網站服務、雲端服務設定 CDN

參考資料

 

與企業網路混合連接

很多 web 開發人員,可能原本就有自建機房來維運網路服務或資料庫等等,有時因為業務需求,或是公司規定,某些服務對於放在雲端平台上有疑慮,或是需要花許多時間進行移轉,如果想把 web 應用程式放在 Azure 的網站服務上享受前述的功能,但又希望能與自建機房的資料串接,這時就可以使用 Azure 所提供的虛擬網路服務,將自建機房與放在 Azure 上的網站用一個虛擬網路串接,這個虛擬網路只有 Azure 與自建機房能夠存取,也可以避免其它的安全疑慮(當然,Web 程式也要注意安全性,就算不是放在 Azure 上也一樣)。


Azure Hybrid Connection 功能提供另一種與自建機房中的網路介接方式

除了使用虛擬網路之外,另一種方式就是使用 Azure Hybrid Connection 的方式來串接,虛擬網路的作法只能用同一個虛擬網路涵蓋所有需要存取資源的地方,這種方式在 web 應用程式要存取多個網路環境時會變得較不夠用(畢竟要把不同機房全放在同一個虛擬網路下也挺有風險的),而 hybrid connection 則是可以在各個網路環境中安裝一個代理程式(上圖中的 hybrid connection manager),由它來管理機房內什麼服務要透過哪個端點(endpoint)來開放存取而不是開放整個網路,這樣的作法就可以適用在多種複雜的網路環境,只是需要個別安裝代理程式(需要一台 Windows Server 的環境來執行)。

參考資料

 

使用其它服務強化網站應用程式

當網站順利跑在 Azure 的網站服務上後,仍然可以利用其它 Azure 服務來優化網站效能、增加網站安全性、或是提高網站的可靠度,這裡就列出一些常用於 web 應用程式的服務。

Azure 儲存體及 Azure CDN

在開發傳統 web 應用程式時,很多開發人員會直接使用本地端磁碟來處理檔案,好一點的可能會另外建立一台 file server 來專門處理檔案。在 Azure 網站服務上雖然還是有提供本地端磁碟空間,但這個空間主要是用來放 web 應用程式本身的檔案,而不應該是網站的內容(包括使用者上傳的),因為這樣做有兩個最大的問題:

  1. 當瀏覽器要存取內容檔案時,因為是放在 web 服務的檔案系統中,也會耗費 web 實體的 CPU 計算時間及流量,而 web 實體的 CPU 計算時間應該盡可能地用在 web 程式本身的運作上。
  2. Web 應用程式跟 azure 網站服務會綁得太深而缺乏彈性,也會影響後續可能的延展效果。

所以關於檔案的處理,最好可以使用 Azure 儲存體的 Blob 來存放檔案,除了分散檔案的處理之外,也可以享受 Azure 儲存體做好的快取及備份功能,也可以讓 Azure CDN 來快取儲存體上的複本,提供給用戶更快的網路傳輸效率。

此外,結構化的資料也可以使用 Azure 儲存體中的 Table 服務來儲存,透過 key-value 的方式來存取。

要使用 Azure 儲存體是很容易的,因為 Azure 官方已經提供了許多語言的 SDK:.NETPHPPythonNode.jsRubyJava 等。

參考資料

設定 SSL

如果網站需要使用 HTTPS 做加密的連線,Azure 網站服務也支援安裝 SSL 憑證的功能,詳細的安裝步驟(包括使用 IIS 或 OpenSSL 來製作憑證要求證)可以參考官網上這篇文章:對 Azure 網站啟用 HTTPS

使用 Azure Redis Cache

Web 應用程式最常做的就是資料的 CRUD(Create, Read, Update, Delete),而資料的來源可能是來自資料庫、或是其它第三方的服務(如:Open Data)等,而資料操作的時間比較長,而這四種資料操作又以讀取操作最為頻繁,為了節省去資料庫讀取的時間,通常會將經常重覆讀取的資料放進快取(cache)中,因為快取是直接把資料存在記憶體中,所以讀資料的反應較快,這樣一來之後的讀取操作都可以直接從快取拿而獲得較快的效能。


Azure Redis Cache 服務可以直接使用,不必自行架設伺服器

而 Azure 提供的 Redis 快取服務正是可以用來做快取的解決方案,開發人員不必額外去架設快取伺服器,直接在 Azure 的管理後台開一個 Redis Cache 的服務,再根據需求選擇價格方案,就可以直接使用高可靠的快取服務。

Redis 本來就是一個擁有不錯生態系的開源專案,所以很多程式語言都有函式庫可以使用。

參考資料

 

下一步

如果你迫不及待要開始試用 Microsoft Azure 的網站服務功能,最後再提供您更快可以上手的相關資源: