匯出 (0) 列印
全部展開

您的應用程式適合 Azure 嗎?

更新日期: 2014年4月

作者: Jason Roth
審稿者:Paulette McKay、Ralph Squillace、Sidney Higa、Brian Swan、Larry Franks

如果您正考慮使用 裝載應用程式,則可能會想要知道平台是否能夠為您的應用程式或商務需求提供最佳服務。您可以在 上裝載大部分的應用程式和電腦。不過,有些案例更善於利用在雲端執行的優點。在下列各節中,本文將概述這些優點和案例,以告知您移轉至 的最佳決策:

其目的是要提供一個架構來思考應用程式以及它與 功能之間的相關性。許多情況下會提供其他資源的連結。這些資源將提升您分析應用程式以及決定如何移至雲端的能力。

在您可以判斷應用程式是否適合 之前,必須先了解平台的一些主要優點。您可以在 Azure 文件庫以及許多文章和影片中找到有關 的完整優點清單。雲端最佳化 -- 擴充功能,同時配合運算和商務需求是討論雲端優點的一份絕佳文件。

同時也必須了解在 上執行應用程式的三個主要選項: 網站雲端服務虛擬機器。「網站」和「雲端服務」都是「平台即服務 (PaaS)」方案。這表示 所有提供所有硬體和作業系統映像。您可以提供在平台上執行的應用程式程式碼。「虛擬機器」提供「基礎結構即服務 (IaaS)」方案。這表示您可以管理在 資料中心內執行的機器映像。這三個選項具有各種優點,而您的選擇需取決於許多因素。不過,由於有了這些不同的選項和功能,幾乎所有應用程式都十分適合 。

在雲端中執行應用程式有一些主要優點。讓我們以高層級看看其中的一些優點,然後我們再討論利用這些功能的情況。

當您將應用程式和服務部署至雲端時, 會提供必要的虛擬機器、網路頻寬和其他基礎結構資源。如果機器因為硬體更新或非預期的失敗而當機, 會自動為您的應用程式尋找新的虛擬機器。

因為您只需要針對使用的部分付費,所以一開始的投資可以少一點。這樣做可避免支出內部部署所需的典型前期成本。這對於小型公司特別有用。在內部部署案例中,小型組織可能沒有成功部署應用程式所需的資料中心空間、IT 技能或硬體技能。 所提供的自動基礎結構服務為應用程式部署和管理提供一個低障礙的入口。

動態調整指的是根據資源需求向外和向內延展應用程式的能力。這也稱為「彈性延展」(Elastic Scale)。在描述其運作方式之前,請先針對使用「雲端服務」的 應用程式查看其典型架構。如果使用「雲端服務」,您會建立一起工作的角色,以便實作應用程式邏輯。例如,單一 Web 角色可能會裝載應用程式的 ASP.NET 前端。一個或多個背景工作角色可能會執行必要的背景工作。一部或多部虛擬機器會裝載每個角色;這些在 資料中心中稱為角色執行個體。要求將會橫跨這些執行個體進行負載平衡。如需有關角色的詳細資訊,請參閱 Azure 程式設計模型文件。

在此情況下,您也可以隨著資源需求增加而佈建新的角色執行個體,以便處理負載。當需求降低時,便可以移除這些執行個體,讓您不必支付不必要的運算能力。您也可以選擇根據預先定義的規則和原則自動增減規模。這與內部部署非常不同 (您必須超額佈建硬體,以符合尖峰需求)。如果您想要更進一步地控制平台所提供的自動調整,則可以使用 Microsoft Patterns and Practices 團隊所建立的自動調整應用程式區塊

雖然前一個案例描述「雲端服務」內容中的動態調整,但是您也可以向外擴張「網站」和「虛擬機器」的規模。如果您的應用程式對運算資源的需求經常波動或無法預測, 可讓您輕鬆地調整您的資源使用量來符合負載。

