Windows Azure 基本概念淺析

Windows Azure Platform不斷在變化，所以它的概念什麼的也不斷在變動。考慮到將來童鞋們要用到這些東西，所以我基於MSDN2010年11月22日的文檔以及The Windows Azure Programing Model 1.0整理了這篇文章。

  一、關於Windows Azure的基本概念

 

Windows Azure 和Windows Azure 平台不是一個東西，平台指的是微軟在其全球幾個資料中心搭建的雲端服務平台，平台裡包括了Windows Azure 作業系統和一些列的各種服務，比如SQL Azure等等。

 

正如所有雲端運算服務一樣Windows Azure 平台簡化了維護技術設施和軟體的工作，同時基於按需使用的原則提供了彈性的支付方案，這樣一來不僅保障了基礎設施的高可用性和延展性，同時也保證了相比自己購買伺服器和基礎設施所需的覆蓋長期需求的成本。

 

Windows Azure作業系統作為Windows Azure平台的開發、運行時以及控制環境。 它內建了負載平衡以及資源的自動管理。

 

目前，要進行Windows Azure的編程工作需要使用到以下服務和工具：

 

  Windows Azure Compute Services Windows Azure Storage Services Windows Azure Platform Management Portal Windows Azure Development Environment Windows Azure Tools for Visual Studio

 

 

  Windows Azure 計算服務

Windows Azure提供了一套基於整個英特網層級，建立在多個分佈於全球不同地區的資料中心的主機環境，使用者可以使用這個環境來執行託管的代碼。

關於計算服務中的幾個概念的關係如下：

 

Windows Azure Compute Service

--Deployment

-- Role

-- Role

--Depolyment

-- Role

注意的是，這個Deployment Azure是不管的，每個Deployment是用VS編譯出來的包，其中有幾個role部署上去就用幾個role

 

目前， Windows Azure 的roles有三種： Web Role ：專門為Web程式配置的環境，支援IIS7和ASP.NET，它實際運行於IIS7.0之上。通常，把它用來處理外部的HTTP請求，這裡還支援WCF、PHP和Java等技術 Worker Role： 適用於通用的程式，它可能作為Web Role的幕後處理程式 Virtual Machine Role（VM Role）提供一個使用者自訂的鏡像來把現有的Windows Server 程式遷移到Windows azure 環境

一個Services可以混合使用多種role。

Role可能需要和運行時環境有所互動，這樣就必須使用Windows Azure Managed API 。

 

 

  Windows Azure 儲存服務

Windows Azure Storage Servies 提供了一種在雲端儲存持久化資料的功能。 其主要包括以下幾種基礎的服務： Blob服務， 用來儲存文本和位元據 Queue 服務，用來儲存服務局通訊用的可靠的持久化訊息 Table 服務，用來儲存可以被查詢的結構化資料

Windows Azure SDK提供了REST API和託管的API以用來訪問儲存服務。它們支援任何形式的通過HTTP/s訪問

 

  Windows Azure 平台管理入口網站

 

管理入口網站是用來系統管理使用者的Windows Azure 服務的部署和監控的工具。

 

在管理入口網站裡面，我們會看到一些概念： Deployment Health， 表示部署的項目的狀態 Affinity Groups， 它允許使用者基於地理地區組織託管的服務和儲存以最佳化效能 Management Certificates， 用來允許用戶端訪問使用者的訂閱的資源 Reporting， 允許使用者簽入雲端式端的SQL Azure 資料庫報表服務 Service Bus Access，訪問 AppFabric 服務門戶 Virtual Network， 訪問 Windows Azure Microsoft Connect 服務

 

 

  二、Windows Azure的編程模型

 

Windows Azure雖然有VM Role，但是，它更多的是希望做到PaaS（平台即服務）層次的抽象，因此它沒有完全複製舊的面向Windows Server的編程模型，而是建立了一套新的模型以期在以下三點有所提升： 管理能力：作為一個PaaS應用，平台本身負責處理掉大量的管理型事務，如系統的升級、更新、打補丁等，這樣一來，讓使用者可以不必自己去管理程式啟動並執行環境——這是一種非常棒的省去麻煩的做法。 可用性：避免在升級、打補丁、硬體錯誤或者其他原因引起的服務下線。Azure通過雲平台提供的冗餘措施來避免這些問題，所以Azure的編程模型本身即是以保證服務可以持續運行而設計的。 可伸縮：Azure提供的是整個互連網層級的延展性。同時也允許更加彈性化的資源使用。 Windows Azure 編程模型的三條基本規則

