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 ServicesWindows Azure Storage ServicesWindows Azure Platform Management PortalWindows Azure Development EnvironmentWindows Azure Tools for Visual StudioWindows 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相對來說還是比較易於使用的，當然，它還遠不完美，讓我們期待它更加的成熟吧。
轉自：http://blog.csdn.net/cecilulysess/article/details/6324096