能為高可用性應用程式提供平台,此平台可透過儲存體服務或 Microsoft Azure SQL Database 可靠地儲存及存取伺服器資料。

首先, 會確保運算資源的高可用性。就「網站」而言,只要單一實例就能滿足服務等級協定 (SLA) 的需求。就「雲端服務」和「虛擬機器」而言,則每種角色或電腦類型都至少要有兩個執行個體,才能符合 SLA 需求。就「虛擬機器」而言,其執行個體必須可以交換、進行負載平衡,而且屬於同一個可用性群組。在各種情況下, 會監視可裝載這些虛擬機器和執行個體的實際硬體。 可以藉由部署新的執行個體或者將應用程式的程式碼和處理移至其他運作中硬體,針對硬體重新啟動或失敗狀況迅速做出回應。

第二, 會針對透過其中一個儲存體服務儲存的資料而確保其高可用性和耐久性。 儲存體服務會將所有資料至少複製到三部不同的伺服器。依預設,此儲存體也會複寫到次要的 區域。同樣地,Azure SQL 資料庫 會複製所有資料,以確保可用性和耐久性。

其他 服務會提供類似的高可用性保證。如需詳細資訊,請參閱 Azure 業務續航力技術指引

在了解 平台的優勢後,您就可以開始查看最適合雲端的情況。下列章節會討論其中幾種情況以,並說明 為何非常適合某些工作負載和目標。Azure 設計模式影片會說明底下的許多案例,並提供 平台的良好概觀。

Tip提示
雖然這裡的焦點是應用程式案例,但您還是可以選擇使用個別的 服務。例如,如果使用 Blob 儲存體便可以解決應用程式問題,則應用程式的其餘部分便可以保留在雲端外部。這稱為「混合式應用程式」(Hybrid Application),本主題稍後將會討論。

非常適合裝載高可用性的服務。假設有一家線上商店部署在 中。由於線上商店是收入來源,所以一定要維持運作狀態。 資料中心執行服務監視和自動執行個體管理,即可完成這項作業。線上商店也必須維持對客戶需求的高度回應能力。 的彈性調整能力即可達成。在尖峰購物時間,新的執行個體會上線來處理增加的使用量。此外,線上商店不能遺失訂單或無法完整處理客戶下的訂單。 儲存體和 Azure SQL 資料庫 都會提供高可用性且耐久的儲存選項,以保存整個訂單週期的訂單詳細資料和狀態。您可以將相同的應用程式部署至多個 區域,以獲得最高層級的可用性。即使整個 區域發生暫時失敗,還是可以設計保持可用的服務。這樣做需要有路由傳送使用者的正確同步處理架構和程序。

另一種適合 的方式是某種形式的「開啟和關閉」工作負載。某些應用程式不需要持續執行,一個簡單的範例就是您只想要在幾天或幾週中使用的示範或公用應用程式。 可讓您輕鬆地建立和部署該應用程式以及與全世界分享。但是,一旦完成其目的後,您便可移除應用程式,而且您只需要針對部署它的時間付費。

note附註
注意:您必須移除部署,而不只是暫止應用程式,才能避免運算時間的費用支出。

也假設有一家大型公司,它會在每月的月底執行複雜的銷售數字資料分析。雖然這需要大量處理,但是完成分析所需的總時間至少為兩天。在內部部署案例中,此工作所需的伺服器在大多數的時間並未充分利用。在 中,公司只需針對分析應用程式在雲端所執行的時間而付費。假設應用程式的架構是專為平行處理而設計。 的向外延展功能可讓公司建立大量的背景工作角色執行個體或虛擬機器。搭配運作,即可在更少的時間內完成更複雜的工作。在此範例中,您應該使用程式碼或指令碼,在每個月的適當時間自動部署應用程式。

所有企業都有快速且持續成長的目標。但是,傳統的內部部署模型很難處理成長。如果預期的成長不會發生,您會花費許多金錢來維護利用不足的硬體和基礎結構。但是,如果成長的速度比預期中還要快,您可能無法處理負載,因而導致失去業務機會和客戶體驗不佳。對小型公司而言,甚至可能發生初始資本不足,而無法準備或跟得上快速成長。