　　想要充分利用Windows Azure平台所提供的這些好處，面向Azure開發的雲端程式必須要遵守以下三條規則： 一個Windows Azure程式包括一個或多個Roles（可以混合多種role） 一個Windows Azure程式中的每個Roles都運行於多個Instances 一個Windows Azure程式在任何一個role instance出錯的時候都可以正確工作

　　只有完全遵守著3條規則而開發的程式才可以讓你的程式完全享受到雲端運算帶來的好處。

 

　　正如前文所說的，Azure中的Role包括三種，Web Role, Worker Role和VM Role，

　　舉例來說，一個程式可以使用Web Role來處理來自使用者的HTTP請求然後把請求傳遞給Work Role來處理。這樣一種方式使得整個程式具備了良好的伸縮性。

 

　　對於任何一個Windows Azure程式來說，對於它的每一個role都應該至少運行兩個隔離的執行個體。每個執行個體都運行於它自己的VM之上。

下圖是上面那張圖的實際啟動並執行執行個體的情況，可以看到，程式的每一個role都運行了多個執行個體，並且在不同的VM之上。開發人員應該告訴Windows Azure它需要給每個Role運行多少個執行個體。每個Role的特定執行個體都運行著一模一樣的代碼，所以這些執行個體都是可以互相替換的，這樣一來，Azure就可以自動的處理負載平衡和容錯等問題了。但是需要注意的一點是，Azure不保證對於同一個使用者的請求都能被同一個執行個體處理。

 

　　對於上面這個程式，當它的任何一個Role的執行個體掛了之後，系統還能保證正常工作（除非全部Instance都掛掉，當然，這個機率比一個掛掉的機率小得多）

 

　　接下來，涉及到稍微技術細節一點的東西，讓我們來看看Windows Azure編程模型的細節

  Windows Azure 編程模型的一些工作原理 Fabric Controller

　　Windows Azure 運行在大型的資料中心中，而每一個程式的不同執行個體都會被部署到不同的伺服器上，Fabric Controller管理資料中心裡的電腦。我們部署一個雲端程式的時候實際上是上傳我們的服務組態檔和程式包。設定檔告訴fabric controller使用不同的主機來運行role的執行個體。而一旦部署成功，fabric controller會繼續監控這些程式的運行，當其中某個執行個體掛掉了，它會啟動一個新的執行個體。

 

　　正因為有了Fabric controller，Azure才能夠有如此良好的管理能力，它自動對程式和底層的系統內容進行維護和更新。這樣一來，整個系統具備了良好的抵抗硬體錯誤帶來的停機時間，

　　事實上，在伺服器硬體的選取上，Fabric controller不是隨機的，它把一個role的不同執行個體配置到不同的fault domain（故障域，包括了一系列的硬體，如電腦，交換器等等——顯然，它們是處於一個故障點中的)中，因此，硬體的錯誤不會波及到整個程式的運行。

 　　而在軟體上，當程式的一個執行個體掛了，fabric controller會重啟程式或者重啟程式啟動並執行VM。那麼，Azure又是如何做到讓程式無停機的升級的呢。類似上面的fault domain，在Azure裡，role的不同執行個體位於不同的update domain（更新網域，和fault domain 不同）。當程式的新版部署了以後，fabric controller將關閉一個更新網域的實力，升級之，然後啟動它。之後才對其他更新網域的執行個體挨個處理。這樣就實現了所謂的不下線升級。

　　從伸縮性上看，Azure不僅允許使用者指定某個role要運行多少個執行個體，同時也允許那些負載變化比較大的程式通過Web門戶或者自己開發的程式來即時調整執行個體的數量。

　　技術帶來的這些好處看起來如此的美妙，不過，要謹記的是，Windows Azure是按每個啟動並執行執行個體來收費的，所以要是使用者為了節約成本而僅使用一個instance的話那他就違背了編程模型的三大原則，這樣，也就無法享受到上面說的好處了。 一些更複雜的問題

