本文章是由機器翻譯。

Windows Azure

將應用程式遷入 Windows Azure

Alex Homer

 

生活專家會告訴您，遷入新居是我們一生當中遇到的壓力最大的事件之一；可如果讓我們在搬家和將應用程式移到新平臺之間作出選擇，很多人會毫不猶豫地開始收拾瓶瓶罐罐。 然而，令人欣慰的是，將應用程式遷入 Windows Azure 可謂輕而易舉。

多年來，Microsoft 一直在其遍佈世界各地的資料中心中構建高度可伸縮的應用程式。這些應用程式服務全球並具有高可用性，為使用者提供強大的功能。 您可以利用 Windows Azure 的這一基礎結構部署您自己的應用程式，使其具備同樣的能力，從而降低維護需求、最大化性能並最小化成本。

多年來，人們往往將其應用程式的部署外包給協力廠商託管公司。 具體方式可以是租用位於遠端資料中心中的機架空間或伺服器，用來安裝並運行其應用程式，或者僅是從託管公司租用 Web 服務器和資料庫的空間。 但是無論哪種方式，所提供的功能種類通常比較有限。 一般而言，沒有身份驗證機制、訊息佇列、流量管理、資料同步或其他週邊服務，而這些都是 Windows Azure 的標準服務。

所有這些能力使應用程式遷入 Windows Azure 看似相當複雜，但是只要花時間權衡您的需求並研究可用功能，遷入 Windows Azure 的過程非常快速且相對簡單。 為了説明您理解各種選項並作出正確決策，Microsoft 的模式和實施方案小組近期出版了 Windows Azure 遷移指南的新版本：「將應用程式遷入 Windows Azure 上的雲」(msdn.microsoft.com/library/ff728592)。

該指南涵蓋了將應用程式遷入 Windows Azure 的各種場景。 在下文中，我將探討這些場景，列出您將需要作出的決策，並瞭解如何採用指南提供的實用建議説明您作出恰當的選擇。 雖然指南所遵循的步驟人為劃分為多個步驟，且不太可能完全照搬，但該指南所演示的大部分選項及所展示的 Windows Azure 功能均可用於您的應用程式。 圖 1（源自該指南）展示了一個遷移路徑概念圖，可供您在將應用程式從內部資料中心遷入 Windows Azure 時遵循。

圖 1 Windows Azure 中某些可能的遷移路徑的概念圖

基礎結構託管還是平臺託管？

如您在圖中所見，在遷入 Windows Azure 時，首先要決定遵循哪條路線 — 基礎結構即服務 (IaaS) 還是平臺即服務 (PaaS)。

顧名思義，IaaS 方法提供了運行時基礎結構 — 如虛擬伺服器和網路連接，您可以自行選擇要安裝的作業系統、服務和應用程式。 實際上，您只是選擇伺服器，然後在 Microsoft 資料中心中的運行。 Windows Azure 提供了各種預先安裝作業系統（如 Windows Server 和 Linux）可供選擇，並且您仍可以利用週邊服務，如通過 Windows Azure Active Directory 的身份驗證、與 Windows Azure 存儲佇列或服務匯流排的消息傳遞、通過流量管理器實現的至應用程式全域路由等等。

或者，您可以採用 PaaS 方法，讓 Microsoft 為您管理作業系統和運行時平臺。 Windows Azure 網站為 Web 應用程式及網站提供了便於使用的託管平臺，該平臺支援簡單的管理和部署，可與很多源控制系統直接集成，並支援各種程式設計語言。 如果您要獲得對平臺的更多控制，包括能夠混合運行不同類型的角色以及直接集成緩存的能力，您可以選擇雲服務方法。 雲服務方法使您可以分別部署 Web 和輔助角色；提供了更廣泛的配置選項；並且非常適合分版本、分階段的部署環境。

您將在本文後面看到，IaaS 與 PaaS 之間的選擇不僅限於應用程式代碼。 遵循 IaaS 路線時，可選擇部署預先安裝 SQL Server 或 MySQL 等資料庫的 Windows Azure 虛擬機器 (VM)。 而對於 PaaS 路線，Windows Azure 還提供了名為 Windows Azure SQL 資料庫的託管資料庫機制，該資料庫實際上是一個託管的 SQL Server 實例，可按與內部 SQL Server 幾乎相同的方式使用該資料庫。