非常適合處理這個情況。假設有一個小型的運動新聞網站靠廣告賺錢,它的收入金額直接與網站產生的流量成比例關係。在此範例中,收入的初始資本受到限制。此外,公司也不需要為了設定和執行自己的資料中心而準備大筆預算。透過設計,只要網站在 上執行,公司就可以輕鬆地將方案部署為 ASP.NET 應用程式。應用程式會針對關聯式資料使用 Azure SQL 資料庫,並針對圖片和影片使用 Blob 儲存體。如果網站的普及率大幅成長,公司就可以增加前端的 Web 角色執行個體數目。公司也可以增加 Azure SQL 資料庫 的大小。Blob 儲存體在 內有內建延展性功能。如果業務減少,公司可以移除任何不必要的執行個體。因為其收入與網站的流量成比例關係,所以 可幫助公司以小規模的方式開始運作、快速成長並降低風險。

有了 ,您對於判斷管理運算成本的積極程度有完全的控制權。您可能會決定使用「自動調整」功能或透過自動調整應用程式區塊來實作自動調整。這可以根據自訂規則來新增和移除執行個體。您可也可以選擇根據預先決定的數量來改變執行個體數目。例如,在上班時間有四個執行個體,在非上班時間則有兩個執行個體。您也可以讓執行個體數目維持不變,並在一段時間的需求增加時透過入口網站手動增加數目。 讓您擁有很大的彈性來做出適合公司的決策。

有另外一個工作負載模式需要彈性延展。假設之前的運動新聞網站範例,當其業務穩定成長時,依然有暫時的尖峰或活動暴增的可能性。例如,另一個熱門的新聞媒體會參照網站。單日的網站訪客數目可能會大幅增加。在可預測性更高的情況下,重大體育賽事和運動錦標賽也會導致網站的活動增加。

另一個範例是在每天結束時處理每日報表的服務。當工作日結束時,每個辦事處都會傳入公司總部所處理的報表。因為此程序每天只作用幾個小時,所以它也是彈性調整和部署的候選項目。

非常適合暫時向外延展應用程式來處理負載尖峰,經過事件後再調整回來。

如之前的範例所示,許多最常見的雲端案例都會利用 的彈性延展。不過,即便是具有穩定工作負載模式的應用程式還是可以在 中實現成本節約。管理自己的資料中心需要大量成本,特別是當您考慮能源成本、員工技能、硬體、軟體授權和設備等事項時。此外,了解成本如何與個別應用程式緊密相連也很困難。在 中,其目標是降低總成本以及讓這些成本更為透明。建議您閱讀雲端最佳化 -- 擴充功能,同時配合運算和商務需求文件。本文件完整說明典型的內部部署裝載成本以及如何使用 降低這些成本。

虛擬機器和虛擬網路能為內部部署伺服器和網路提供移轉至雲端最簡單的方式。將內部部署應用程式轉換至「雲端服務」或「網站」,也會減少對內部部署資料中心的壓力。 現在負責為該類應用程式提供必要的運算和儲存體資源,而非內部部署資料中心。

提供可了解特定成本的定價計算機。也提供擁有權總成本 (TCO) 計算機,可預估採用 之後將能降低多少整體成本。如需計算機工具和其他定價資訊的連結,請參閱 Azure 網站

具有幾乎適合任何應用程式的服務和選項。它們橫跨 PaaS 選項 (例如「雲端服務」和「網站」),以及含有「虛擬機器」和「虛擬網路」的 IaaS。不過,有些情況保證會以較慢的速度移轉至雲端,或根本不移轉至雲端。