Windows Azure編程模型所帶來的不只是前面說的那三個原則，從程式的角度看，我們還必須看到的是，這個模型給我們的開發環境帶來了一些新的問題，我們可以將之主要歸納為以下3個方面： instances如何和OS互動 instances如何和持久性儲存互動 instances之間如何互動

　　首先，從作業系統的角度來看，傳統的伺服器系統是由營運團隊來管理的，而在Azure裡面，則是由Fabric Controller來控制，雖然用程式控制自動化程度高，但是我們也會遇到一些問題，比如如何讓程式運行在管理員模式下，此外更加嚴重的問題是，instance所允許的物理伺服器總是在不同的機器上，所以程式寫入本地系統的資訊肯定是無法保證可靠性的。雖然現在Work Role和Web Role可以運行在管理員模式下，但是，上面的問題還是沒有解決的。這也就引出了第二個問題：既然程式寫入本地系統的資訊是沒有保障的，我們編程的時候就必須知道它是非持久性的，而且為了不同的執行個體都能訪問到資料所以資料應該被儲存於role instances之外。

　　同樣的，儲存也必須要有冗餘，也必須能夠處理大量的資料。對於超大型的資料，傳統的關係型系統不是最好的選擇，所以也就有了前文提到的ｂｌｏｂｓ這樣的資料結構。

　　在這個圖例裡，程式使用了兩個Blob和一個Table，但是Azure storage在底層為每個執行個體都維護了一個資料鏡像，同樣也是跨物理系統的，跨故障域的，這樣即使有某些鏡像掛掉了，還是可以用的。不過必須注意的是，Windows Azure的這個機制使得這些資料每次只能被一個執行個體操作（讀寫）

 　　最後我們再來看看instances間的互動，這可是一個複雜的問題（想想進程同步問題）。。 執行個體間的互動

　　通常我們設計程式的時候都會分層（邏輯上的分layer或者物理上的分tier）或者分模組，這些部分通常都需要相互互動的，然而，在Azure中，這樣的互動和傳統程式略有不同。還記得前面提到的特定的一個role的每個執行個體都是等價可替換的嗎。這意味著一個Web role傳了一個請求給Worker Role，但是它不應該去管具體worker role的哪個執行個體來處理這個請求的，甚至，web role都不應該依賴於比如IP地址這樣的依執行個體而變的星系來進行通訊。我們需要一個更加通用的機制。

 

　　在Azure平台上，我們的程式可以使用最通用的Windows azure queues來進行通訊，它的原理如下圖：

　　這個例子裡，一個Web role的某個instance獲得了一個請求1）這個instance建立了一條包含這個請求所需的工作的資訊，並把它寫入Windows Azure queue（記得最上面提到的基本的3中資料結構之一，所以queue和blob一樣基於相同的原理——每個執行個體copy一份） 2），接下來，Worker role從queue中讀取訊息，注意的是它並不管是那個web role寫入的。在處理完工作後從queue中刪除這條訊息，沒錯，你看到的確實是Dequeue後處理完工作再刪除，這和我們理解的普通隊列有所不同，舉例來說，在Microsoft Message Queuing技術裡，一個程式可讀取隊列裡的訊息是一條原子操作，如果讀取訊息的程式出錯，那麼，這個讀事務就會還原，也就是原來的訊息會重現，這樣就保證了MSMQ隊列裡的每一條訊息都能按照發送的順序被正確的提交。但是Windows Azure又有些不同，它不支援事務讀操作，所以它無法保證精確的按需遞交，在Azure裡，一個訊息可以被讀並處理多次。加入某個worker role的執行個體讀了訊息，並且處理完工作了，但是在還沒刪除之前就掛掉了，那麼這條被讀取的訊息在逾時之後就會自動重現。Azure這樣的設計機制據說是在速度和延展性和上面提到的那種可靠性上的取捨——選擇了速度。

　　當然，除了隊列之外，Azure還可以通過API來讓某個執行個體發現其他的特定的執行個體，然後直接發送請求給對方。

 

  總結

　　這篇文章先簡要的介紹了一下Winows Azure Platform上的一些基本概念，然後說明了一下Windows Azure的編程模型的一些原則，並且稍微試探了一下運行在Windows Azure上的程式所需要考慮的事情。總之，在目前看來，Windows Azure相對來說還是比較便於使用的，當然，它還遠不完美，讓我們期待它更加的成熟吧。