借助 IaaS 攀上雲端

使用 IaaS 方法來託管應用程式有很多獨特的優點。 例如，您可能無需對應用程式代碼進行任何更改，就能遷入雲中的 VM，並通過虛擬網路將其連接到內部網路和域，並且所有測試、部署、管理和監視系統將和往常一樣繼續進行。

實際上，您所做的一切就是將您內部資料中心中的乙太網電纜替換成與 Windows Azure 的 Internet 連接。 通過標準虛擬私人網路 (VPN) 路由器，Windows Azure 虛擬網路可將內部網路連接到您在雲中配置的網路中，讓您像在內部網路一樣，使用內部網路 IP 位址。 是的，這種連接方式會導致一些額外延遲，並且您還要考慮如何處理意外的暫態連接故障，但是您不再需要管理和更新硬體、基礎結構和作業系統。 （若要處理很多不同類型的操作的暫態連接故障，可考慮使用 Microsoft 暫態故障處理應用程式塊。 如需更多資訊，請參閱 msdn.microsoft.com/library/hh680934(PandP.50)。）

當您需要運行軟體或服務，卻無法獲得原始程式碼或無法修改應用程式（如依賴于協力廠商應用程式）時，使用 Windows Azure VM 的 IaaS 方法是理想的選擇。 如果需要對作業系統或常規服務採用非標準配置，或者對檔和資源設置特定許可權，這種方法也效果良好。

對於測試和部署而言，開發團隊察覺不到 IaaS 與現有過程有何不同。 內部開發電腦和構建伺服器可部署到 Windows Azure 中的測試和生產環境，或者可以將測試和構建伺服器放入雲中。 圖 2（基於該指南中的圖）顯示了測試和部署配置的示例，此配置涵蓋了內部測試和雲託管測試兩種環境，使用了兩個單獨的 Windows Azure 訂閱 — 一個用於測試，一個用於即時應用程式。

圖 2 一種可行的開發、測試和部署機制的概覽

所以，在選擇 Windows Azure IaaS 方法時，唯一真正的區別是應用程式不再運行于您自己的昂貴、配備空調的伺服器機房內，這種方式消耗資源，對 Internet 連接的頻寬有相當的要求。 對比之下，應用程式將運行在您所選擇的 Microsoft 資料中心中，這意味著對 VM 的更改將持久存儲在原始映射的備份存儲中，始終提供可靠的連接，並且運行時平臺將確保應用程式不間斷提供服務。

此外，您可以從各種規格的 VM 中進行選擇；根據需要更新運行的實例；按照應用程式的特定需求配置作業系統及其服務；部署額外的實例來滿足負載變化；甚至設置自動路由，將請求分散至不同資料中心中的部署，從而最大化可用率、最大程度降低遍佈全球的使用者的回應時間。

用 PaaS 簡化管理

如果要避免自己管理作業系統，可以選擇 PaaS 方法。 的確，這意味著您將放棄某些配置您自己的運行時平臺的機會，但是，因為 Microsoft 負責維護伺服器、更新作業系統和應用補丁，這將減少管理工作和運維成本。 您只需將精力集中于應用程式代碼及其與週邊服務的交互。

將網站或 Web 應用程式遷入 Windows Azure 的最簡單方法是將其部署到 Windows Azure 網站；應用程式所需的更改（即使有）非常少。 您可以從 Microsoft Team Foundation Server (TFS) 或其他原始程式碼存儲庫系統（如 GitHub）上部署。 根據您的需求和託管預算，您可以選擇託管在共用 Web 服務器或專門保留的伺服器實例上，從而保證性能並管理實例數量以滿足要求。

或者，如果需要內置機制進行分版本部署和分階段應用，以及單獨擴展應用程式某些部分的自由度，您可以採用 Windows Azure 雲服務 Web 和輔助角色來託管應用程式。 通過將背景工作移入輔助角色，並將 UI 放入 Web 角色，您可以平衡應用程式上的負載、執行非同步幕後處理，並通過為每個角色類型運行適當數目的實例，實現每種角色類型的可伸縮性。