其中一種情況是預測不到成長的小量應用程式或服務。在內部部署商用硬體上執行該應用程式的成本,低於在雲端中執行相同作業的成本。這有兩個例外狀況。移至 的優點多於簡單裝載成本。例如,您可能不想要管理伺服器、其可用性和資料持續性。其次,使用 網站,會有小量網站的免費裝載選項。例如,您可能會使用此選項來裝載個人 WordPress 部落格。

另一個情況涉及無法移至 的資料。企業和政府有時會規範可位於雲端中的資料類型。在這些情況下,您可能會考慮使用混合式方案。在此執行個體中, 只會裝載應用程式中非機密且需要高度可用的特定資料或特定部分。

藉由了解 的優勢,您可以辨識將不會利用這些優勢的應用程式或應用程式部分。然後您可以順利開發最有效利用 功能的整體解決方案。

評估是否要移至 的程序當然會牽涉到許多因素,而不只是了解您的應用程式或業務目標是否適合雲端而已。此外,評估現有或新的應用程式的架構和開發特性也很重要。快速開始這項分析的方式就是使用適用於 的 Microsoft 評定工具 (MAP)。這項工具會詢問一些問題,以判斷移至 時可能發生的問題類型。每個問題的旁邊有一個稱為「查看完整考量」的連結,此連結會提供有關 中該特定領域的其他資訊。這些問題和其他資訊可協助您為雲端中應用程式的現有或全新設計識別出可能的變更。

除了 MAP 工具以外,您對於 平台的基本知識應該有紮實的理解。其中包括了解常見的平台設計模式。針對 ,您也應該考慮檢閱技術海報。這些海報具有平台功能的豐富資訊,以及其他資訊的連結。請檢閱 中所提供的各種服務,並考慮如何將其納入您的方案。如需 服務的概觀,請參閱<何謂 Azure?>。在規劃架構時,請檢閱<Azure 訂閱和服務限制、配置及條件約束>。

本文件將不會涵蓋 解決方案的所有可能考慮事項和緩和方式。不過,下表會列出四個常見的設計考量以及其他資源的連結。

 

區域 描述

IaaS 或 PaaS?

「基礎結構即服務 (IaaS)」可讓您將專屬的映像放在 的「虛擬機器」上。這通常是移轉至雲端較簡單的方式,因為應用程式架構變更較少。

網站和 雲端服務提供「平台即服務 (PaaS)」。您為 PaaS 環境所設計的應用程式通常會比 IaaS 上的類似方案更具彈性、擴充性且易於管理。不過,一般需要較多的時間才能完成「雲端服務」的移轉。「網站」提供 PaaS 優點與 IaaS 易於移轉之間的平衡。

若要從 Web 觀點更清楚地了解這些選項,請參閱 Azure 網站、雲端服務和虛擬機器的比較

混合式解決方案

將複雜的舊版應用程式移至 可能很困難。有時在雲端中儲存某些類型的資料也有一些法規顧慮。Azure 信任中心提供一些有關安全性和法規相符性的答案。

為了克服這些挑戰,其中一個方案是建立混合式應用程式,以連線 所裝載的服務與內部部署應用程式和資料。有多種 技術支援這項功能,其中包括服務匯流排虛擬網路。如需詳細資訊,請參閱在 Azure 上建置雲端中的混合式應用程式

狀態管理

如果您是將現有應用程式移至 虛擬機器,則處理狀態資料的方式通常會與透過內部部署方式處理地一樣。不過,如果您想要利用 雲端服務的 PaaS 架構,則必須評估狀態處理方式。許多內部部署應用程式會將狀態儲存在本機硬碟上。其他功能 (例如預設 ASP.NET 工作階段狀態) 則會使用本機電腦的記憶體來管理狀態。雖然雲端服務角色可以存取其虛擬機器的本機磁碟空間和記憶體,但是 會在所有角色執行個體之間針對所有要求進行負載平衡。此外,您的角色執行個體可能會隨時中斷及移動 (例如,當執行此角色執行個體的電腦需要更新時)。

