匯出 (0) 列印
全部展開

Azure 雲端服務中大規模服務設計的最佳作法

更新日期: 2014年1月

作者:Mark Simms 和 Michael Thomassy

參與作者:Jason Roth 和 Ralph Squillace

審稿者:Brad Calder、Dennis Mulder、Mark Ozur、Nina Sarawgi、Marc Mercuri、Conor Cunningham、Peter Carlin、Stuart Ozer、Lara Rubbelke 和 Nicholas Dritsas。

雲端運算是一種分散式運算,不論平台的選擇為何,分散運算都需要審慎的規劃和傳遞。本文的目的是為了提供以真實世界的客戶案例為根據的適當指引,以便在 Azure 和 SQL Database 上建立可擴充的應用程式,充分利用平台即服務 (PaaS) 方法 (這類應用程式會使用 Web 角色和背景工作角色建立為 Azure 雲端服務)。

Important重要事項
注意:本文的所有最佳作法指引都來自在 Azure 上使用實際執行之程式碼的客戶所進行的深入業務開發。本文會討論根據 v1.6 SDK 版本的 Azure 雲端服務 (PaaS) 平台,但是不會涵蓋 Azure 網站Azure 虛擬機器 (IaaS) 等功能。

本文涵蓋建立 Azure 應用程式的基礎設計概念、主要 Azure 平台功能、限制和特性,以及使用 Azure 核心服務的最佳作法。焦點是那些遵守鬆散一致性分散式資料存放區的應用程式 (與嚴格一致性或高密度的多租用戶資料模型相反)。

將應用程式和服務的層面移到 Azure 可能會因為許多原因而有吸引力,例如:

  • 將資本開支保留或合併到營運開支 (從 capex 到 opex)。

  • 藉由更符合需求和容量來減少成本 (並提高效率)。

  • 藉由減少或移除基礎結構障礙來提高靈活度及縮短上市時間。

  • 擴大新市場 (例如行動裝置) 的接觸客群。

  • 藉由在地理位置分散的資料中心建立可支援整體客群的新應用程式,從大規模的雲端運算獲益。

有許多絕佳的技術原因可開發新的應用程式或是將現有應用程式的全部或一部分移植到 Azure。因為環境有豐富的實作替代方案,所以必須謹慎評估您的特定應用程式模式,才能選取正確的實作方法。某些應用程式非常適合 Azure 雲端服務 (稱為平台即服務或 PaaS 方法),也有其他應用程式可能會因為部分或完整的基礎架構即服務 (或 IaaS) 方法而獲益,例如 Azure 虛擬機器。最後,這兩者一起使用時,可能最能滿足某些應用程式需求。

您的應用程式應該有以下三個主要層面的其中一個或多個,才能讓 Azure 雲端服務的優點最大化 (並非所有的這些層面都必須出現在您的應用程式中;應用程式可能會藉由充分利用只包含以下一個層面的 Azure 而獲得極大的投資報酬率。不過,未呈現這些特性的工作負載可能不適合 Azure 雲端服務)。

應用程式應該評估的重要層面為:

  • 彈性需求。移到 Azure 的其中一個重要價值主張為彈性延展:能夠新增或移除應用程式的容量 (向外延展和向內延展),更密切地配合動態使用者需求。如果您的工作負載具有靜態、穩定的需求 (例如,靜態的使用者、交易等數目),這項 Azure 雲端服務優點不會最大化。

  • 分散式使用者和裝置。在 Azure 上執行可讓您立即存取應用程式的全域部署。如果您的工作負載有固定的使用者客群在單一位置執行 (例如單一辦公室),雲端部署可能不會提供最佳投資報酬率。

  • 可分割的工作負載。雲端應用程式會藉由向外延展進行擴充,藉此增加以較小區塊為單位的更大容量。如果您的應用程式取決於向上延展 (例如,大型資料庫和資料倉儲) 或是專門且專用的工作負載 (例如,大型、統一的高速儲存體),則在向外延展服務上必須將它分解 (分割),才能在雲端中使用。根據工作負載而定,這可能是重要的練習。

重申:在評估應用程式時,如果您的工作負載只有上述三個層面的其中一個在類似 Azure 雲端服務的平台即服務環境中佔有重要地位,您可能會因為在 Azure 雲端服務上移動或建立而獲得高的投資報酬率。具有所有三種特性的應用程式可能會看到很高的投資報酬率。

雖然為 Azure 設計應用程式的許多層面與內部部署開發很類似,但是基礎平台和服務的行為模式有幾個主要差異。在雲端中傳遞可實現彈性延展承諾的應用程式時,了解這些差異以及如何為平台進行設計 (不能反對平台) 是非常關鍵的。

這一節概述五個重要概念,這些概念是在針對類似 Azure 雲端服務的平台即服務 (PaaS) 環境建立大規模、廣泛分散的向外延展應用程式時的關鍵設計重點。了解這些概念將可幫助您設計和建立不但能在 Azure 雲端服務上執行,也會在那裡蓬勃發展並且傳回您的許多投資優點的應用程式。本文稍後討論的所有設計考量和選擇都與這五個概念的其中一個有關。

此外也請注意,雖然許多考量和最佳作法是透過 .NET 應用程式的觀點來檢視,但是基礎概念和方法大多與語言或平台無關。

從內部部署應用程式移到 Azure 雲端服務的主要轉換與應用程式的擴充方式有關。建立較大應用程式的傳統方法取決於向外延展 (無狀態的 Web 伺服器和應用程式伺服器) 及向上延展 (購買較大的多核心/大量記憶體系統、資料庫伺服器,建立較大的資料中心等等) 的混合。在雲端中,向上延展不是一個實際的選擇,要達到真正的可擴充應用程式的唯一路徑是透過向外延展的明確設計

因為內部部署應用程式的許多元件都已經遵守向外延展 (Web 伺服器、應用程式伺服器),所以挑戰在於識別應用程式的哪些層面相依於向上延展服務以及將其轉換 (或對應) 為向外延展實作。向上延展相依性的主要候選項目通常是關聯式資料庫 (SQL Server/Azure SQL Database)。

傳統關聯式設計將焦點放在整體一致的資料模型 (單一伺服器向上延展) 並且具有高度一致性和交易式行為。針對這個備援存放區提供擴充的傳統方法一直是「讓所有項目變成無狀態」,將管理狀態的責任推延給向上延展 SQL Server。

不過,SQL Server 的絕佳延展性其實明顯缺少了真正的彈性延展。也就是說,您必須另外購買更大的伺服器,這樣不但需要高成本的移轉階段、容量遠超過需求而且每次向上擴充時都必須購買,而此無法提供非常靈敏的資源可用性。此外,在擴充過去的中檔硬體時,還必須考量指數成本曲線。

隨著 Azure 雲端服務架構支柱的向外延展,應用程式也必須設計為可搭配向外延展的資料存放區一起運作。這也就意味著一些設計挑戰,例如明確地將資料分割為較小的區塊 (每一個區塊都可放入資料分割或向外延展單位) 以及管理分散式資料元素之間的一致性。這會透過資料分割來達成延展,達成的方式可避免向上延展設計的許多缺失。

從已知的向上延展技術樞紐轉換為向外延展資料和狀態管理通常是雲端設計所面臨的最大障礙之一;本文的焦點在於應付這些挑戰,以及設計應用程式來充分利用 Azure 雲端服務和 Azure SQL Database 的可擴充、彈性功能,以管理耐久性的資料。

在您運作自己的資料中心的環境下,您幾乎擁有無限度的控制權,同時並列著幾乎無限的選擇。從實體工廠 (空調、電力供應、樓層空間) 到基礎結構 (機架、伺服器、儲存裝置、網路等等) 到組態設定 (路由拓撲,作業系統安裝) 都在您的控制下。

這樣的控制程度也必須支付成本 - 資本、營運、人力和時間。在靈活且變動的環境中管理所有細節的成本是將磁碟機虛擬化的核心,也是邁向雲端的一個關鍵層面。在放棄某些控制程度時,這些平台會減少部署、管理的成本並增加靈活性當做回報。它們所加諸的限制如下:可用元件和服務的大小 (容量、輸送量等) 會限制為一組固定的供應項目。

為了使用類比,商業大量運送主要是根據運送容器。這些容器可由各種不同的運輸工具 (船隻、火車和卡車) 運送,而且有各種不同的標準大小 (最長可到 53 英尺)。如果您想要運送的貨物數量超出最大拖車的容量,您必須使用:

  • 使用多部拖車。這張發票會將貨物切割 (分割) 成適合不同的容器,並協調處理拖車的運送。

  • 使用特殊運送方法。如果貨物無法分配到標準容器中 (太大、過於笨重等等),則必須使用專業方法,例如駁船。這些方法通常比標準貨物運送更為昂貴許多。

將這項類比帶回 Azure (及一般的雲端運算),每一項資源都有限制。假如是個別角色執行個體、儲存體帳戶、雲端服務或甚至是資料中心 – Azure 中的每個可用資源都有某些有限的限制。這些可能是非常大的限制,例如資料中心的可用儲存體數量 (類似於最大貨輪如何運送超過 10,000 個容器),不過,它們是有限的。

在考慮這一點時,延展的方法如下:分割負載,並在多個延展單位中組合負載,這些單位可能是多個 VM、資料庫、儲存體帳戶、雲端服務或資料中心。

在本文中,「延展單位」一詞指的是可以 (a) 處理定義的負載程度以及 (b) 組合在一起來處理額外負載的一組資源。例如,Azure 儲存體帳戶的大小上限為 100 TB。如果您需要儲存 100 TB 以上的資料,您必須使用多個儲存體帳戶 (即至少兩個儲存體延展單位)。

每個 Azure 核心服務或元件容量的一般設計指引將於稍後的章節討論,我們也會建議組合這些服務來提供額外擴充的方法。

我們已經投入了極大的時間、精力和智慧資本來建立非常靈活的內部部署應用程式。這通常歸結於將應用程式分為低狀態的元件 (應用程式伺服器、網路) 和高狀態的元件 (資料庫、SAN),並讓每一個元件對失敗模式保有恢復功能。

在本文的上下文中,失敗模式指的是結合 (a) 觀察處於失敗狀態的系統而且 (b) 是因為失敗原因。例如,因為密碼更新設定不正確而無法存取資料庫就是一個失敗模式;失敗狀態是指無法連接 (連接遭到拒絕、認證不被接受),而且失敗原因是因為密碼更新未適當傳送給應用程式程式碼。

低狀態元件會透過鬆散結合的備援性提供恢復功能,並將其整合到外部系統管理的系統中。例如,將額外的 Web 伺服器放在負載平衡器背後;每一部 Web 伺服器都與其他伺服器相同 (讓新增容量成為複製基本 Web 伺服器映像的工作),並整合到負載平衡器管理的整體應用程式中。

高狀態元件會透過緊密結合的備援性提供恢復功能,而且元件之間會緊密管理「整合」。範例如下:

  • 。在主動/被動叢集中新增重複的 SQL Server 執行個體需要仔細選擇相容 (即相同) 的硬體和共用儲存體 (例如 SAN),才能在多個節點之間提供交易一致性的容錯移轉。

  • 電力供應。提供重複的電力供應呈現非常複雜的範例,因為這需要多個系統一致行動,才能減少本機 (伺服器的多個電源供應器,並有內建硬體可在主要和次要供應器之間切換) 和整個中心 (停電時的備用發電機) 的問題。

以緊密結合的方法為根據的恢復功能解決方案原本就比鬆散結合的「增加更多複製東西」方法需要更多成本,因為前者需要訓練有素的人員、專業硬體及周密的組態設定和測試。這樣不但很難做到完美,而且通常也需要極高的成本。

這個方法將焦點放在確保硬體平台具有高彈性,所以可視為「鈦蛋殼」。為了保護蛋的內容,我們覆蓋了一層強硬 (且昂貴) 的鈦殼。