（在雲服務部署中，為了按預定義時程表或回應運行時事件 [如伺服器負載變化] 實現角色的自動擴展，請考慮使用 Microsoft 自動擴展應用程式塊。 如需更多資訊，請參閱 msdn.microsoft.com/library/hh680892(PandP.50)。）

為了連接 Web 和輔助角色，通常需要使用 Windows Azure 存儲佇列或 Windows Azure 服務匯流排佇列，將資料以消息的形式在二者之間傳遞。 （服務匯流排佇列可支援更大的消息，並且具有內建的身份驗證和存取控制機制。）使用消息還為設計帶來新的機制，允許使用標準消息和存儲模式，如請求/回應、即發即棄、延遲寫入等等。 如果應用程式遵循面向服務體系結構 (SOA) 設計按元件的方式構建，那麼將其遷入 Windows Azure 雲服務會相對簡單。

當然，使用 Web 和輔助角色可能意味著需要部分重構應用程式。 但是，在很多情況下，這並不麻煩，而且不會影響核心業務邏輯或呈現代碼。 例如，ASP.NET MVC 應用程式在遷入 Windows Azure 後工作良好，並且它們可訪問 SQL Server 之類的資料存儲，與其在內部運行，或使用 IaaS 方法部署到 VM 的情形完全一樣。

遷入 Windows Azure 雲服務，還可以對身份驗證和授權機制進行更新，這對您發現需要執行某些代碼重構時頗為有用。 新型應用程式越來越多的採用基於聲明的身份驗證機制，其中包括聯合身份標識和單一登入 (SSO)。

這類機制允許使用者使用一系列現有憑據登錄，並不要求提供僅針對應用程式的特定憑據，並且在訪問多個應用程式或網站時，只需要登錄一次。 Windows Azure Active Directory 存取控制功能，連同 Windows Identity Framework (WIF)，使得基於聲明的身份驗證和聯合身份標識很容易實現。 圖 3（基於該指南中的圖）展示了一個示例，這是虛擬公司 Adatum 的 a-Expense 應用程式，其中使用者通過其本身的 Active Directory 驗證身份後獲得一個權杖，向應用程式出示該權杖即可獲得存取權限。

圖 3 採用基於聲明的身份驗證系統

有關基於聲明的身份驗證的更多資訊，請參閱的模式和實施方案出版物「A Guide to Claims-Based Identity and Access Control」（基於聲明的身份標識和存取控制指南），位址是 msdn.microsoft.com/library/ff423674。

我的資料存在哪裡？

幾乎所有商務應用程式都使用資料，並且通常這些資料都存儲在資料庫中（如 SQL Server）或來自其他供應商的關係資料庫管理系統 (RDBMS) 中。 遷移使用關係資料庫的應用程式時，典型場景是部署一個託管資料庫伺服器的 Windows Azure VM（Windows Azure 提供了包含 SQL Server 或 MySQL 的預配置 VM）。 或者，您可以在 Windows Azure 中運行的 VM 上，安裝幾乎任何其他類型運行于 Windows 或 Linux 系統的資料存儲。

您從雲託管的應用程式連接到雲託管的資料庫，如同資料庫和應用程式位於您自己的資料中心中一樣。 但是，這只是 Windows Azure 提供的選擇之一。 通常，您將需要確定是將應用程式的資料部署在雲中，還是將其留在內部，是通過虛擬網路，還是通過消息傳遞與資料庫伺服器通信。 如果選擇雲，您還需要確定是遵循 IaaS 路徑，還是遵循 PaaS（SQL 資料庫）路徑。

命令查詢職責分離 (CQRS) 模式通常使用消息傳遞機制在應用程式元件之間傳輸資料更新和查詢結果；為此，Windows Azure 提供了兩種排隊機制供應用程式使用。 但是，對於應用程式和資料庫之間的標準資料訪問需經由網路，如 Internet，延遲將不可避免並相應導致性能低下。 如果環境或法規需求強制使用內部資料庫，Windows Azure 緩存可有助於降低這些延遲。 （有關 CQRS 模式的更多資訊，請參閱相關的模式和實施方案指南「CQRS Journey」（CQRS 之旅），位址是 msdn.microsoft.com/library/jj554200。）