運作中角色執行個體的動態管理對於 雲端服務的延展性和可用性功能非常重要。因此,您必須將雲端中的應用程式程式碼設計為可使用 儲存體或 Azure SQL 資料庫 這類服務而在遠端儲存資料和狀態。如需有關儲存選項的詳細資訊,請參閱 網站的儲存和存取資料章節中的資源。

儲存需求

Azure SQL 資料庫 是 中的關聯式資料庫解決方案。如果您目前使用 SQL Server,轉移到 Azure SQL 資料庫 應該比較容易。您也可以選擇在「虛擬機器」上執行 SQL Server。如果您是使用不同的資料庫系統,其中一個選項是移轉至「虛擬機器」上的 Azure SQL 資料庫 或 SQL Server。有一些 SQL Server 移轉小幫手可協助您執行此程序。如需有關移轉資料至 Azure SQL 資料庫 的詳細資訊,請參閱<Azure SQL Database 的資料移轉:工具和技巧>。另一個選項是將協力廠商資料庫直接移轉至 。其中一個技術是在「虛擬機器」上安裝資料庫系統。不過,Azure 市集中還有 MySQL 和 MongoDB 這類系統的一些協力廠商方案。

也請考慮將 儲存體當做耐久、高度可用且可擴充的資料儲存體使用。良好的設計模式會有效結合使用 Azure SQL 資料庫 和 儲存體資料表、佇列和 Blob。常見範例是使用 Azure SQL 資料庫 將 Blob 的指標儲存至 儲存體。請這麼做,而不要將二進位大型物件儲存至資料庫本身。這樣不但有效率,而且也符合成本效益。

互通性

適用於 Visual Studio 的 SDK 和工具可大幅簡化建立 .NET 應用程式或將其移轉至 的程序。

但是,如果您使用開放原始碼軟體或協力廠商開發語言和工具,又會如何呢? 網站和雲端服務支援使用 Node.js、PHP、Python 和 Java (僅限雲端服務) 所寫的應用程式。如果您的應用程式使用另一種語言,請考慮使用「虛擬機器」。使用 服務時,所有作業都是以 REST API 為基礎。您可以直接編寫此項目的程式碼。不過, 也提供 Java、Node.js、PHP、Python 和 Ruby 的正式 SDK,其提供 REST API 的友善包裝函式。也有社群建立的 SDK 可以與 互動。

根據您的技術而定,當然必須要應付一些難題。針對「虛擬機器」,您必須安裝電腦映像的必要執行階段和依存性。針對「雲端服務」,您可能需要新增自訂啟動動作,以安裝您角色的協力廠商依存性。針對「網站」,您可能需要進行少量修改,以允許應用程式在 PaaS 裝載環境中工作。這個領域有一個很棒的資源稱為互通性橋接和實驗室中心

重要的是可以使用各種語言來存取 。因此,您應該先查看特定所選語言的選項,再決定應用程式是否為 的不錯候選項目。

除了這些問題之外,您還可以藉由檢閱移轉應用程式至 的相關內容,深入學習可能的開發挑戰和解決方案。Microsoft 的 Patterns and Practices 群組已發佈下列移轉指引:在 Microsoft Azure 平台上將應用程式移至雲端

提供一個平台來建立和管理可高度擴充且高可用性的服務。有兩個 PaaS 方案 (「網站」和「雲端服務」) 以及一個含「虛擬機器」的 IaaS 方案。除了這些方案之外,還有許多支援服務和功能可支援許多不同的應用程式案例。您只需要針對所需的資源付費,然後隨時向上和向下延展。而且,您不必擁有硬體或支援的基礎結構也可以達成這個目的。如果您的公司可以利用此平台來提高靈活度、降低成本或風險,則 非常適合您的應用程式。在做出這個決定之後,您可以尋找使用此平台的特定架構和開發選項。其中包括有關新的開發、移轉或混合式情況的決定。在這項分析結束時,您會擁有作出明智決定所需的必要資訊,從而已最有效的方式使用 以達成業務目標。

顯示:
© 2014 Microsoft