大規模的執行系統經驗 (請參閱 http://www.mvdirona.com/jrh/TalksAndPapers/JamesRH_Lisa.pdf 取得進一步的討論內容) 已經顯示,在任何夠大的系統中 (例如 Azure 規模的資料系統),僅只是實體移動組件的數目就會導致系統的某些片段總是毀損。Azure 平台的設計方式能夠配合這項限制來運作 (而不是反對此限制),它會依賴節點層級的失敗事件進行自動復原。此設計意圖會流經所有核心 Azure 服務,而且也是設計可搭配 Azure 可用性模型使用之應用程式的關鍵。

轉換到 Azure 會將有關恢復功能的對話從基礎結構備援性挑戰變成服務備援性挑戰。許多在內部部署主控可用性規劃的核心服務持續在 Azure 中運作:

  • SQL Database 會自動維護多個交易一致的資料複本。資料庫的節點層級失敗會自動容錯移轉到一致的次要複本;與這項簡單經驗提供的內部部署恢復功能所需的時間和成本形成對比。

  • Azure 儲存體會自動維護多個一致性資料複本 (若要進一步閱讀,請參閱 http://sigops.org/sosp/sosp11/current/2011-Cascais/11-calder-online.pdf)。存放磁碟區的節點層級失敗會自動容錯移轉到一致的次要複本。但是 SQL Database 與這項完全管理的經驗形成對比,因為這項管理會在內部部署叢集或 SAN 中直接管理彈性的儲存體。

不過,本章節的標題為可用性,不是恢復功能。恢復功能只是在 SLA 的界限內持續提供價值給使用者之整體故事的一部分。如果服務的所有基礎結構元件都是狀況良好,但是此服務無法處理預期的使用者數量,則無法使用此服務,它也無法提供價值。

行動或社會中心的工作負載 (例如具有行動裝置應用程式的公用 Web 應用程式) 通常遠比鎖定目標客群的工作負載更為動態,而且也需要更複雜的方法來處理突發事件和尖峰負載。為 Azure 應用程式設計可用性的重要概念將於本文詳細討論,而且將根據以下樞紐:

  • Azure 中的每個服務或元件都會提供某個服務等級合約 (SLA),這個 SLA 不能與執行應用程式所需的可用性度量直接相關。了解所有系統中的元件、其可用性 SLA,以及它們如何互動是了解可傳遞給使用者之整體可用性的關鍵。

    • 請避免會將您的 SLA 降級的單一失敗點,例如單一執行個體角色。

    • 組合或遞補多個元件,以減少特定服務離線或無法使用的影響。

  • Azure 中的每個服務或元件都會遇到失敗,不論是短暫的暫時性還是長期的事件。您的應用程式應該要撰寫成能夠正常地處理失敗。

    • 如果是暫時性失敗,請提供適當的重試機制來重新連接或重新提交工作。

    • 如果是其他失敗事件,請提供與失敗事件有關的豐富檢測 (報告錯誤給操作人員),並將適當的錯誤訊息回報給使用者。

    • 可能的話,請遞補到不同的服務或工作流程。例如,如果將資料插入 SQL Database 的要求失敗 (基於任何非暫時性理由,例如無效的結構描述),請以序列化格式將資料寫入 blob 儲存體。這樣會允許持續擷取資料,並且在解決結構描述問題之後將資料提交給資料庫。

  • 所有服務都將有尖峰容量,不論是明確性 (透過節流原則或尖峰負載邊緣線) 還是隱含性 (藉由達到系統資源限制)。

    • 設計您的應用程式在達到資源限制時正常處理降級,並採取適當的動作來軟化對使用者的影響。

    • 實作適當的退避/重試邏輯,避免對服務產生「護航」作用。如果沒有適當的退避機制,下游服務在遇到尖峰事件之後絕對不會有機會趕上 (因為您的應用程式將持續嘗試發送更多負載到服務中,而觸發了節流原則或導致資源耗盡)。

  • 可導致急促事件的服務必須正常地處理超出其尖峰設計的負載,通常是透過脫落功能。

    • 就像人體在遇到極端寒冷的氣候時會限制血液流向四肢一樣,請將您的服務設計為可在極端負載事件中讓不重要的服務脫落。

    • 這裡的推論是,並非應用程式提供的所有服務都有同等商業重要性,而且可能受限於 SLA 的差異。

描述核心 Azure 服務的每一個章節都將更詳細地套用這些高層級的概念,同時也將說明每一個服務或元件的可用性目標以及如何針對可用性進行設計的建議。請記住,資料中心仍然是大型應用程式的單一失敗點;從電力供應 (請參閱這裡的範例) 到系統錯誤 (請參閱這裡的範例),基礎結構和應用程式問題會導致資料中心當機。需要最高執行時間等級的應用程式應該部署在多個重複的資料中心,雖然這個情況比較少見。

將應用程式部署在多個資料中心需要一些基礎結構和應用程式功能:

  • 可將服務的使用者路由傳送到適當資料中心的應用程式邏輯 (根據地理位置、使用者資料分割或其他同質邏輯)。

  • 資料中心之間的應用程式狀態同步處理和複寫,並具有適當的延遲和一致性層級。

  • 應用程式的獨立部署,好讓資料中心之間的相依性降到最低 (也就是說,避免資料中心 A 的失敗觸發資料中心 B 的失敗情況)。

在可用性方面,提供災害復原解決方案 (萬一資料中心遺失時) 需要大量的時間、精力和資本。本章節將著重於系統故障和資料遺失 (不論是系統還是使用者觸發) 時提供業務續航力的方法和考量,因為「災害復原」一詞已採用資料庫社群內有關實作方法的具體內涵。

提供業務續航力分為:

  • 在基礎結構發生災難性的失敗時,維護重要商業系統 (針對持久狀態操作的應用程式) 的存取和可用性。

  • 在基礎結構發生災難性的失敗時,維護重要商業資料 (持久狀態) 的存取和可用性。

  • 萬一操作人員發生錯誤或意外刪除、修改或損毀時,維護重要商業資料 (持久狀態) 的可用性。

在傳統上,前兩個元素都一直在地理災害復原 (geo-DR) 的內容中處理,第三個元素則屬於資料備份和資料還原的領域。

Azure 大幅變更重要商業系統可用性的方程式,讓地理位置分散的主要應用程式快速部署到全球的資料中心。推出地理位置分散的應用程式的程序確實與推出單一雲端服務稍微不同。

主要的挑戰依然是管理持久狀態的存取;橫跨資料中心存取持久狀態服務 (例如 Azure 儲存體和 SQL Database) 通常會產生次佳的結果,因為會有高度及/或變動的延遲,而且萬一資料中心發生失敗便無法滿足業務續航力需求。

在恢復功能方面,許多 Azure 服務會提供 (或是在其藍圖中擁有) 自動地理複寫。例如,除非明確設定,否則 Azure 儲存體中的所有寫入 (blob、佇列或資料表) 都會自動複寫到另一個資料中心 (每個資料中心在相同地理區域內都有特定「鏡像」目的地)。這樣會大幅減少在 Azure 之上提供傳統式災害復原解決方案所需的時間和精力。稍後的章節會提供管理持久狀態之核心 Azure 服務的地理複寫功能概觀。

如果在遇到使用者或操作人員錯誤時要維護業務續航力,您可以在應用程式設計中納入幾個額外考量。當 Azure 儲存體透過儲存體分析功能提供受限的稽核功能時 (稍後的章節會描述),它不會提供任何時間點還原功能。在意外刪除或修改時需要恢復功能的服務必須著重以應用程式為中心的方法,例如定期將 blob 複製到不同的儲存體帳戶。

SQL Database 會提供維護資料記錄快照集的基本功能,包括資料庫複製及透過 bacpac 匯入/匯出。這些選項會在本文的稍後詳細討論。

有了 Azure 平台提供的彈性延展,供給曲線可以緊密符合需求曲線 (而不會有大量額外容量來代表尖峰負載)。

有了彈性延展,貨物的成本是由以下項目驅動:

  • 在某個情況下使用的延展單位數;VM、儲存體帳戶等等 (為了延展而組合)

  • 這些延展單位執行工作的效率。

我們指的是,可以針對給定的容量執行多少工作當做應用程式的密度。更密集的服務和架構允許針對給定的資源部署執行更大量的工作;也就是說,增加密度會縮減部署的容量 (和成本),或者能夠以相同部署的容量來吸收額外的負載。密度是由兩個主要因素所驅動:

  • 延展單位內執行工作的效率。這是傳統形式的效能最佳化 – 管理執行緒競爭和鎖定、最佳化演算法、微調 SQL 查詢。

  • 工作在延展單位之間協調的效率。如果系統是由更多的較小單位所組成,能夠有效率地將這些單位連結在一起是提供效率的關鍵。這牽涉到橫跨元件進行通訊的架構和工具,例如 SOAP 訊息堆疊 (例如 WCF、ORM (如 Entity Framework))、TDS 呼叫 (SQL 用戶端程式碼) 和物件序列化 (例如資料合約或 JSON)。

除了針對單一電腦 (或資料庫) 使用的傳統最佳化技術之外,最佳化分散式通訊和作業對於提供可擴充、有效率的 Azure 服務非常關鍵。之後的章節會詳細涵蓋這些重要的最佳化:

  • 大量而對話不多。對於每個分散式作業而言 (也就是產生網路呼叫的作業),封包框架、序列化、處理等作業都有一些負擔。為了讓負擔降到最低,請嘗試批次處理成更少數的「大量」作業,而不是大量的「多對話」作業。請牢記,批次處理細微作業確實會增加延遲及可能資料遺失的機會。適當批次處理行為的範例如下:

    • SQL。在單一批次中執行多個作業。

    • REST 和 SOAP 服務 (例如 WCF)。充分利用以訊息為中心的作業介面,而不是多對話的 RPC 樣式,並盡可能考慮以 REST 為根據的方法。

    • Azure 儲存體 (blob、資料表、佇列)。依批次發佈多個更新,而不是個別發佈。

  • 序列化的影響。在電腦之間移動資料 (以及移入和移出持久的儲存體) 通常需要將資料序列化成電傳格式。這項作業的效率 (也就是所花的時間和耗用的空間) 會快速主導大型系統的整體應用程式效能。

    • 充分利用高效率的序列化架構。

    • JSON 用於與裝置通訊或是互通 (可讀取) 的應用程式。

    • 當您控制兩個端點時,請使用非常有效率的二進位序列化 (例如 protobufAvro) 來進行服務與服務之間的通訊。

  • 使用有效率的架構。有許多豐富的架構可供開發,而且包含大量、複雜的功能集。許多這些架構的缺點是您通常必須針對您不使用的功能支付效能成本。

    • 在泛型介面背後隔離服務和用戶端應用程式開發介面,以允許取代或並存評估 (透過靜態 Factory 或逆轉控制項容器)。例如,針對泛型介面工作 (而非特定實作,例如 Azure Caching) 來提供可插入的快取層。

在上一節中,我們引進了建立應用程式的主要設計概念和觀點,這些應用程式會充分利用 Azure 提供的雲端網狀架構。這一節我們將會探索核心平台服務和功能,並說明其功能、延展界限和可用性模式。

因為每個 Azure 服務或基礎結構元件都會提供具有可用性 SLA 的有限容量,所以針對您的延展性目標和使用者 SLA 做出適當的設計選擇時,了解這些限制和行為非常關鍵。每個核心 Azure 服務都會呈現在四個關鍵樞紐的內容中:功能及其意圖、密度、延展性和可用性。

Azure 訂用帳戶是管理、計費和服務配額的基本單位。每個 Azure 訂用帳戶都有一組預設配額,您可以連絡支援人員來提高這些配額,而且這些配額的目的是為了防止意外的超支和資源耗用。

每個訂用帳戶都有帳戶擁有者和一組共同管理員,這些角色是透過 Microsoft 帳戶 (先前稱為 Live ID) 來授權,而且可透過管理入口網站來完全控制訂用帳戶中的資源。它們可以建立儲存體帳戶、部署雲端服務、變更組態,以及新增或移除共同管理員。

Azure 管理應用程式開發介面 (以 REST 為根據的 Web 服務) 會提供自動化介面來建立、設定和部署 Azure 服務 (由表面之下的管理入口網站使用)。對這些應用程式開發介面的存取會使用管理憑證加以限制。

 

服務 預設限制

雲端服務

20

儲存體帳戶

20

核心

20

SQL Database 邏輯伺服器

5

Tip提示
如需最新的 Azure 訂閱和服務限制,請參閱<Azure 訂閱和服務限制、配額及條件約束

Azure 雲端服務 (先前稱為託管服務) 是部署和延展的基本單位。每個雲端服務都由兩個部署 (實際執行與預備) 所組成,每一個部署都有一組角色。雲端服務針對實際執行部署具有公用 DNS 項目 (servicename.cloudapp.net 的形式),而且針對預備部署具有 DNS 項目 (someguid.cloudapp.net 的形式)。

每個部署都包含一個或多個角色,可以是 Web 角色或背景工作角色,而且這些角色會包含一個或多個執行個體 (非耐久性的 VM)。每個執行個體都針對該角色包含相同、不變、非耐久性的軟體封裝快照集 (也就是說,給定角色中的所有執行個體都有部署相同的組建)。這些執行個體會執行 Azure 專用版的 Windows Server (許多服務在預設情況下為了額外的安全性都已停用,而且設定為能夠與 Azure 網路和服務網狀架構等項目一起順利運作),而且預設會由 Azure 架構自動修補。即時修補是透過輪流升級計畫進行處理,如底下所述。

雲端服務可以直接部署到任何 Azure 資料中心 (在建立服務時選取目的區域),或是透過同質群組來部署。同質群組是部署目的地的間接參考,可用來簡化將應用程式的所有元件部署到相同資料中心的程序。

Web 角色會使用裝載應用程式程式碼的 IIS 執行個體預先設定。裝載於背景工作角色中的應用程式程式碼會在預先設定的長期主應用程式中執行。每個雲端服務最多可能會有 25 個角色。角色預設組態是為了執行 .NET 程式碼,但是角色可以設定為執行與 Windows Server 相容的任何程式碼 – Java、Python、Ruby、node.js 等等。本文所參照的所有平台功能都可從任何平台使用,但是可能需要額外的用戶端 - Proxy 開發來鎖定以 REST 為根據的應用程式開發介面。

在雲端服務中,所有執行個體都會被指派私用 IP 位址 (在 10.x 區塊中);所有傳出的連接透過網路位址轉譯似乎都來自單一虛擬 IP 位址或 VIP (雲端服務部署的 VIP)。所有傳入的連接都必須通過設定的端點;這些端點會提供內部角色和連接埠的負載平衡存取。例如,根據預設,與雲端服務部署的傳入 HTTP/HTTPS (連接埠 80 和 443) 連接會針對主要 Web 角色的所有可用執行個體進行負載平衡。

請注意,跨服務延遲 (也就是從一個雲端服務周遊 NAT,並透過負載平衡器周遊到另一個雲端服務) 遠比同等的內部部署架構更具有變動性,這也是鼓勵針對延展性採用批次處理或「大量」跨服務連接的其中一個理由。

Azure 網狀架構也提供一個組態服務,可供雲端服務部署的所有執行個體使用。服務定義中會提供一組靜態的預期組態金鑰 (開發週期的一部分),其中包含最初的一組部署的組態值以及發佈給 Azure 時的服務。這一組組態值可當做執行階段查閱提供給服務部署中的所有執行個體使用,而且可能會在執行階段透過 REST 介面、Azure 入口網站或 PowerShell 指令碼加以修改。

一旦變更執行階段組態,所有執行個體都可能會選擇 (在應用程式程式碼中) 攔截組態變更通知,並在內部處理組態更新。如果未撰寫應用程式程式碼來擷取組態變更事件,此角色的所有執行個體都會遇到輪流重新開機,以更新其組態。

每個執行個體的狀態都不會持久;基本 Azure 映像之上的任何組態 (專門的 Windows Server VM) 需要啟動的組態,以建立效能計數器、調整 IIS 設定、安裝相依軟體等等。這些組態指令碼通常會當做雲端服務組態定義的啟動工作來執行。

在雲端服務內,Azure 網狀架構會提供有關組態的資訊、內部 IP 位址、服務組態等等,而且會透過 RoleEnvironment 提供。在 Azure 執行個體上執行的所有處理序都可以存取 RoleEnvironment 資訊,以擷取組態、探索網路拓撲等等。您也可以使用 Azure 管理應用程式開發介面,從外部存取這項資訊。

Azure 網狀架構會公開管理元件失敗、重新組態和升級/修補的兩個核心概念:升級網域和故障網域。

升級網域是 Azure 服務內的邏輯群組;每個服務預設都有五個升級網域 (這個值可能會在雲端服務定義中修改)。任何服務變更或升級一次只會影響單一升級網域。這些變更的範例包括修補作業系統、變更虛擬機器大小、將角色或角色執行個體新增至執行中的服務,或是修改端點組態。

如此可以即時方式重新設定執行中雲端服務的組態,同時維護可用性。如果是只包含單一執行個體的角色,則 Azure 網狀架構將無法在升級作業期間提供可用性,這也是執行中的單一執行個體角色不符合 Azure SLA 的原因。

故障網域是以基礎硬體為根據的邏輯群組。雖然不保證可直接對應到任何特定的硬體組態,但是可將此邏輯群組視為 Azure 網狀架構從代表單一失敗點的基礎資源 (例如單一基礎實體伺服器、機架等等) 自動分隔執行個體的一種方式。若要符合此服務 SLA,Azure 至少必須部署執行個體到兩個故障網域。這是單一執行個體角色部署不符合 Azure SLA 的另一個原因。

總結:

  • Azure 中的部署和延展的基本單位是由一組角色組成的雲端服務。每個角色都包含一組相同的角色執行個體,每個執行個體都會執行雲端專門設定版本的 Windows Server。

  • 除了實體拓撲 (角色和執行個體) 和應用程式程式碼以外,雲端服務也會定義整個服務的組態。這個組態可能會在執行階段更新。

  • 每個角色執行個體都是非耐久性 (變更,檔案等項目不保證在重新開機、修補或失敗事件時可以持續保存)。

  • 每個雲端服務都會針對傳入和傳出流量公開單一虛擬 IP。雲端服務會公開端點,端點則會提供與內部角色和連接埠之間的 (循環配置資源) 負載平衡對應。

  • Azure 會使用升級網域,以邏輯方式分隔執行個體群組,並提供輪流升級或修改 (同時維持可用性)。

  • Azure 會使用故障網域來以實體方式分組執行個體,使其遠離單一失敗點 (例如在相同基礎實體電腦上執行的所有執行個體)。

  • 充分利用多個訂用帳戶,以隔離開發、測試、預備和實際執行環境。

每個角色都包含由一個或多個執行個體組成的一組執行個體。每一個執行個體都是 VM,並且執行專門版本的 Windows Server。執行個體 (VM) 目前有提供五個大小;從超小到超大。每一個大小都有配置某些數量的 CPU、記憶體、儲存體和頻寬。

 

虛擬機器大小 CPU 核心數目 記憶體 Web 角色和背景工作角色中本機儲存體資源的磁碟空間 VM 角色中本機儲存體資源的磁碟空間 配置的頻寬 (Mbps)

超小

共用

768 MB

19,480 MB

(保留 6,144 MB 給系統檔案)

20 GB

5

小型

1

1.75 GB

229,400 MB

(保留 6,144 MB 給系統檔案)

165 GB

100

中型

2

3.5 GB

500,760 MB

(保留 6,144 MB 給系統檔案)

340 GB

200

大型

4

7 GB

1,023,000 MB

(保留 6,144 MB 給系統檔案)

850 GB

400

超大

8

14 GB

2,087,960 MB

(保留 6,144 MB 給系統檔案)

1890 GB

800

Tip提示
如需最新的 Azure 訂閱和服務限制,請參閱<Azure 訂閱和服務限制、配額及條件約束

假設有兩個或多個執行個體部署在不同的故障網域和升級網域,Azure 會針對雲端服務提供下列 SLA:

  • 99.95% 外部連接供面對網際網路的角色使用 (也就是具有外部端點的角色)

  • 99.9% 會在兩分鐘內偵測角色執行個體問題,並啟動更正動作

角色執行個體大小和計數都可能會在執行中的應用程式內動態變更 (請注意,變更角色執行個體大小將會觸發輪流重新部署)。如果有提供向外延展方法來建立 Azure 應用程式,在選取執行個體大小時,較大不見得比較好。這適用於成本 (為什麼要支付您不使用的項目) 和效能 (取決於您的工作負載是否繫結 CPU、I/O 等等)。本文的<最佳作法>一節會詳細探討選取執行個體數目和執行個體大小的方法。

Azure 儲存體是 Azure 適用的基準耐久性資料服務,可提供 blob (檔案)、佇列和資料表儲存體 (索引鍵對值)。此儲存體帳戶是延展和可用性的基本單位,並提供下列功能。與儲存體服務之間的所有通訊都是根據經由 HTTP 的 REST 介面。

Tip提示
如需最新的 Azure 訂閱和服務限制,請參閱<Azure 訂閱和服務限制、配額及條件約束

Azure 儲存體可用性 SLA 保證至少 99.9% 的時間將會成功且正確處理格式正確的新增、更新、讀取和刪除資料的要求,此外,儲存體帳戶也會連接網際網路閘道。

這些限制會在個別儲存體帳戶的所有使用之間共用,也就是說,每秒的作業數和整體頻寬會在資料表、blob 和佇列之間共用。如果應用程式超出每秒的作業總數,此服務可能會傳回 HTTP 代碼 503,表示伺服器忙碌中。作業是每一個儲存體層面所特有 (資料表、佇列或 blob),底下的各小節會加以說明。

就之前使用的運送容器比喻而言,每一個儲存體帳戶都是提供某些容量的容器。超出單一帳戶 (運送容器) 的限制時,便需要利用相同應用程式中的多個帳戶。

Azure 儲存體預設會提供可用性和恢復功能;對 Azure 儲存體的所有寫入或更新都會在三個儲存體節點 (位於不同的升級網域和故障網域) 之間,以透明且一致的方式複寫。對 Azure 儲存體的存取會使用存取金鑰形式的單一因素驗證加以控制。每一個儲存體帳戶都有主要和次要金鑰,如此當 Azure 儲存體中的主要金鑰為 rotated.Data 時便允許持續的可用性,而且會自動以地理複寫方式將其複寫到「鏡像」資料中心 (除非使用入口網站明確停用這項功能)。地理複寫是不透明的,萬一在主要資料中心發生故障時,可利用 DNS 重新導向,將用戶端容錯移轉到次要位置。

請注意,雖然 Azure 儲存體會透過自動化複本提供資料恢復功能,這並不會防止您的應用程式程式碼 (或開發人員/使用者) 因為意外或不小心的刪除、更新等作業而損毀資料。在遇到應用程式或使用者錯誤時維護資料精確度需要更進階的技術,例如使用稽核記錄在次要儲存體位置複製資料。Blob 儲存體會提供快照集功能,此功能可以建立 blob 內容的唯讀時間點快照集,而且此快照集可以當做 blob 資料精確度解決方案的基礎。

Azure 儲存體會透過其儲存體分析功能提供遙測,以收集及公開有關個別儲存體呼叫資料表、佇列和 blob 的使用資料。必須針對包含收集原則 (收集全部、只收集資料表等等) 和保留原則 (保存資料的時間長短) 的每一個儲存體帳戶來啟用儲存體分析。

Blob 儲存體會在 Azure 中提供檔案管理服務,以提供高可用性、具成本效益的方法來儲存未結構化的大量資料。此服務會提供兩種類型的 blob

  • 區塊 blob。區塊 blob 專為有效率地管理大型資料 blob 而設計。每個區塊 blob 最多包含 50,000 個區塊,每個區塊的大小上限為 4 MB (整體最大區塊 blob 大小為 200 GB)。區塊 blob 支援平行上傳,以便有效率且同時透過網路移動大型檔案。可以插入、取代或刪除個別區塊,但是無法就地編輯。

  • 頁面 blob。頁面 blob 是專為有效率地提供隨機讀取/寫入作業 (例如存取 VHD) 而設計。每個頁面 blob 的大小上限為 1 TB (由 512 位元組的頁面組成)。可以新增或更新個別頁面或頁面群組,而且可以就地覆寫。

blob 儲存體的設計限制列於下表。請記得,所有的這些作業計數都是針對整體儲存體帳戶的限制。

 

Blob 類別目錄 限制

最大 blob 大小 (區塊)

200 GB (50k 個區塊)

最大區塊大小

4 MB

最大 blob 大小 (頁面)

1 TB

頁面大小

512 個位元組

最大頻寬 / blob

480 Mbps

當超出單一 blob 的大小或頻寬限制時,應用程式可寫入多個並行 (或連續) blob 檔案。如果您的應用程式超過單一儲存體帳戶的限制,請利用多個儲存體帳戶來提供額外的容量。

Azure 佇列會在發行者和訂戶之間提供中介 (代理) 訊息服務。佇列可支援多個並行發行者和訂戶,但是原本不會公開高階訊息基本資料,例如發佈/訂用或是以主題為根據的路由。它們通常用來散發工作項目 (例如訊息、文件、工作等等) 給一組背景工作角色執行個體 (或是在多個託管服務等項目之間)。

如果應用程式未擷取和刪除佇列訊息,則會在 7 天後自動加以刪除。它們會提供資訊發行者與取用者之間的取消結合;所以只要雙方有儲存體帳戶金鑰和佇列名稱,就可以進行通訊。

 

佇列類別目錄 限制

佇列中的訊息上限

N/A (取決於儲存體帳戶限制)

訊息的最大存留期間

1 週 (自動清除)

訊息大小上限

64 kB

最大輸送量

~ 500 個訊息 / 秒

佇列是為了傳遞控制訊息,而不是原始資料。如果您的訊息太大而無法放入佇列、請重構您的訊息來分隔資料和命令。將資料儲存在 blob 儲存體中,包含資料的參考 (URI) 及儲存在佇列訊息中的意圖 (也就是要如何處理 blob 儲存體中的資料)。

若要增加單一佇列內的輸送量,請在單一訊息中批次處理多個訊息,然後利用更新訊息命令來追蹤封裝訊息工作的進度。另一個技術是將多個訊息放在 blob 中,並且在佇列訊息內包含此 blob 的指標。

如果您的應用程式需要的輸送量比單一佇列提供的輸送量還要多,請利用多個並行佇列。在此上下文中,您的應用程式必須實作適當的資料分割和路由邏輯。

Azure 資料表儲存體會針對單欄式 (二維) 資料提供高耐用性、可擴充的一致性存放區。它會傳遞 { 資料分割索引鍵, 資料列索引鍵 } -> { data[] } 語意來儲存和存取資料,如下圖所示。每個資料表都以資料分割細分,而每個資料分割都包含實體。每個實體都可以有自己的 (平面) 結構描述或屬性 (資料行) 清單。

每個資料分割最多每秒可支援 500 個作業,而每個資料表最多可支援儲存體帳戶中的可用作業上限。由於每個實體不但會包含實際資料,也會包含單欄式中繼資料 (因為每個實體都可以有不同的結構描述),所以不建議使用長的資料行名稱,特別是大型的方法。

 

資料表類別目錄 限制

每個資料分割每秒的最大作業數目

500

最大實體大小 (資料行名稱 + 資料)

1 MB

最大資料行大小 (byte[] 或字串)

64 kB

最大資料列數目

N/A (取決於儲存體帳戶限制)

支援的資料類型

byte[]、Boolean、datetime、double、Guid、int32、int64、string

個別實體 (可以視為資料列) 的大小上限為 1 MB,其中的個別資料行則限制為 64 kB 的上限。支援的資料類型列在上表中;如果是不支援的類型 (例如 DateTimeOffset),您的應用程式程式碼中需要序列化 Proxy (例如,以標準字串格式儲存 DateTimeOffset)。

資料表儲存體會提供儲存之資料的存取權,其方式是使用與資料分割和實體、資料分割掃描或實體掃描相關的金鑰。它可支援篩選投射,因為可以在查詢中將篩選運算式發送到資料表儲存體,並在資料表儲存體中執行。資料表儲存體不提供次要索引,所以根據資料分割索引鍵或實體索引鍵的任何查閱都需要資料表和/或資料分割掃描。如果是包含重要實體數目的資料分割,這通常對於效能會有顯著的影響。

任何查詢處理的時間超過 5 秒時,都會傳回應用程式可以使用的持續 Token,繼續接收查詢結果。擷取超過 1,000 個實體的查詢必須利用分頁模型來帶回以 1,000 個實體為區塊單位的資料 (資料表儲存體應用程式開發介面原本就支援此功能)。

目前針對資料表儲存體支援的唯一查詢運算式為篩選和選取 (選取特定屬性);資料表儲存體不提供伺服器端的彙總或群組語意。若要建立需要豐富彙總或分析功能的應用程式,通常比較好的選擇是以彙總格式儲存資料或是使用關聯式引擎,例如 Azure SQL Database。某些應用程式會使用一種混合式方法,將資料表儲存體的資料彙總到輔助性 SQL Database,然後將其用於查詢和報告用途。

選擇適當的資料分割函數對於有效率及有效的資料表儲存體使用非常關鍵。資料分割函數的類型有兩個主要選擇:

  • 時間。通常用於儲存時間序列資料,例如 Azure 診斷效能計數器 (本文的遙測章節中會涵蓋這種用法),以時間為根據的資料分割函數會將目前時間轉換成代表時段的值 (目前的分鐘、小時等等)。

    這樣會以有效率的方式查閱和尋找特定資料分割 (因為資料表儲存體的篩選子句支援 >=、<= 等等),但是如果選擇的時段太窄則容易發生節流,而且會發生尖峰事件。例如,如果選擇的資料分割函數是目前的分鐘,而且發生尖峰事件,則可能有太多的用戶端嘗試同時寫入相同的資料分割。這樣不但會影響插入的輸送量,也會影響查詢的輸送量。

  • 資料。以資料為中心的資料分割函數會根據要儲存 (或擷取) 的一個或多個資料屬性來計算資料分割值。選擇適當的資料驅動資料分割函數取決於幾個因素 – 查詢模式、資料分割索引鍵的密度 (一個資料分割中最終有多少個實體) 及無法預期的成長 (重新平衡極大型的資料表可能極具挑戰性)。常見的模式包括:

    • 單一欄位。資料分割索引鍵是來源資料中的單一欄位 (例如訂單資訊的客戶識別碼)。

    • 多個欄位。資料分割或資料列索引鍵為來源資料中多個欄位的複合 (通常是串連)。當選取資料分割索引鍵時,請注意批次作業會要求所有實體都在相同的資料分割中 (即具有相同的資料分割索引鍵)。

    • 導出欄位。資料分割索引鍵是根據決定性函數從一個或多個欄位計算而來。常見範例為將使用者設定檔散發到多個資料分割中。使用者識別碼會使用雜湊函數進行雜湊處理 (此函數是為了能夠以相當一致的方式散發而設計),然後會針對所需的資料分割數目採用模數。

任何重要的應用程式都需要使用多個資料分割。即使是總實體很少的資料表 (例如兩百個),如果應用程式每秒將會提出幾千個要求,則必須有多個資料分割提供輸送量:

  • 單一資料表 / 單一資料分割。最簡單的選項 (常數資料分割索引鍵值),適用於資料數量和要求輸送量需求 (< 500 個實體/秒) 有限的小規模工作負載。

  • 單一資料表 / 多個資料分割。大多數部署的典型選項;請小心選擇能配合目標查詢模式的資料分割索引鍵。

  • 多個儲存體帳戶 / 多個資料分割。如果預計負載每秒會超出 5,000 個作業,則需要橫跨多個儲存體帳戶使用資料表散播。

一旦選取之後,重新平衡 (重新分割) 資料可能需要極高的成本,其中牽涉到讀取和複製包含新資料分割索引鍵的所有實體,然後刪除舊的資料。請注意,資料分割並沒有大小下限,資料分割可由單一實體 (即資料列) 組成。

如果應用程式需要的輸送量多於單一資料表提供的輸送量 (在仔細選擇資料分割之後),請使用不同儲存體帳戶中的多個並行資料表。在此上下文中,您的應用程式需要實作適當的路由邏輯,才能選取適當的儲存體帳戶。

Azure 內容傳遞網路 (CDN) 會提供有效率的方式在全域散發的快取網路中快取靜態內容 (來自 blob 或應用程式輸出)。這樣會減少應用程式傳遞靜態內容的壓力,並改善使用者的整體經驗。

內容傳遞網路可用性 SLA 會保證快取物件將以每月 99.9% 的可用性來傳遞。

使用 CDN 需要為您的訂用帳戶啟用此功能。可以快取 blob 內容 (來自公開可用 / 匿名存取容器) 和匿名應用程式輸出內容 (例如,http://www.myapp.com/cdn/somepage.aspx)。

一般而言,如果是任何大規模的應用程式,所有經常存取的靜態內容 (影像、css 等等) 都應該使用適當的快取到期原則來透過 CDN 傳遞。

例如,假設有一家線上電子書店有 1 百萬本書。將所有書籍的內容 (影像等) 包含在 CDN 中需要極高的成本 (因為大部分的內容並不會經常有人存取,而且會一直到期),所以只包含熱門的內容 (例如,前 50 大暢銷書) 將會提供相較於價格的適當快取組合。

成功傳遞大規模服務的其中一個核心要素就是遙測 – 洞察應用程式的作業、效能與使用者體驗。Azure 應用程式適用的遙測方法必須考量平台的向外延展 / 分散式本質,以及用來收集、分析和取用遙測的可用平台服務。

在 Azure 上收集和了解遙測的基準技術元件為 Azure 診斷 (WAD)。WAD 是由代理程式 (此代理程式會收集個別執行個體中的資料,並將資料轉送給中央收集點 (儲存體帳戶)) 以及用來儲存和存取資料的一組標準結構和慣例所組成。此代理程式會支援一些組態方法,包括程式碼 (.NET)、內嵌在已部署之專案程式碼中的組態檔,或是部署到 blob 儲存體的集中式組態檔。此組態在最後一個執行個體中有一部分是動態的,好讓更新的診斷檔案得以發送到 blob 儲存體,然後往下提取到目標代理程式。

WAD 組態會提供許多資料來源;每個資料來源都會定期收集、透過 Windows 事件追蹤 (ETW) 工作階段批次處理,並發佈到目標儲存體帳戶。代理程式會處理暫時性連接問題、重試等等。可用的資料來源如下:

  • 效能計數器。效能計數器值的子集 (CPU、記憶體等等),已擷取到本機 ETW 工作階段並定期暫存到資料表儲存體。

  • Windows 事件記錄檔。Windows 事件記錄的子集 (應用程式、系統等等),已擷取到本機 ETW 工作階段並定期暫存到資料表儲存體。

  • Azure 記錄。由應用程式程式碼所發佈 (透過 System.Diagnostics.Trace) 並由 DiagnosticMonitorTraceListener 追蹤接聽程式所擷取的應用程式記錄檔 (追蹤訊息)。這些會發佈到目的地儲存體帳戶中的 WAD 效能計數器資料表。

  • IIS 7.0 記錄。有關 IIS 記錄之要求的標準 IIS 記錄資訊 (僅限 Web 角色)。記錄會收集到本機檔案中,並且定期暫存到 blob 儲存體。

  • IIS 失敗要求記錄。有關失敗要求的 IIS 資訊,收集到本機檔案並且定期暫存到 blob 儲存體。

  • 損毀傾印。在系統損壞時,有關作業系統狀態的記錄都會擷取及發佈至 blob 儲存體。

  • 資料來源。WAD 可監視其他本機目錄 (例如本機儲存體中的記錄檔目錄),並且將資料定期複製到 blob 儲存體中的自訂容器。

每一個資料來源都會設定要收集的資料子集 (例如,效能計數器清單) 及收集/發佈間隔。也有一些 PowerShell 指令碼可用來變更執行階段組態,或是強制立即將資料從代理程式發佈到目標儲存體帳戶。

Important重要事項
將遙測記錄到個別儲存體帳戶。將遙測和應用程式資料記錄到相同的儲存體帳戶將會造成大規模嚴重的競爭問題。

Azure SQL Database 提供資料庫即服務,可讓應用程式快速佈建關聯式資料庫、將資料插入其中及查詢關聯式資料庫。它會提供許多熟悉的 SQL Server 功能,同時減少了硬體負擔、組態、修補和恢復功能。

note附註
SQL Database 不提供與 SQL Server 之間的 1:1 功能同位檢查,而且其目的是為了滿足特別適合雲端應用程式的一組不同的需求 (彈性延展、可減少維護成本的資料庫即服務等等)。如需詳細資訊,請參閱 http://blogs.msdn.com/b/windowsazure/archive/2012/06/26/data-series-sql-server-in-windows-azure-virtual-machine-vs-sql-database.aspx

此服務會在多個租用戶共用環境中執行,其中包含來自多個使用者的資料庫,以及在根據商用硬體的基礎結構上執行的訂用帳戶 (向外延展,而不是向上延展)。

資料庫會在邏輯伺服器內佈建;每部邏輯伺服器在預設情況下最多可包含 150 個資料庫 (包括 master 資料庫)。根據預設,每個訂用帳戶可佈建五部邏輯伺服器,而且能夠藉由連絡支援人員來增加這個配額以及每部邏輯伺服器的資料庫數目上限。

每部邏輯伺服器都會被指派一個系統產生的公開、唯一的 DNS 名稱 (形式為 [servername].database.windows.net),而且訂用帳戶中的每部邏輯伺服器都會共用相同的公開 IP 位址。邏輯伺服器 (和資料庫) 會透過標準 SQL 連接埠 (TCP/1433) 存取,其方式是在連接埠 TCP/833 上使用 REST 架構管理應用程式開發介面 存取。

依預設,邏輯伺服器 (及其所有資料庫) 的存取權會透過 Azure 管理入口網站的 IP 型防火牆規則加以限制 (可以針對邏輯伺服器或個別資料庫設定規則)。啟用 Azure 應用程式的存取權以及從 Azure 外面直接連接應用程式 (例如,連接 SQL Server Management Studio) 需要設定防火牆規則。這些規則可能會透過 Azure 管理入口網站使用管理服務應用程式開發介面呼叫加以設定。

SQL Database 提供 SQL Server 中大多數主要功能的支援,但是有幾個重要的例外狀況,包括:

  • 所有資料表都必須包含 CLUSTERED INDEX;要等到定義 CLUSTERED INDEX 之後,資料才能插入 SQL Database 的資料表中。

  • 沒有內嵌 Common Language Runtime (CLR) 支援、資料庫鏡像、Service Broker、資料壓縮或資料表分割。

  • 沒有 XML 索引;支援 XML 資料類型。

  • 不支援透明資料加密 (TDE) 或資料稽核

  • 沒有全文檢索搜尋支援

每個資料庫在建立時,都會設定大小上限。目前可用的大小上限為 1 GB、5 GB、10 GB、20 GB、30 GB、40 GB、50 GB、100 GB 和 150 GB (目前可用的大小上限)。當資料庫遇到大小上限時,它會拒絕其他 INSERT 或 UPDATE 命令 (依然可以查詢和刪除資料)。可能也會藉由發出 ALTER DATABASE 命令來建立資料庫的大小 (增加或減少)。

因為資料庫是根據每天使用的平均大小計費,所以預期快速成長或無法預測成長的應用程式一開始可能會將資料庫大小上限設定為 150 GB。將資料庫延展到 150 GB 以外需要利用向外延展方法,底下的章節會有更詳細的說明。

SQL Database 會針對節點層級失敗提供內建的恢復功能。所有寫入資料庫的內容都會使用仲裁認可技術自動複寫到兩個或多個背景節點 (主要複本和至少一個次要複本必須先確認此活動會寫入交易記錄,然後才能將交易視為成功並傳回)。萬一發生節點失敗,資料庫會自動容錯移轉到其中一個次要複本。這會造成用戶端應用程式暫時性連接中斷 – 這也是所有 SQL Database 用戶端必須實作某種形式的暫時性連接處理的其中一個主要原因 (請參閱下面有關實作暫時性連接處理的詳細資料)。

每月可用性 SLA 會有 99.9% 的執行時間,這定義為能夠在 5 分鐘間隔期間於 30 秒內連接到 SQL Database。之前段落所述的容錯移轉事件通常會在 30 秒內發生,加強您的應用程式處理暫時性連接失敗的需求。

SQL Database 可讓您透過動態管理檢視 (DMV) 深入了解其健康狀況和效能,這些 DMV 包含系統重要層面的相關資訊,例如查詢效能、資料庫和資料表大小等等。應用程式負責定期收集和分析來自重要 DMV 的資訊,並整合到更寬廣的遙測和前瞻架構中。

SQL Database 有幾個業務續航力 (備份、還原) 選項可以使用。透過資料庫複製功能或 DAC 匯入/匯出服務可複製資料庫。資料庫複製會提供交易一致的結果,但是 bacpac (透過匯入/匯出服務) 則不會。這兩個選項都會當做資料中心內的佇列型服務來執行,而且目前未提供完成時間 SLA。

請注意,資料庫複製和匯入/匯出服務對於來源資料庫會有極大的負載,而且可以觸發資源競爭或節流事件 (底下的<共用資源和節流>一節會加以描述)。雖然這兩個方法無法提供 SQL Server 所支援的相同累加備份程度,但是預覽版本中有新的功能可以啟用時間點還原功能。時間點還原功能允許使用者將資料庫還原到過去 2 週的任意時間點。

目前唯一支援的驗證技術是 SQL 驗證,這是以資料庫中註冊的使用者為根據的單一因素使用者名稱/密碼登入。Active Directory 或雙因素驗證功能目前還無法使用。強烈建議您使用 ADO.NET、ODBC 等項目中的內建加密支援,將 SQL Database 的連接加密。資料庫層級權限與 SQL Server 一致。如需有關設定 Azure SQL Database 安全性的詳細討論,請參閱管理 Azure SQL Database 中的資料庫和登入

SQL Database 會提供一組豐富的動態管理檢視來觀察查詢效能和資料庫健全狀況。不過,並未提供任何自動化基礎結構來收集和分析這些資料 (也沒有熟悉的工具,例如直接附加的分析工具和作業系統層級的效能計數器)。本文的<遙測>一節會說明收集和分析的方法。

如上所述,SQL Database 是在共用基礎結構上執行的多租用戶服務。來自不同租用戶的資料庫會共用基礎實體節點,這些節點會建立在商用硬體之上。系統的其他使用者可以取用相同基本基礎結構上的重要資源 (工作者執行緒、交易記錄、I/O 等等)。系統會控管資源的使用與形狀,將資料庫維持在設定資源界限之內。當超過這些限制時 (不論是租用戶還是實體節點層級),SQL Database 都會藉由節流使用量或卸除連接來回應。這些限制列在下表中。

 

資源 每個交易的最大值 / 工作階段 每個實體節點的最大值 軟節流限制 硬節流限制

工作者執行緒

512

305

410

資料庫大小

每個資料庫最多設定 150 GB 的大小上限

100%;達到限制之後無法接受插入或更新

交易記錄成長

每筆交易 2 GB

500 GB

交易記錄長度

20% 的總記錄空間 (100 GB)

500 GB

鎖定計數

每筆交易 1 百萬個

封鎖系統工作

20 秒

暫存資料庫空間

5 GB

5 GB

記憶體

20 秒期間的 16 MB

最大並行要求數

每個資料庫 400 個

當到達交易限制時,系統會取消交易來回應。當資料庫到達軟節流限制時,交易和連接都會減緩或中止。到達硬節流限制會影響基礎實體節點上的所有資料庫 (和使用者),造成現有的作業終止,並在資源低於此節流臨界值之前防止新的作業或連接。

這些節流限制的一部分可能會造成應用程式設計和效能的非直覺式限制。例如,將交易記錄限制為每筆交易最多 2 GB 可防止在大型資料表上建立索引 (在這裡建立索引將會產生超過 2 GB 的交易記錄)。執行這類作業的技術將會在本文的<最佳作法>一節討論。

處理這些類型的節流狀況和暫時性錯誤需要謹慎設計和實作用戶端程式碼,對付這些情況需要向外延展資料庫層,以同時利用多個資料庫 (下一節會討論向外延展)。

SQL 用戶端應用程式程式碼應該:

  • 實作可感知與節流相關之 SQL 錯誤碼的重試程式碼,並提供適當的撤退邏輯。如果應用程式中沒有提供某個形式的撤退邏輯,您可以持續針對資料庫發送尖峰負載,將資料庫鎖定在持續節流狀態。

  • 記錄節流錯誤,使用重試程式碼來區分暫時性連接、節流和嚴重錯誤 – 語法、遺漏 sproc 等等。這將會協助追蹤和排除應用程式可用性問題。

  • 實作斷路器模式。當適當選擇的重試原則過期時 (平衡延遲及應用程式將重試之頻率的系統回應),請叫用程式碼路徑來處理非暫時性錯誤 (亦即跳開斷路器)。然後應用程式程式碼可以:

    • 遞補到另一個服務或方法。如果應用程式未能將新的資料插入 SQL Database (而且資料不需要立即可用),可以改為將資料序列化成 DataTable (或其他 XML/JSON 格式) 並寫入到 blob 儲存體中的檔案。然後應用程式可以傳回成功代碼給使用者 (或應用程式開發介面呼叫),並將資料插入資料庫中之後的點。

    • 如果資料或工作流程為選擇性 (將不會影響使用者體驗),則傳回 null 值表示在無訊息模式中失敗

    • 如果沒有實用/適當的後援機制,藉由傳回錯誤碼表示快速失敗

SQL Database 可以輕鬆地傳遞大量相當小的延展單位 (資料庫)。在利用 SQL Database 的 Azure 上實作可高度擴充的應用程式需要向外延展方法,組合多個資料庫的資源來滿足多變的需求。在傳統上,應用程式會被鎖定為單一向上延展的高彈性資料庫伺服器的「鈦蛋殼」,所以您需要謹慎設計,將應用程式轉換成能夠有效率地利用向外延展資料庫服務。

在 SQL Database 中,就像與其他核心 Azure 服務一樣,向外延展和組合是其他延展 (資料庫大小、輸送量) 與資源 (工作者執行緒等) 的關鍵。有兩個核心方法可針對 SQL Database 實作資料分割/分區化 (因此為向外延展),這些方法目前在應用程式內不是互斥的:

  • 水平資料分割。在水平資料分割方法中,保持不變的資料表或資料集會單獨放在個別資料庫中。例如,如果是服務不同組客戶的多租用戶應用程式,應用程式可能會針對每個客戶建立一個資料庫。如果是較大的單一租用戶應用程式,客戶資料表可能會位於與訂單資料表不同的資料庫中。資料分割索引鍵通常是租用戶識別碼 (例如客戶識別碼)。在底下的圖表中,資料集會使用電子郵件的雜湊當做資料分割值水平向外分割成三個不同的資料庫 (也就是說,資料分割索引鍵為電子郵件,資料分割函數會使用此索引鍵的雜湊對應到目的地資料庫)。

  • 垂直資料分割。在垂直資料分割方法中,資料集會根據資料分割結構描述分佈到多個實體資料表或資料庫。例如,客戶資料和訂單資料可能會分佈到不同的實體資料庫。在下圖中,資料集會垂直分割成兩個不同的資料庫。核心使用者資訊 (名稱、電子郵件) 會儲存在 DB1 中,而且使用者設定檔資訊 (例如頭像圖片的 URI) 會儲存在 DB2。

許多應用程式將使用水平和垂直資料分割的組合 (混合資料分割) 以及併入額外的儲存體服務。例如,在上述範例中,使用者的頭像圖片已當做識別碼儲存在資料庫中,而應用程式會將它展開為完整 URL。然後這個 URL 會對應至 blob 中儲存的影像。

當使用向外延展的關聯式資料存放區時,可用性計算非常不同。具有大量分區的系統比較可能有一些個別資料區段處於離線狀態,整個應用程式無法使用的機率則比較低。應用程式必須考量後端資料存放區的部分可用性。在向外延展資料模型中,資料可用性不再是一個全有或全無的情況。

分割資料可能非常有挑戰性,特別是當使用量模型或資料分佈會隨著時間而變更時。以範圍為根據的資料分割索引鍵,不論是根據固定數目 (使用資料分割值的雜湊模數) 還是資料分割值的分佈,都需要重新平衡個別分區之間的資料。以資料分割配置為根據的範圍通常會利用二進位分割或合併來簡化重新平衡作業。

例如,固定範圍的資料分割方法 (例如姓氏第一個字母) 一開始可能會以平衡分佈的形式出現,不過在新的使用者出現時可快速切換成高度不平衡的狀況 (每個使用者都有自己的姓氏,而且這些姓氏不一定會在字母之間平均分佈)。請牢記,您可能必須隨著時間來調整資料分割機制,而且重新平衡資料也需要成本。

根據資料分割配置的查閱實作起來更具挑戰性,因為每個資料租用戶或資料分割都需要高效能的查閱機制,但是比較適合細微的重新平衡,因為這種查閱方式可讓單一租用戶個別重新平衡到新的資料分割。這樣也允許將額外容量 (新的資料庫等等) 新增到系統中,而不需要複製資料。

不論分區化方法的組合為何,移至分區化關聯式資料庫的向外延展都會附帶一些限制,必須採用另一個方法來管理和查詢資料:

  • 傳統「良好的」SQL 資料儲存體和查詢設計已利用高度正規化的資料模型,針對儲存體和一致性最佳化。這個方法假設整體的資料空間都是連續的,並充分利用資料表之間的交互參考和 JOIN。隨著資料分佈到實體分散的節點,只能在單一分區中使用 JOIN 和交互參考。SQL Database 不支援多個資料庫之間的分散式查詢;資料合併必須在用戶端層處理,並且跨分區進行資料的非正規化和複寫。

  • 參考資料和中繼資料通常會集中到參考資料表中。在向外延展方法中,這些參考資料表以及無法以一般資料分割索引鍵分隔的任何資料都必須跨分區複寫和保持一致性

  • 並沒有實際的方法可提供跨分區的可擴充式、高效能分散式交易;資料和 (結構描述更新) 絕對無法在分區之間維持交易一致性。應用程式程式碼必須承受及負責分區之間某種程度的鬆散一致性

  • 應用程式程式碼必須了解分區化機制 (水平或垂直的資料分割類型),才能連接到適當的分區。

  • 常用 ORM (例如 Entity Framework) 原本不了解向外延展資料模型;廣泛使用大型 ORM 的應用程式可能需要大幅重新設計,才能與水平分區化相容。在單一資料庫的垂直分區化方法中設計隔離租用戶 (客戶集合) 通常需要在資料存取層做的重新設計較少。純垂直分區模型的缺點為,每一個個別分區都受到單一資料庫容量的限制。

  • 需要接觸 (讀取或寫入) 多個分區的查詢必須以分散/聚集模式實作,其中個別查詢會針對目標分區執行,而且結果集會彙總在用戶端資料存取層。

使用 SQL Database 向外延展的執行方式是橫跨多個 SQL 手動分割或分區資料。這個向外延展方式會提供機會來隨著延展達成接近線性的成本成長。彈性成長或視需要的容量可能會根據需要隨著累加成本而增加。並非所有應用程式都可以支援這個向外延展模型而不需要大幅重新設計。

  • 結構描述更新不保證能夠維持交易一致性,特別是在更新大量分區時。應用程式必須接受規劃中的停機時間,或者負責多個並行版本的已部署結構描述。

  • 業務續航力程序 (備份/還原等等) 必須負責多個資料分區。

對付這些挑戰的設計建議和最佳作法會涵蓋在本文的<最佳作法>一節。

本文的其餘部分著重於說明使用 Azure and SQL Database 來提供高擴充性應用程式的最佳作法,這些作法是根據實際的經驗以及這些經驗提供的教育。每個最佳作法都會討論目標的最佳化和元件、實作方法及固有的權衡得失。就如同任何最佳作法一樣,這些建議大多取決於它們所適用的環境。請根據上一節討論的平台功能來評估適合的每一種最佳作法。

note附註
這些經驗取自未遵循傳統 OLTP (線上交易處理) 模式的一些客戶開發。請務必了解一點,部分最佳作法可能無法直接提供給需要強烈或嚴格資料一致性的應用程式使用;只有您自己知道應用程式和其環境的確切業務需求。

每個最佳作法將與一個或多個最佳化層面相關:

  • 輸送量。如何透過系統增加作業數目 (交易、服務呼叫等) 並減少競爭。

  • 延遲。如何針對彙總和個別作業減少延遲。

  • 密度。在直接內容 (例如,SQL Database 的應用程式程式碼) 和彙總內容 (充分利用多個儲存體帳戶來增加延展) 中組合服務時,如何減少競爭點。

  • 管理能力。診斷、遙測和洞察 – 如何了解您的大規模部署服務的健全狀況和效能。

  • 可用性。如何透過減少失敗點和模式的影響來增加整體應用程式可用性 (負載之下的可用性會在輸送量/延遲/密度底下涵蓋)。

身為 Azure 中的基準延展單位,謹慎設計和部署託管服務對於提供可高度擴充、可用的服務非常關鍵。

  • 託管服務內的執行個體和升級網域數目對於部署、設定及升級託管服務所需的時間有很大的影響。請平衡效能和延展性優點以及達成這些優點所需增加的複雜性。提高延展性和彈性通常會一併增加解決方案的開發和管理成本。

  • 請避免單一執行個體角色;此組態不符合 Azure SLA 的需求。在節點失敗或升級事件期間,單一執行個體角色會離線工作。請將其使用限制為低優先權的「維護」工作。

  • 每個資料中心都有有限 (但是大量) 的容量,而且在極少數情況下可以當做單一失敗點。需要最高層級延展和可用性的服務必須實作具有多個託管服務的多個資料中心拓撲。但是:

  • 不需要最高層級的可用性時 (請參閱先前的項目),請確定應用程式和相依服務完全包含在單一資料中心內。如果是解決方案必須使用多個資料中心的情況,請使用下列指導方針:

    • 避免針對即時作業進行跨資料中心的網路呼叫作業 (刻意跨網站同步處理之外)。資料中心之間的長途延遲可能會有很大的變異性,而且會產生非預期或不想要的應用程式效能特性。

    • 只有在另一個資料中心存取服務所需的最低功能。一般而言,這些活動與業務續航力和資料複寫相關。

對於大規模的分散式應用程式而言,存取有狀態的應用程式資料非常關鍵。整體應用程式輸送量和延遲通常受到所需資料和內容可以擷取、共用及更新的速度所限制。分散式快取服務 (例如 Azure Caching 和 Memcached) 已進化,以回應這個需求。應用程式應該利用分散式快取平台。請考慮下列指導方針:

  • 利用分散式快取平台當做託管服務內的背景工作角色。與快取用戶端之間的這個相似性會減少延遲以及負載平衡器周遊所呈現的輸送量障礙。Azure 快取的角色中快取會裝載雲端服務中背景工作角色的快取。

  • 使用分散式快取平台當做存取常用應用程式資料和物件 (例如使用者設定檔和工作階段狀態) 的主要儲存機制,並以 SQL Database 或是讀過或另行快取方法中的其他耐久性存放區為後盾。

  • 快取物件具有存留時間,此時間會影響它們在分散式快取中的有效期間。應用程式會明確在快取物件上設定存留期間,或是為快取容器設定預設的存留期間。請平衡可用性之間存留期間的選擇 (快取點擊) 與記憶體壓力和陳舊資料。

  • 快取目前的 key->byte[] 語意;請注意重疊寫入可能會造成快取中的資料不一致。分散式快取通常不會針對不可部分完成的儲存資料更新提供應用程式開發介面,因為這些快取無法察覺儲存之資料的結構。

    • 如果是需要並行寫入有嚴格一致性的應用程式,請使用分散式快取平台提供鎖定機制來更新實體。在 Azure Caching 中,可以透過 GetAndLock/ PutAndUnlock 加以實作。注意:這樣對輸送量有負面影響。

  • 快取效能會依據序列化及還原序列化物件所需的時間限制在應用程式層上。若要將這個程序最佳化,請利用相當對稱 (加密/解密資料所需的相同時間)、高效率的二進位序列化程式,例如 protobuf

    • 若要順利使用自訂序列化,請設計資料傳輸物件 (DTO) 來序列化成快取、使用適當的序列化註解、避免週期性相依性,並利用單元測試來追蹤有效率的序列化。

根據預設,服務層之間的連接 (包括透過負載平衡器的傳入連接) 受限於循環配置資源的配置方式,而且連接固定也受限。下圖說明不同層和外部服務之間產生的典型連接網狀 (左邊說明僅限典型 Web 層應用程式)。當這個網狀未針對輕量型連接通訊協定 (例如 HTTP) 呈現任何顯著效能問題時,就表示某些連接的連接/初始化成本很高,或是屬於受控管 (受限) 的資源。例如,SQL Database 連接就屬於這個類別目錄。若要最佳化這些外部服務和元件的使用,強烈建議您針對特定執行個體將資源呼叫同質化。

在上圖中,右側的拓撲在相同託管服務內有個別的 Web 層和背景工作層 (角色)。此拓撲也會實作 Web 層與應用程式層之間的同質性,將特定應用程式執行個體的呼叫固定到特定資料庫。例如,若要要求資料庫一 (DB1) 中的資料,Web 執行個體必須透過應用程式執行個體一或二來要求資料。因為 Azure 負載平衡器目前只會實作循環配置資源技術,所以在應用程式中提供同質性需要謹慎設計和實作。

  • 請使用個別的 Web 層和應用程式層設計應用程式,在 Web 層和應用程式層之間提供資料分割或可感知資源的同質性。

  • 請實作路由邏輯,以透明方式將內部服務呼叫路由傳送到目標應用程式執行個體。請使用外部或下游資源 (例如 SQL Database) 使用的資料分割機制的知識。

這個多層架構的實際實作需要使用輕量型通訊協定的 Web 層與應用程式層之間具有高效率的服務通訊。

Azure 應用程式的開發技術在根本上與 Windows Server 的開發技術並無不同。不過,彈性的網狀架構會強調利用有效率的程式碼的需求和優點,最有效力的程式碼會使用運算資源。

  • 假設所有服務、網路呼叫和相依資源可能不可靠且容易處於暫時性和持續的失敗模式 (例如,本主題底下有涵蓋如何針對 SQL Database 實作重試邏輯):

    • 針對所有服務呼叫 (SQL Database、儲存體等等) 實作適當的重試原則,以處理暫時性失敗狀況和連接遺失。

    • 請在重試邏輯中實作撤退原則,以避免發生「護航」作用 (在延長中斷的服務上重試堆疊)。

    • 請實作豐富的用戶端遙測來記錄包含內容資訊的錯誤訊息和失敗事件 (目的地服務、使用者/帳戶內容、活動等等)。

  • 請勿直接建立執行緒來排程工作,而是要利用排程和並行架構,例如 .NET 工作平行程式庫。執行緒是相當重量型的物件,而且對於建立和處置非常重要。針對共用執行緒集區工作的排程器可以更有效率地排程及執行工作。此架構也會提供更高層級的語意來描述連續和錯誤處理。

  • 針對序列化網路傳輸最佳化資料傳輸物件 (DTO)。在給定 Azure 應用程式的高度散發本質時,延展性受限於系統的個別元件可以透過網路通訊的效率程度。透過網路為了通訊或儲存而傳遞的所有資料都應該實作 JSON 文字序列化或更有效率的二進位格式,且包含適當的提示,將透過網路傳輸的中繼資料數量最小化 (例如線路上的較短欄位名稱)。

    • 如果互通很重要,請針對互通性和頻內中繼資料使用有效率的文字格式 (例如 JSON)。

    • 如果較高的輸送量很重要 (例如在您控制兩端的服務對服務通訊中),假設有一個非常有效率的封裝二進位格式,例如 bson 或 protobuf。

      • 請避免使用小型物件的多對話 (頻繁) 資料傳輸。服務之間的多對話通訊在負擔工作上會浪費大量的系統資源,並且很容易受到變動延遲回應的影響。

      • 序列化及還原序列化物件的測試應該是自動化測試架構的核心元件。功能測試會確保資料類別可序列化,而且沒有週期相依性。效能測試會確認所需的延遲時間和編碼大小。

  • 請在實用的地方充分利用輕量型架構,在元件和服務之間通訊。.NET 堆疊中的許多傳統技術會提供豐富的功能集,這些功能可能與 Azure 的分散式本質不一致。在意圖與執行之間提供高度抽象的元件通常附帶高效能的成本。

    • 在您不需要通訊協定互通或進階通訊協定支援的地方,請使用 ASP.NET Web 應用程式開發介面 (而不是 WCF) 實作 Web 服務來進行調查。

    • 在您不需要 Entity Framework 豐富功能的地方,請使用 micro-ORM (例如 Dapper) 實作 SQL 用戶端層來進行調查。

  • 請在 IIS 中針對傳出資料啟用 HTTP 壓縮來減少從資料中心送出的資料數量。

  • 將不同層之間的連接同質化,以減少連接的多對話性和內容切換。

  • 若要降低應用程式的負載,請使用 blob 儲存體來服務較大的靜態內容 (> 100 kB)。

  • 若要減少應用程式的負載,請使用透過 blob 儲存體的內容傳遞網路 (CDN) 來服務靜態內容,例如影像或 CSS。

  • 請避免針對工作階段資料使用 SQL Database。請改用分散式快取或 Cookie。

Azure 儲存體是 Azure 應用程式中的耐久資料骨幹。在提供非常可靠且立即可用的擴充經驗時,大規模的應用程式需要適當的設計和使用指導方針。

  • 請利用多個儲存體帳戶來取得較大的延展性,不論是藉由增加大小 (> 100 TB) 還是獲得更多輸送量 (> 每秒 5,000 個作業)。請確定應用程式程式碼可設定為使用多個儲存體帳戶,並且有適當的資料分割函數可將工作路由傳送到儲存體帳戶。請設計新增額外的儲存體帳戶當做組態變更 (而非程式碼變更) 的功能。

  • 請針對資料表儲存體謹慎選取資料分割函數,以啟用所需的延展 (就插入和查詢效能而言)。請針對遙測資料尋找以時間為基礎的資料分割方法,其中非暫時資料的複合索引鍵會根據資料列資料。請將資料分割保留在適當的範圍中,以獲得最佳效能;非常小的資料分割會限制執行批次作業 (包括查詢) 的能力,而非常大的資料分割則需要很高的查詢成本 (而且大量的並行插入可能會造成瓶頸)。

    • 資料分割函數的選擇對於查詢效能也有很大的影響;資料表儲存體會提供依照 {資料分割索引鍵, 資料列索引鍵} 的有效率查閱,而且 {資料分割索引鍵, 資料列符合篩選} 和 {資料分割索引鍵符合篩選, 資料列索引鍵符合篩選} 處理效率較低。需要全域資料表掃描的查詢 ({資料列索引鍵符合篩選})。

    • 資料分割可以很小,例如單一實體;這樣會針對單純的查閱工作負載提供高度最佳化效能,例如購物車管理。

  • 可能的話,請批次處理儲存體中的作業。資料表寫入應該要批次處理,通常是透過 .NET 用戶端應用程式開發介面中 SaveChanges 方法的使用。將一系列的資料列插入資料表中,然後在單一批次中使用 SaveChanges 方法認可變更。blob 儲存體的更新也應該在批次中使用 PutBlockList 方法加以認可。就像是資料表儲存體應用程式開發介面一樣,請針對區塊範圍呼叫 PutBlockList,而非個別的區塊。

  • 選擇短的資料行名稱用於資料表屬性,因為中繼資料 (屬性名稱) 會在頻內儲存。資料行名稱也會計算到 1 MB 的最大資料列大小。過長的屬性名稱很浪費系統資源。

就如同<探索 Azure>一節中所述,SQL Database 會提供周全的關聯式資料庫做為服務功能,以向外延展的方式啟用可擴充的資料儲存體存取。在大規模的應用程式中成功使用 SQL Database 需要幾個謹慎的設計和實作選擇;本章節將討論主要的設計重點和最佳作法。

許多應用程式都需要中繼資料資料表來儲存詳細資料,例如路由、資料分割和租用戶資訊。將此中繼資料儲存在單一資料庫中會產生單一失敗點以及延展性瓶頸。中央中繼資料存放區應該透過以下的組合向外延展:

  • 主動快取。組態資料庫中的資訊應該主動快取到分散式快取 (例如 Memcached 或 Azure Caching)。

    • 請注意在應用程式啟動時,積極嘗試從多個工作者執行緒預先載入快取的影響,這樣通常會導致過多的負載和資料庫節流。如果您的應用程式需要預先載入的快取,請將載入資料的責任委派給具有可設定載入率的專用背景工作角色 (或排程的工作)。

    • 如果應用程式效能或可靠性取決於擁有快取中可用的某個資料區段,您的應用程式應該拒絕內送要求,直到快取預先擴展為止。在擴展資料之前,應用程式應該傳回適當的錯誤訊息或錯誤碼。

  • 向外延展。以垂直方式 (依據資料表) 或水平方式 (橫跨多個分區來分割資料表) 分割資料,將負載分佈在多個資料庫。

分割的 SQL Database 的整體延展性受限於個別資料庫 (分區) 的規模以及這些分區可以組合在一起來增加規模的效率和有效性程度:

  • 由於交易記錄會限制較大的交易 (例如重建索引),所以個別資料表不可超過約 10 GB (請注意,這個實用限制取決於目標資料表索引的大小,因此它可能會針對您的資料庫大於或小於 10 GB)。如果是大型的個別資料表,請將資料表細分為較小的個別資料表,並且使用資料分割檢視提供一致的覆疊。

    • 持續保持小型的個別資料表大小會減少結構描述變更或是分段升級期間索引重建的影響。變更多個較小的資料表會讓封鎖作業造成的停機時間和延遲減至最低。

    • 此資料分割會讓管理技術變得複雜。類似重建索引的作業必須以反覆的方式針對所有元件資料表執行。

  • 請將個別資料庫 (分區) 保持在合理的小型狀態。持續性作業 (例如資料庫複製或是針對大於 50 GB 的資料庫匯出) 可能需要好幾個小時才能完成 (此服務會取消執行超過 24 小時的作業)。

在持續服務傳遞的環境中,管理分散式資料庫更新或結構描述修改需要應有的注意和照顧,才能有順利的升級路徑。在實際執行資料存放區中控制結構描述和中繼資料作業的所有傳統最佳作法要比以往更為重要。例如,在 100 個資料庫的其中 1 個內偵錯和解析意外卸除的預存程序是一項更為複雜的工作。

由於結構描述更新和資料修改在不同分區之間不會有交易一致性,所以應用程式更新在轉換期間必須與舊的和新的結構描述相容。這項需求通常表示每一個應用程式版本至少必須與目前版本和舊版的結構描述相容。

轉換為向外延展的資料庫連接會產生連接管理作業的挑戰。每個 SQL Database 連接都是相當耗成本的資源,在用戶端應用程式開發介面中 (ADO.NET、ODBC、PHP 等等) 大規模使用連接共用就是一項證明。每個應用程式執行個體可能都必須維護與多部資料庫伺服器之間的連接,而不是維護與中央 SQL Server 之間的多個連接。

由於連接會當做高成本而且可能很稀少的資源,所以應用程式必須及時傳回共用連接來適當地管理連接。應用程式程式碼應該使用自動連接處置;在 .NET 中,最佳作法是將 SqlConnection 的所有使用包裝在 using 陳述式內,例如:

using (var conn = new SqlConnection(connStr))
{
    // SQL client calls here
}

如前所述,針對 SQL Database 的連接受限於暫時性連接失敗。必須在所有連接和命令上使用重試邏輯,以防止這些暫時性失敗 (請參閱底下的其他詳細資料)。

SQL Database 只支援 TCP 連接 (不是具名管道),而且強烈建議您將應用程式程式碼與 SQL Database 之間的連接加密。若要避免不想要的連接嘗試 (例如嘗試使用具名管道),應用程式應該將其 SQL 連接字串格式化,如下所示:

Server=tcp:{servername}.database.windows.net,1433;Database={database};User ID={userid}@{database};Password={password};Trusted_Connection=False;Encrypt=True;Connection Timeout=30;

如果是大規模的應用程式部署,則託管服務部署與 SQL Database 叢集中 SQL Database 邏輯伺服器之間可能連接的預設數目可能會以指數方式成長 (每部伺服器都有單一外部 IP 位址)。例如,某個託管服務有 100 個執行個體、50 個資料庫,而且預設連接數目在 ADO.NET 中為 100 個連接。

MaxConnections=DatabaseCount*Instance Count*MaxConnectionPoolSize

請參考網路拓撲中的託管服務;連接的每一端 (託管服務和 SQL Database 邏輯伺服器) 都存在於 Azure 負載平衡器的背後。. 每個 Azure 負載平衡器在任何兩個 IPv4 位址之間都有 64k 的連接上限。此網路拓撲與可用連接的預設數目組合會讓較大的應用程式產生嚴重的網路失敗

  • 橫跨多個託管服務部署較大的應用程式。

  • 在多個訂用帳戶中部署資料庫 (而不只是相同訂用帳戶中有多部邏輯伺服器),取得更多唯一的 IP 位址。

  • 實作多層應用程式,將傳出作業同質化為目標應用程式執行個體 (請參閱之前有關託管服務的章節)。

  • 請記得每一個唯一的連接字串都會維護連接集區,而且連接集區會對應到每一個唯一的資料庫伺服器、資料庫和登入組合。使用 SQL 用戶端連接共用,並明確地限制 SQL 連接集區的大小上限。SQL 用戶端程式庫會視需要重複使用連接;小型連接集區的影響是在應用程式等候連接可用時,可能會增加延遲。

下列清單會提供減少必要作用中連接數目的建議:

轉換到分散式資料模型可能需要變更資料庫結構描述的設計以及變更某些類型的查詢。需要橫跨多個資料庫使用分散式交易的應用程式可能會有不適當的資料模型或實作 (例如,嘗試強制全域一致性)。這些設計必須重整。

由於可用性和延展性限制的緣故,應用程式的任何重要層面都應該避免使用中央序列產生機制。許多應用程式都會利用序列來提供全域唯一識別碼 (使用中央追蹤機制,視需要將序列遞增)。此架構會產生系統的每個元件都必須互動的全域競爭點和瓶頸。此瓶頸對於可能中斷連接的行動應用程式特別有問題。

應用程式應該改為利用可以在分散式系統中產生全域唯一識別碼 (例如 GUID) 的函數。根據設計,GUID 不是連續的,因此在大型資料表中當做 CLUSTERED INDEX 使用時可能會造成片段。為了減少 GUID 在大型資料模型中的片段影響,請將資料庫分區化,將個別分區保持在相對較小的規模。如此可讓 SQL Database 在複本容錯移轉期間將您的資料庫自動重組。

用戶端應用程式程式碼必須負責傳遞分散式資料模型的幾個層面:

  • 資料分割索引鍵。資料分割索引鍵應該屬於每個資料類別或模型的一部分,而且可能使用屬性加以裝飾,以允許資料分割索引鍵探索。

  • 遙測。資料存取層應該自動記錄有關每個 SQL 呼叫的資訊,包括目的地、資料分割、內容、延遲和任何錯誤碼或重試

  • 分散式查詢。執行跨分區查詢會帶來幾個新的挑戰,包括路由、資料分割選擇及部分成功的概念 (有一些個別分區會順利傳回資料,也有一些不會)。資料存取層應該提供委派,以便透過非同步 (平行) 分散/聚集方式執行分散式查詢,傳回複合結果。分散式查詢也必須負責限制基礎資源:

    • 平行處理原則的最大程度 (為了避免過多執行緒和連接壓力)。

    • 最大查詢時間 (為了從長時間執行的查詢或緩慢的分區減少整體延遲命中率)。

也有幾個持續中的管理工作必須執行:

  • 參考資料表。如果沒有全域一致的查詢空間,則必須將查詢中 JOIN 的參考資料複製到每一個個別分區。必須在個別分區中將資料維護和複寫到參考資料表,才能提供合理的一致本機參考資料。

  • 重新平衡資料分割。個別資料分割可能會變得不平衡,不是耗用太多資源並成為檢查點,就是呈現不足的使用量並且浪費資源。在這些情況下,必須重新平衡資料分割來重新配置資源。重新平衡機制在很大的程度上取決於資料分割策略和實作。在大多數情況下,重新平衡通常會牽涉到:

    • 將分區中的現有資料複製到一個或多個新的分區,不論是透過分割/合併機制 (以範圍為基礎的資料分割),還是實體層級的複製和重新對應 (以查閱為基礎的資料分割)。

    • 更新分區對應來指向新的分區,然後補償轉換期間寫入舊分區的任何資料。

  • 資料清除。因為應用程式會成長並收集資料,所以請考慮定期清除未使用的舊資料,以增加主要系統中的可用空餘空間和容量。已清除 (刪除) 的資料不會從 SQL Database 同步清除,而是由背景處理序標示為要刪除並加以清除。將資料標示為要刪除的常見方法是旗標資料行,此資料行可以將資料列標示為使用中、非使用中或是標示為要刪除。如此可針對一段期間的查詢資料加上遮罩,好讓資料輕鬆移回到實際執行環境 (如果使用者表示依然需要該資料)。

    刪除資料也會觸發片段,而且可能需要重建索引,以便進行有效率的查詢作業。舊的資料可以封存到:

    • 線上商店 (次要 SQL Database);這樣會增加主要系統中的空餘空間,但是不會減少成本。

    • 離線存放區,例如 blob 儲存體中的 bcp 或 bacpac 檔案;這樣會增加主要系統中的空餘空間,而且會減少成本。

    • 位元值區。您可以選擇從主要系統永久刪除資料,以增加空餘空間。

SQL Database 中有幾個常見情況會觸發暫時性連接失敗,例如複本容錯移轉。應用程式必須實作適當的程式碼來處理暫時性失敗,並適當地回應資源耗盡和節流:

  • 使用重試的暫時性連接失敗處理。資料存取程式碼應該利用原則驅動的重試機制來補償暫時性連接失敗。重試機制應該偵測暫時性連接失敗、重新連接目標 SQL Database 並重新發出命令。

  • 使用重試和撤退邏輯處理節流。資料存取程式碼應該利用原則導向的重試和撤退機制來處理節流情況。重試機制應該偵測節流,並逐漸撤出重新發出命令的嘗試 (以避免產生可能會延期節流情況的「護航」作用)。

    • 資料存取程式碼也應該實作撤退到替代資料存放區 (例如 blob 儲存體) 的能力。這個替代存放區會提供一個持久的機制來擷取活動、資料和狀態,以免在延長的節流或可用性事件中發生資料遺失的情況。

.NET 應用程式可以使用可感知 SQL Database 的重試和撤退邏輯架構,例如雲端應用程式架構 (CloudFx)Enterprise Library 暫時性錯誤處理常式。這些架構會針對常用資料存取類別提供包裝函式 (例如 SqlConnection 和 SqlCommand) 以及可以直接叫用的原則。

var retryPolicy = RetryPolicy.Create<SqlAzureTransientErrorDetectionStrategy>(
    retryCount: 3, 
    initialInterval: TimeSpan.FromSeconds(5),
    increment: TimeSpan.FromSeconds(2));
                
using (var conn = new ReliableSqlConnection(connStr))
{
    conn.Open();
    using (var cmd = conn.CreateCommand())
    {
    }
    conn.Close();
}

之前的程式碼片段示範在針對 SQL Database 工作時,如何使用 CloudFx ReliableSqlConnection 類別來處理暫時性連接錯誤。

特別注意和照顧可能有複雜失敗模式之服務 (例如 SQL Database) 的應用程式開發介面呼叫記錄。嘗試擷取重要內容片段和效能資訊。例如,所有 SQL Database 工作階段都附有工作階段識別碼,在協助直接隔離基本問題的支援電話中可使用此識別碼。強烈建議您將 SQL Database 中的所有呼叫、命令和查詢都記錄:

  • 伺服器資料庫名稱。因為可能有數百個資料庫,所以目的地伺服器對於追蹤和隔離問題非常關鍵。

  • 適當情況下的 SQL 預存程序或命令文字。請小心不要洩漏機密資訊到記錄檔中 – 通常要避免記錄命令文字。

  • 呼叫的端對端延遲。使用 Stopwatch 或另一個輕量型計時器,將呼叫包裝在計時委派中。

  • 呼叫的結果碼 (成功或失敗) 以及重試次數和失敗原因 (連接已卸除、節流等等)。

  • 連接的工作階段識別碼,可透過 CONTEXT_INFO() 屬性來存取 (如果使用 ReliableSqlConnection 則為 SessionTracingId 屬性)。不過,請勿針對每個用戶端呼叫從 CONTEXT_INFO() 擷取工作階段識別碼屬性,因為這個命令會觸發與伺服器之間的另一趟往返。

若要讓 SQL Database 的使用更有效率,針對 SQL Database 的查詢和資料插入應該要批次處理,並且盡量以非同步方式執行。這樣不但會提高應用程式效率,也會減少對 SQL Database 的整體系統負載 (允許更多的輸送量)。

  • 批次處理插入。如果是連續的資料插入作業,例如註冊新的使用者,資料應該要批次處理,並配合目標分區。這些批次應該根據觸發程序 (例如目標批次大小或時間間隔) 定期 (非同步) 寫入 SQL Database。如果是少於 100 個資料列的批次大小,資料表值函式通常會比大量複製作業更有效率。

  • 避免多對話介面。減少讓資料庫執行查詢或一組作業所需的往返次數。多對話介面具有高度負擔,這樣會增加系統的負載,並且減少輸送量和效率。請嘗試合併相關作業,通常使用預存程序可減少往返次數。

在業務續航力的整體方法中,儲存在 SQL Database 中的資料應該定期匯出到 blob 儲存體。Blob 儲存體預設可支援可用性和地理複寫。

實作排程工作,定期將資料庫匯出到 blob 儲存體。使用專用儲存體帳戶。此工作應該在與目標資料庫相同的資料中心執行,而不是從內部部署桌面或伺服器執行。

在低活動的時間排程匯出工作,以減少對使用者經驗的影響。當匯出多個資料庫時,請限制平行匯出的程度,以減少對系統的影響。

洞察 SQL Database 的健全狀況、效能和空餘空間是整體服務傳遞的重要元件。SQL Database 會透過動態管理檢視提供所需的原始資訊,但是目前並沒有周全的基礎結構可擷取、分析和報告關鍵度量。若要為 SQL Database 提供這項功能,請考慮下列作法:

  • 實作週期性工作,將與系統負載、使用的資源 (工作者執行緒、儲存空間) 和資料有關的關鍵效能資料收集到常用儲存機制。例如,假設有 Azure 診斷使用的資料表。此工作必須從屬於您的應用程式的所有資料庫收集資料。這項收集通常會以向外延展的方式進行 (同時從多個資料庫收集資料)。

  • 實作週期性工作來彙總此資訊,以建立部署之資料庫健全狀況和容量的關鍵效能指標。

Azure 診斷會提供收集應用程式和執行個體層級遙測的基準。但是在提供於 Azure 上執行之大規模應用程式的洞察能力時,需要謹慎設定和管理資料流程。不像可利用豐富 Windows 診斷公用程式的集中式向上延展應用程式,向外延展之分散式系統中的診斷必須先實作,系統才會上線 – 不能在事後實作診斷

錯誤處理、內容追蹤和遙測擷取對於了解錯誤事件、根本原因和解決方法非常關鍵。

  • 請勿將即時網站資料和遙測發佈到相同的儲存體帳戶。請使用專用儲存體帳戶進行診斷。

  • 針對大量 (高容量、高延遲、細微資料) 和多對話 (低容量、低延遲、高價值資料) 遙測建立不同的通道

    • 使用標準 Azure 診斷來源 (例如效能計數器和追蹤) 取得多對話資訊。

    • 使用一般記錄程式庫 (例如 Enterprise Application Framework Library、log4net 或 NLog) 實作大量記錄到本機檔案。在診斷監視器組態中使用自訂資料來源,定期將此資訊複製到 blob 儲存體。

  • 記錄包含內容、目的地、方法、時間資訊 (延遲) 和結果 (成功/失敗/重試) 之外部服務的所有應用程式開發介面呼叫。使用大量記錄通道,可避免讓診斷系統被遙測資訊所淹沒。

  • 寫入資料表儲存體的資料 (效能計數器、事件記錄檔、追蹤事件) 會寫入暫時資料分割中 (大約維持 60 秒)。嘗試寫入過多資料 (太多點來源、太低的收集間隔) 可能會淹沒這個資料分割。請確定錯誤尖峰不會觸發資料表儲存體中的高量插入嘗試,因為這可能會觸發節流事件。

    • 請從這些來源中選擇高價值資料來收集,包括關鍵效能計數器、重大/錯誤事件或追蹤記錄。

    • 請選擇適當的收集間隔 (5 分鐘 – 15 分鐘),以減少必須傳送和分析的資料量。

  • 請確定可在執行階段修改記錄組態,而不會強制重設執行個體。也請確認組態的細微程度很足夠,可記錄系統的特定層面,例如資料庫、快取或其他服務。

Azure 診斷不會提供相依服務的資料收集,例如 SQL Database 或分散式快取。若要提供應用程式及其效能特性的完整檢視,請新增基礎結構來收集相依服務的資料:

  • 從相依服務收集關鍵效能和使用量資料,並當做效能計數器記錄發佈到 WAD 儲存機制。

    • 透過 Azure 儲存體分析的 Azure 儲存體。

    • SQL Database 與動態管理檢視。

    • 透過效能計數器或健全狀況監視應用程式開發介面的分散式快取。

  • 定期分析原始遙測資料,以建立彙總和積存 (當做排程工作)。

顯示:
© 2015 Microsoft