在遷移使用 SQL Server 的現有應用程式時，Windows Azure SQL 資料庫是常規資料存儲的理想解決方案。 除非代碼要求某些更複雜的 SQL Server 功能—如無格式文本搜索、XML 處理能力、需要 CLR 程式設計的過程，或依賴 SQL Server Service Broker 的分散式查詢，否則現有應用程式無需改動便可使用。

Windows Azure SQL 資料庫在只需要存儲通常規模的資料時，非常經濟高效。 但是，對於極大量的資料，或需要部署很多資料庫時，使用託管在 VM 中的資料庫伺服器將成為有吸引力的解決方案。 您可以選擇相應大小的 VM，甚至使用多個 VM 來實現資料庫容錯移轉或共用資料存儲。

有時，關係資料庫系統的能力無法滿足資料存儲和查詢的需要。 例如，公司的 Web 服務器日誌、金融交易檔、社交媒體資訊、醫療資料或其他類型的資料，通常達到 PB 的級別，這些資料不經常得到處理，但是可能偶爾使用或供未來查詢之用。 Windows Azure 特為此情形提供了 HDInsight 服務（基於開源的 Hadoop 技術）。 有關詳細資訊，請參閱 hadooponazure.com。

表、Blob、查詢和磁碟機

Windows Azure 還提供了另一種類型的存儲，這種類型並不基於關係 SQL 模式。 您可以使用 Windows Azure 存儲表和 blob 來存儲應用程式資料、使用存儲佇列在應用程式元件和存儲磁碟機之間傳遞消息，這種方式類似于傳統的基於磁片的檔案系統。

Windows Azure 存儲表採用無 schema 的機制，這意味著每一行是包含一組屬性值的實體，並且表中各行的實體類型可以不同。 這對於結構化（列和行）和半結構化資料非常理想。 另一方面，Windows Azure 存儲 blob 更適合存儲文檔、二進位資料、XML 檔和圖像之類的非結構化資料。

相比使用 VM 託管的資料庫伺服器或 SQL 資料庫，Windows Azure 存儲費用非常低廉，但是這確實意味著現有資料存取碼必須重寫。 通常，對於從新設計在 Windows Azure 中運行的應用程式而言，Windows Azure 表和 blob 將更加有用。 但是，如果應用程式具有一個明確界定的資料訪問層，並且可以替換成專為使用 Windows Azure 表和 blob 而設計的層，那麼切換到使用 Windows Azure 存儲，而不是關係資料庫，就變得相當容易。

與所有基於雲的服務一樣，可能會有暫態網路問題或間斷，並且資源的臨時性不足可能造成初始連接請求失敗。 暫態故障處理應用程式塊（前面提過）可用於自動檢測故障，並重試所有存儲操作，包括關係資料庫和 Windows Azure 存儲。 這是所有基於雲的應用程式的良好做法，並且暫態故障處理應用程式塊使其實現起來非常容易。

輔助角色和背景工作

Windows Azure 雲服務的優勢之一是，提供了專為執行幕後處理而設計的特殊類型角色。 輔助角色不限於只作為應用程式的輔助部分使用；實際上，它是無需安裝 Web 服務器 (IIS) 的 Web 角色。 但是，典型場景是在輔助角色中運行持續任務，這些任務偵聽 Windows Azure 佇列（或服務匯流排佇列），以獲取指示角色在後臺執行某些操作的消息，如圖 4 中所示。

圖 4 從 Web 角色到輔助角色傳遞消息

以這種方式將非同步背景工作獨立出來，有助於實現很多基本的應用程式設計原則，如關注點的分離和單一責任。 通過在角色之間以消息的方式傳遞資訊和命令，有助於每個角色的封裝並降低依賴性，這與應用 SOA 原則別無二致。

例如，該指南探討了 Adatum 如何使用輔助角色壓縮和存儲使用者上載的收據圖像以便節省存儲空間，以及如何使用這些角色將開支資料匯出到 Adatum 工資單應用程式。 兩種任務都由存放在佇列中的消息發起。 消息包含各個任務所需的資料。

在您為了部署到 Windows Azure 雲服務角色而重構應用程式時，適合在輔助角色中運行的任務通常顯而易見。 背景工作也可按照計畫安排啟動，並且只需加入用於重新開機任何可能失效或停滯的程式的代碼，就可以在輔助角色中運行多個任務來最大程度降低託管成本。 Windows Azure 確實能檢測到角色何時失效，並且將嘗試重新開機，但是它不能檢測角色中的各個任務何時失效。

