Azure 提供了用於運行應用程序的不一樣執行模型。每種模型提供一組不一樣服務,而你選擇哪一種模型徹底取決於你要作什麼。本文介紹三種模型,描述它們的技術並提供相關用例。前端
開發人員、IT 操做人員和其餘人可使用 Azure 虛擬機在雲中建立和使用虛擬機。提供所謂的 Infrastructure as a Service (IaaS),這是一項可普遍使用的技術。圖 1 顯示其基本組件。web
圖 1:Azure 虛擬機可提供"基礎結構即服務"技術。數據庫
如圖所示,可使用 Azure 管理門戶或基於 REST 的 Azure 服務管理 API 建立虛擬機。能夠從包括 Internet Explorer、Mozilla 和 Chrome 在內的任何經常使用瀏覽器訪問管理門戶。對於 REST API,Microsoft 爲 Windows、Linux 和 Macintosh 系統提供了客戶端腳本工具。其餘軟件也可隨意使用此接口。編程
不管你如何訪問此平臺,建立新 VM 都須要爲 VM 的映像選擇一個虛擬硬盤 (VHD)。這些 VHD 將存儲在 Azure blob 中。windows
有兩種選項可供您開始操做瀏覽器
庫中以及 VMDepot 上的 VHD 包含全新的 Microsoft 和 Linux 操做系統映像,以及包含安裝在其上的 Microsoft 和其餘第三方產品的映像。選項一直都在增加。示例包含如下產品的各個版本和配置:服務器
除了 VHD 之外,你還要指定你的新 VM 的大小。Azure 庫 中列出了每一個大小的完整統計信息。網絡
最後,選擇你的新 VM 應在其中運行的 Azure 數據中心(不管是在美國、歐洲仍是亞洲)。app
一旦 VM 開始運行,你將根據其運行按小時付費,並在刪除該 VM 時中止付費。你支付的數額不取決於你的 VM 的使用率,它僅取決於時鐘時間。閒置了一小時的 VM 與負載很重的 VM 的費用相同。框架
每一個運行的 VM 都有一個關聯的 OS disk,該磁盤保存在 Blob 中。當你使用庫 VHD 建立 VM 時,該 VHD 將會複製到你的 VM 的 OS 磁盤中。您對於運行的 VM 的操做系統所作的任何更改都存儲在這裏。例如,若是你安裝可修改 Windows 註冊表的應用程序,該更改將存儲在你的 VM 的 OS 磁盤中。在你下次從該 OS 磁盤建立 VM 時,VM 將繼續在你離開它時的相同狀態下運行。對於存儲在庫中的 VHD,Microsoft 將在須要時應用更新,例如操做系統修補程序。可是,對於你本身的 OS 磁盤中的 VHD,你要對應用這些更新負責(儘管 Windows 更新在默認狀況下處於打開狀態)。
還能夠修改運行的 VM,而後使用 sysprep 工具進行捕獲。Sysprep 可刪除特定內容(例如計算機名稱),所以 VHD 映像可用於建立帶有相同常規配置的其餘 VM。這些映像與你上載的映像一塊兒存儲在管理門戶中,所以它們能夠用做其餘 VM 的起點。
虛擬機還監視託管您建立的每臺 VM 的硬件。若是運行 VM 的物理服務器發生故障,則平臺會注意到此狀況並在另外一臺計算機上啓動相同的 VM。假設你有合適的許可,你能夠從你的 OS 磁盤中複製已更改的 VHD,而後在其餘任何位置(例如你本身的本地數據中心或其餘雲提供程序中)運行它。
除了其 OS 磁盤之外,你的 VM 還有一個或多個數據磁盤。儘管其中每一個磁盤看起來都像是你的 VM 的已裝載磁盤驅動器,但實際上每一個磁盤的內容都存儲在 Blob 中。對數據磁盤所作的每次寫入都將永久存儲在基礎 blob 中。與全部 Blob 同樣,Azure 同時在單個數據中心內和多個數據中心上覆制它們以防止出現故障。
可使用管理門戶、PowerShell 以及其餘腳本工具,或者直接經過 REST API 來管理運行的 VM。(事實上,你經過管理門戶執行的任何操做均可以經過此 API 以編程方式完成。)Microsoft 合做夥伴(如 RightScale 和 ScaleXtreme)也提供依賴 REST API 的管理服務。
能夠普遍使用 Azure 虛擬機。Microsoft 面向的主要方案包括:
雖然這些不是惟一的可能狀況,但它們確實爲你如何使用 Azure 虛擬機提供了很好的示例。
當你使用 Azure 虛擬機建立新 VM 時,能夠選擇獨立運行它,或使它成爲一塊兒在 cloud service中運行的一組 VM 的一部分。(儘管名稱相似,但請不要和表示 Azure PaaS 技術名稱的"雲服務"混淆;這是兩個不一樣的概念)。每一個獨立 VM 都有它本身的公用 IP 地址,而同一雲服務中的全部 VM 均可經過一個公用 IP 地址進行訪問。圖 2 顯示了這種狀況。
圖 2:每一個獨立 VM 都有它本身的公用 IP 地址,而在雲服務中分紅一組的 VM 可經過一個公用 IP 地址來公開。
例如,若是你已建立一個虛擬機來建立並測試一個簡單的應用程序,則你可能會使用獨立 VM。可是,若是你要建立一個多層應用程序,其中包含一個 Web 前端、一個數據庫或許還有一箇中間層,則你極可能如圖 2 所示的那樣將多個 VM 鏈接到一個雲服務。
將 VM 在雲服務中分組還使您可使用其餘選項。Azure 爲同一雲服務中的 VM 提供負載平衡,使用戶請求分散在 VM 上。以這種方式鏈接的 VM 還能夠經過 Azure 數據中心內的本地網絡直接相互通訊。
同一個雲服務中的 VM 還能夠分組爲一個或多個 availability sets。要理解爲什麼這很重要,可考慮一個運行多個前端 VM 的 Web 應用程序。若是全部這些 VM 都部署在同一臺物理計算機上甚至在計算機的同一機架中,單個硬件故障就可能致使它們全都不可訪問。可是,若是這些 VM 分組爲一個可用性集,Azure 就會跨數據中心部署它們,所以任何一個單點故障都不會波及到其餘 VM。
若要更好地理解 Azure 虛擬機的工做原理,有必要給出幾個較爲具體的場景。例如,假設你要建立一個在 Azure 上運行的可靠且可縮放的 Web 應用程序。一種方法是在一個或多個 Azure VM 中運行該應用程序的邏輯,而後使用 SQL Server 進行數據管理。圖 3 顯示了這種狀況。
圖 3:在 Azure 虛擬機中運行的應用程序可使用 SQL Server 進行存儲。
在此示例中,兩種 VM 都是從庫中的標準 VHD 建立的。該應用程序的邏輯在 Windows Server 2008 R2 上運行,所以開發人員今後 VHD 建立三個 VM,而後在每一個 VM 上安裝其應用程序。因爲全部這些 VM 都在同一雲服務中,所以他能夠配置硬件負載平衡來分散請求。開發人員還從庫中包含 SQL Server 2012 的 VHD 建立兩個 VM。在這兩個 VM 運行後,他在每一個實例中配置 SQL Server,以使用具備自動故障轉移功能的數據庫鏡像。這不是必需的,由於應用程序能夠只使用單個 SQL Server 實例,可是採用此方法能夠提升可靠性。
假設某個組織想建立一個 SharePoint 服務器場,但並不但願在本身的數據中心中運行該服務器場。緣由多是本地數據中心缺少資源,或者建立該場的業務部門不但願與其內部 IT 組打交道。在此類狀況下,在 Azure 虛擬機上運行 SharePoint 頗有意義。圖 4 顯示了這種狀況。
圖 4:Azure 虛擬機容許在雲中運行 SharePoint 場。
SharePoint 場有幾個組件,每一個組件在從不一樣 VHD 建立的 Azure VM 中運行。須要如下項目:
儘管圖中未顯示,但此 SharePoint 場可能使用 Azure 虛擬網絡鏈接到本地網絡。這使 VM 以及它們所包含的應用程序對於使用該網絡的人們而言像是位於本地。
如這些示例所示,你可使用 Azure 虛擬機在雲中建立和運行新的應用程序,或以其餘方式運行現有應用程序。不管你選擇哪一個選項,該技術的目標都是相同的:爲公有云計算提供一個通用基礎。
人們經過多種不一樣方式使用 Web 技術。公司可能須要遷移或設置可處理每週數以百萬次的單擊的現有網站,該網站部署在全球若干數據中心中。一個網站設計機構能夠與一組開發人員合做構建一個可應對數以千計用戶的自定義 Web 應用程序。公司開發人員可能須要設置應用程序,以便針對來自其公司 Active Directory 的經身份驗證的用戶在雲中跟蹤費用報表。IT 顧問可使用經常使用的開放源應用程序爲小型企業設置內容管理系統。 可使用 Azure 虛擬機完成全部這些操做。可是建立和管理原始 VM 須要一些技巧和花一點功夫。若是你須要實現一個網站或 Web 應用程序,這裏有一個更容易(也更便宜)的解決方案,這種方法一般稱爲"平臺即服務"(PaaS)。如圖 5 所示,Azure 可爲此提供網站。
圖 5:Azure 網站支持經過各類技術構建的靜態網站、經常使用 Web 應用程序和自定義 Web 應用程序。
Azure 網站在 Azure 雲服務的基礎上構建,用於建立爲運行 Web 應用程序而優化的"平臺即服務"解決方案。如圖所示,網站將在一組可能包含由多個用戶建立的多個網站的單個虛擬機,以及屬於單個用戶的標準 VM 上運行。VM 是經過 Azure 網站管理的資源池的一部分,所以容許得到高可靠性和容錯能力。 入門都很輕鬆。藉助 Azure 網站,用戶能夠從一系列應用程序、框架和模板中進行選擇並在幾秒內建立一個網站。而後,他們可使用最喜歡的開發工具(WebMatrix、Visual Studio、任何其餘編輯器)和源控件選項來設置持續集成,並做爲一個團隊進行開發。依賴於 MySQL 數據庫的應用程序可使用 ClearDB(Microsoft 合做夥伴)爲 Azure 提供的 MySQL 服務。 開發人員可使用網站建立可伸縮的大型 Web 應用程序。該技術支持使用 ASP.NET、PHP、Node.js 和 Python 建立應用程序。例如,應用程序可使用易貼的會話,而現有 Web 應用程序能夠不作任何更改移動到此雲平臺。在網站上構建的應用程序可隨意使用 Azure 的其餘方面,例如 Service Bus、SQL 數據庫 和 Blob 存儲。你還能夠在不一樣 VM 中運行一個應用程序的多個副本,而網站會自動在各 VM 中對請求進行負載平衡。由於新網站實例是在已存在的 VM 中建立的,所以能夠很是快速地啓動新的應用程序實例;這明顯快於等待建立新的 VM。 如 圖 5 所示,你能夠經過多種方式將代碼和其餘 Web 內容發佈到網站中。您可使用 FTP、FTPS 或 Microsoft 的 WebDeploy 技術。網站還支持從源控件系統發佈代碼,例如 Git、GitHub、CodePlex、BitBucket、Dropbox、Mercurial、Team Foundation Server 和基於雲的 Team Foundation Service。
Azure 虛擬機提供 IaaS,而 Azure 網站提供 Web 宿主。第三個計算選項"雲服務"提供 Platform as a Service (PaaS)。這種技術旨在支持可擴展、可靠且運做便宜的應用程序。它還可使開發人員沒必要擔憂管理他們所使用的平臺,而將全副精力用在本身的應用程序上。圖 6 解釋了此概念。
圖 6:Azure 雲服務提供"平臺即服務"功能。
和其餘 Azure 計算選項同樣,雲服務也依賴於 VM。該技術提供了兩個略有不一樣的 VM 選項: web roles實例運行包含 IIS 的 Windows Server 變體,而 worker roles實例運行不含 IIS 的同一 Windows Server 變體。雲服務應用程序依賴於這兩個選項的某種組合。
例如,一個簡單的應用程序可能只使用一個 Web 角色,而一個稍複雜的應用程序可能使用一個 Web 角色來處理來自用戶的傳入請求,而後將那些請求建立的工做傳遞給輔助角色進行處理。(此通訊可能使用 Service Bus 或 Azure 隊列。)
如圖所示,一個應用程序中的全部 VM 都在同一雲服務中運行,如以前對 Azure 虛擬機所述的那樣。所以,用戶經過單個公用 IP 地址訪問應用程序,而請求會自動在應用程序的 VM 上實現負載平衡。與使用 Azure 虛擬機建立的雲服務同樣,該平臺將採用一種可以避免單點硬件故障的方式在雲服務應用程序中部署 VM。
即便應用程序在虛擬機中運行,理解雲服務提供的是 PaaS 而非 IaaS 也很重要。如下辦法有助於理解這一點:使用 IaaS(如 Azure 虛擬機),首先要建立和配置你的應用程序將運行的環境,而後將應用程序部署到此環境中。你要負責該環境的大部分管理工做,如在每一個 VM 中部署操做系統的新修補版本。相反,在 PaaS 中,這樣的環境彷佛早已存在。您只需部署您的應用程序。已爲你處理它所運行的平臺的管理工做,包括部署操做系統的新版本。
使用雲服務,你無需建立虛擬機。相反,你提供一個配置文件,告知 Azure 每一個 VM 須要多少個角色實例(如三個 Web 角色實例和兩個輔助角色實例),平臺將爲你建立它們。雖然你仍然要選擇這些 VM 應該是什麼大小(選項與 Azure VM 的相同),可是你無需親自顯式建立它們。若是你的應用程序須要處理更大的負載,則能夠要求增長 VM,Azure 將建立這些實例。若是負載下降,則能夠關閉這些實例並中止爲它們付費。
一般經過兩個步驟就能使雲服務應用程序可供用戶使用。首先,開發人員將應用程序上載到該平臺的暫存區域。當開發人員準備好使應用程序上線後,他會使用 Azure 管理門戶請求將其投入生產。暫存與生產之間的這種切換無需停機就可完成,這使運行的應用程序可在不打擾其用戶的狀況下升級到新版本。
雲服務還提供監視功能。和 Azure 虛擬機同樣,它將檢測到發生故障的物理服務器,並在新的計算機上從新啓動原先在該服務器上運行的 VM。雲服務不只檢測硬件故障,還檢測發生故障的 VM 和應用程序。與虛擬機不一樣,它在每一個 Web 角色和輔助角色中都存在有代理,所以它可以在發生故障時啓動新的 VM 和應用程序實例。
雲服務的 PaaS 特性還具備其餘含義。其中一個最重要的含義是,應編寫基於此技術構建的應用程序以在任何 Web 角色或輔助角色實例出現故障時正確運行。要實現這一目標,雲服務應用程序不該該在它本身的 VM 的文件系統中維持狀態。與使用 Azure 虛擬機建立的 VM 不一樣,對雲服務 VM 所作的寫入不是持久的;這與虛擬機數據磁盤徹底不一樣。相反,雲服務應用程序應將全部狀態明確寫入 SQL 數據庫、blob、表或其餘某種外部存儲中。以這種方式構建應用程序會使它們更易於擴展、抵抗故障的能力更強,這是雲服務的兩個重要目標。
全部三個 Azure 執行模型都能在雲中構建可擴展且可靠的應用程序。既然在本質上是相似的,你應該使用哪一種模型呢?答案取決於你想要作什麼。
虛擬機提供最通用的解決方案。若是你須要可能的最大控制權,或者須要泛型 VM 以用於開發和測試等目的,這是最好的選擇。虛擬機也是在雲中運行現成本地應用程序的最佳選擇,如上述的 SharePoint 示例所示。同時,由於你使用這一技術建立的 VM 看起來正像是你的本地 VM,因此這也多是災難恢復的最佳選擇。固然,能力越強責任也就越大,IaaS 會要求你承擔一些管理工做。
當你要建立一個簡單的網站時,網站即是合適的選擇。當你想要基於現有應用程序(如 Joomla、WordPress 或 Drupal)建立網站時更是如此。若是建立一個管理任務很少的 Web 應用程序(甚至可擴展性很強的 Web 應用程序),或將現有 IIS Web 應用程序移到公有云中,網站模型也是一個不錯的選擇。它還提供快速部署功能。你的應用程序的一個新實例幾乎能夠當即開始運行,而經過虛擬機或雲服務部署新的 VM 可能須要幾分鐘。
雲服務是 Azure 提供的初始執行模型,它是一個顯式 PaaS 方法。雖然 PaaS 與 Web 宿主之間的界限並不分明,但云服務在一些重要方面與網站不一樣,其中包括:
由於雲服務是 PaaS,因此它還提供了一些超越 Azure 虛擬機的優點。它會爲你完成更多管理任務(如部署操做系統更新),所以你的操做成本極可能低於使用 Azure 虛擬機的 IaaS 方法的成本。
全部這三種 Azure 執行模型都各有優缺點。作出最佳選擇須要瞭解這些內容,明白你要完成的任務,而後從中選出最合適的模型。
有時,單憑一種執行模型可能還不夠。在這樣的狀況下,組合使用模型較爲合適。例如,假設你要構建一個應用程序,既想利用雲服務 Web 角色的管理優點,又須要使用標準 SQL Server 提升兼容性或性能。在此狀況下,最佳選擇是組合使用執行模型,如 圖 7 所示。
圖 7:單個應用程序可使用多個執行模型。
如圖所示,雲服務 VM 在不一樣於虛擬機 VM 的單獨雲服務中運行。儘管如此,兩者仍可高效通訊,因此經過此方法構建一個應用有時是最佳選擇。
因爲雲平臺須要支持多種不一樣方案,因此 Azure 提供了不一樣的執行模型。想要高效使用此平臺的任何用戶(若是你已閱讀至此,可能也包括你)都須要瞭解每種執行模型。