您還必須考慮如何處理背景工作的任何回饋或輸出。 例如，您可能決定使用延遲寫模式來存儲使用者提交的訂單的詳細資訊，而這些訂單封裝在 UI 發送給輔助角色任務的消息中。 輔助角色將從佇列中讀取消息，並在資料庫中存儲這些詳細資訊。 但是，如果訂單數量只在存儲時生成，那麼這將使輔助角色難以將此訂單數量返回給 Web 角色以供在 UI 中顯示。

我用得起 Windows Azure 嗎？

如您所見，Windows Azure 提供了範圍廣泛的功能和服務，應能滿足您應用程式的所有需求，即使您目前尚未明確全部需求。 您可以部署到位於世界各地的任何資料中心，並利用龐大的存儲和可伸縮能力。 但是，我是否確實能承受將應用程式託管在 Windows Azure 中？

在該指南的第 6 章「評估雲託管成本」中，Adatum 嘗試了多種成本評估，以瞭解在 Windows Azure 中運行其 a-Expense 應用程式，會被收取大約多少費用。 該應用程式將使用一個 Web 角色和一個輔助角色，並且將在關係資料庫中存儲約 20 GB 資料，在 Windows Azure 存儲中存放 120GB 的圖像。 按目前價格，Adatum 預計費用約 3,000 美元每年。 雖然 Adatum 無法準確計算在其自己的資料中心運行此應用程式的成本，因為所用到的很多資源都與其他本地應用程式共用，但是 Windows Azure 的預期成本相比之下將非常有吸引力。

不僅如此，通過引入自動擴展解決方案（如企業庫自動擴展應用程式塊），Adatum 計算發現，如果僅在辦公時間內運行應用程式，但在每個月末需對大部分支出進行歸檔時添加額外的角色實例，使其容量加倍，可將總體成本縮減到每年約 2,000 美元。 此外，如果將應用程式修改為使用 Windows Azure 表和 blob，而不用 SQL 資料庫或 SQL Server，Adatum 計算表明每年可再節省 750 美元。

當然，您自己的應用程式容量需求和運作計畫會有所不同，並將取決於應用程式必須應對的負載及其所需的存儲空間。 但是，似乎可以清楚地看到，您可以承受託管在 Windows Azure 中，並且這樣的遷移將比您舉家搬進新居壓力要小得多！

詳細資訊

模式和實施方案指南「將應用程式遷入 Windows Azure 上的雲」可從 msdn.microsoft.com/­library/ff728592 獲得。 您可以從 microsoft.com/download/details.aspx?id=29252 下載該指南的 PDF 副本。

模式和實施方案的相關指南和框架有：

• 針對雲開發多租戶應用程式：msdn.microsoft.com/library/ff966499
• 在 Windows Azure 上的雲中構建混合應用程式：msdn.microsoft.com/library/hh871440
• 基於聲明的身份標識和存取控制指南：msdn.microsoft.com/library/ff423674
• 暫態故障處理應用程式塊：msdn.microsoft.com/library/hh680934(PandP.50)
• 自動擴展應用程式塊：msdn.microsoft.com/library/hh680892(PandP.50)

可以訪問位於 windowsazure.com 的 Windows Azure 主頁，Windows Azure 開發人員中心位於 windowsazure.com/en-us/develop/overview。

Alex Homer is a technical writer assigned to the Microsoft patterns & practices division in Redmond, Wash. However, he has so far resisted the dubious attractions of Seattle weather in favor of working from home in the idyllic rural surroundings of the Derbyshire Dales in England.他所寫的關於 IT 行業和日常生活的漫談隨筆可在 blogs.msdn.com/alexhomer 上找到。

衷心感謝以下技術專家對本文的審閱： Masashi Narumoto
Masashi Narumoto 是模式和實施方案的高級專案經理。 他的工作內容是 Windows Azure 指南系列，目前的主要工作是大資料。 以前，他有 20 多年的時間在開發各種解決方案並提供相應諮詢服務，尤其是零售和製造業。 可以在 HTTP://blogs.msdn.com/masashi_narumoto 或 Twitter 上的 @dragon119 找到他。