匯出 (0) 列印
全部展開
本主題尚未接受評分 - 為這個主題評分

在 Windows Azure 上設計多組織用戶共享應用程式

更新日期: 2014年1月

作者:Suren Machiraju 和 Ralph Squillace

校稿者:Christian Martinez、James Podgorski、Valery Mizonov 和 Michael Thomassy

本文描述針對更有效率的 Windows Azure 設計多組織用戶共享應用程式 (通常是為其他組織提供服務的 ISV 應用程式) 所需的方法,這樣一來,執行或建置的成本會降低,而且 (或) 具有更高的性能、強固性或可調整性。本文會先描述多組織用戶共享應用程式的一般原則、與建置及執行多組織用戶共享應用程式相關的 Windows Azure 平台結構和行為,然後將焦點放在多組織用戶共享的特定領域,尤其是適用於 Windows Azure 的領域:應用程式與資料來源及這些資源的佈建和管理。本文在每一個焦點領域中,都會描述您為了在 Windows Azure 上建立成功的多組織用戶共享應用程式所必須平衡的安全性、成本和延展性問題。

什麼是多組織用戶共享應用程式?

Wikipedia 以下列方式定義多組織用戶共享。

Important重要事項
如果您已經知道本文所談論的主題,請前往 Windows Azure 多組織用戶共享服務概觀開始閱讀,直接取得相關指引。之後如果您有一些事情不太清楚,可以回到本章節。

多組織用戶共享指的是軟體架構的原則,在此原則下會有單一軟體伺服器在伺服器上執行,並服務多個用戶端組織 (租用戶)。多組織用戶共享與多重執行個體架構成了對比,後者會針對不同的用戶端組織設定不同的軟體執行個體 (或硬體系統)。在多組織用戶共享架構中,軟體應用程式的設計目的是為了以虛擬方式分割其資料和組態,而且每一個用戶端組織都會使用自訂的虛擬應用程式執行個體。(Wikipedia.org)

簡單來說,這究竟代表什麼意義?一個很好的範例可能就是餐廳訂位應用程式。餐廳本身並沒有 IT 基礎結構可建置全面性網際網路訂位網站,這個網站會即時連接櫃臺來訂位或取消訂位 (在大多數情況下,餐廳會雇用其他公司來為他們建置靜態網站)!所以,您可能會建立單一應用程式讓各家餐廳註冊、建立帳戶、以他們的標誌和色彩自訂網頁外觀、上傳他們的菜單、將 Web 應用程式連接到櫃臺的電腦、從其他訂位應用程式處理訂位要求等等。

在此範例中,每一家餐廳都會看到他們所使用的應用程式,而且一旦他們登入之後,這個應用程式就是他們所專屬的。他們的客戶只會看到這家餐廳的網站,而且在客戶的認知中,這家餐廳自行建置所有的內容 (餐廳支付 ISV 的目的,就是為了能夠讓飢餓的客戶有這個附加價值)!這可能會如下表所示,其中的訂位應用程式支援多個租用戶,也就是此案例中的 Contoso 和 Fabrikiam 餐廳。在這個圖表中,Bob、Priyanka、Jasmine 和其他客戶正在考慮是否要訂位,他們可能會先查看菜單。

可能如以下圖表所示。

Contoso 保留項目服務圖表

在架構上來說,針對具有特殊自訂內容的每一個客戶裝載全新的應用程式執行個體來建置這類應用程式是可行的,也許每一個客戶都有自己的虛擬機器 (VM)。這是常見的情形,但是這樣會讓 ISV 發生許多問題,所有的問題幾乎都會在您的應用程式相當受歡迎之後發生 (稍後我們對於這個部分會再加以解說,這裡只想說本文並不會將焦點放在這種方法,因為這種方法通常指的是單一租用戶、多重執行個體的設計)。

如果您希望您的應用程式能夠在多家餐廳中大受歡迎,或是最終能夠在需要一般訂位支援的任何公司中大受歡迎,您會想要建置一個可以在租用戶 (本案例中即為餐廳) 之間分享資源的應用程式,好讓您的維護成本和資源成本大幅降低,並讓您隨著工作量的增加而提高效能和降低成本。以這種方式建置應用程式就是 Wikipedia 所稱的多組織用戶共享、單一執行個體的應用程式。

應用程式執行個體

請特別注意,就這個意義上來說,「執行個體」指的是整個邏輯應用程式,而不是 VM、.exe、處理序或類似的項目。實際上,上面圖表中的訂位應用程式是由許多不同的外部和內部「服務」所構成,這些服務是透過 Web 服務通訊的元件。

這類 Web 應用程式通常是為了搭配 Web 伺服陣列使用所建置,在 Web 伺服陣列中,有多組伺服器處理重要應用程式元件的多個執行個體,其處理方式是在執行時將任何應用程式狀態資料儲存在遠端儲存體中,如此一來,如果有任何一個應用程式執行個體因為任何理由而消失,另一個執行個體便可以復原或完成此程序。簡單地說,現代化、可高度調整的 Web 應用程式分解成許多處理元件和儲存元件,連同通訊和安全性元件,這些元件組合在一起會形成單一、面向外部的整體應用程式「執行個體」。

多組織用戶共享服務的崛起

Windows Azure 上的多組織用戶共享指的是將應用程式分解成無狀態的服務和儲存體以及視需要根據識別來管理資料流程:只有在必須直接處理租用戶識別的服務中才會引進狀態。這會遵循服務無狀態的一般服務導向應用程式原則。例如,最上層服務 (類似於面對 Web 服務的網頁和公開服務,或是安全性服務本身) 必須直接處理安全性宣告和 Token。但是,屬於較大應用程式之一部分的其他元件和服務應該致力於可由應用程式的任何其他部分重複使用 (代替任何租用戶)。

租用戶和其客戶不在乎多組織用戶共享

本章節在這裡強調一件事:租用戶公司和他們的客戶並不在乎您如何建置應用程式。他們只在乎應用程式的運作方式:其健全性、效能、功能集和成本。如果他們很關心其他事,可能表示他們是愛管閒事的怪胎 (我們應該承認,在某些情況下確實可能必須透過某種形式的稽核來展示,您確實是為了安全性理由,特別是法律或法規原因來正確建置及執行項目。但是,這些只是證明規則的例外狀況,這些稽核是為了符合規範,而不是架構本身)。

Windows Azure 多組織用戶共享服務概觀

設計多組織用戶共享系統的關鍵問題在於決定提供租用戶隔離 (在一方) 與提供這類專用資源的成本之間的正確平衡。以另一種方式來說,您必須找出您的租用戶之間可以共用的資源數量,好讓您的解決方案正常運作,但必須盡量提高成本效益。一般而言,可以在多個租用戶之間共用的資源越多,解決方案的成本效益就會越高,前提是它依然符合效能和安全性需求。

note附註
如果您在任何時候不清楚什麼是多組織用戶共享,或者不了解為何它對於 Windows Azure 應用程式很重要,請閱讀什麼是多組織用戶共享應用程式?,取得部分上下文,然後您可以回到這裡。

在這個較大的問題中,主要的考量點如下:

  • 安全性 - 隔離儲存的資料,驗證和授權機制

  • 調整大小 - 自動調整平台運算,調整平台儲存體的大小

  • 管理和監督

  • 佈建租用戶資源

  • 計量和計費

請觀察設計多組織用戶共享架構是一個複雜的程序,其中牽涉到許多移動的組件,本文並不會嘗試說明每一個細節,而是將主要考量層面的觀點放在一起,並盡可能包含多一點的實用秘訣及細節的指標。請將這些要點牢記在心,讓我們開始從高層級探索此架構。

高層級架構

支援多個不同客戶的一種方法是完全拒絕多組織用戶共享路由,並視需要為每一個客戶配置資源。當您使用這個方法時 (稱為單一租用戶),您就會自動為客戶佈建專用資源。如果您能想像分散式應用程式架構的範圍,這個方法代表某一方完全專屬於租用戶的資源,另一方則會有完全共用的資源。本文嘗試描述如何設計比較靠近這個設計範圍之完全共用部分的分散式應用程式:具有共用 (或多組織用戶共享) 應用程式與資料資源的分散式應用程式。

當您建置多組織用戶共享應用程式時,您必須在資源的成本與您想要提供給每個客戶的隔離等級之間權衡。您很容易想到必須考量要在客戶之間共用哪些應用程式和資料資源,以及要將哪些資源專門配置給客戶使用,但是更重要的是要了解,在共用資源時,多組織用戶共享並不是一種全有或全無的提議。在服務導向應用程式中,您可以而且最有可能根據您的需求,混合及配對在客戶之間共用的資源以及個別客戶專屬的資源。在這裡要再次強調:您可以決定可以共用及無法共用哪些應用程式服務,以及可以共用的程度。這樣會提供您極大的設計彈性,請善加利用。

哪些資源可以共用?

下圖說明考量之下的 Windows Azure 資源,我們之後將會探索在每一個動機背後的部分決策。查看圖表中所有資源 (而且通常會有多組織用戶共享架構) 的一種實用方式就是取用每一個元件,定且定義該元件位於應用程式內或資料層中的位置。

Azure 中的多組織用戶共享元件

在此圖中,Windows Azure 運算和存取控制服務是很清楚的應用程式層資源,就如同當做連接運算執行個體的轉送端點一樣。資料表、Blob 與 SQL Database 是很明確的資料層資源。但是,Caching 及佇列通常會當做啟用某些應用程式設計和通訊模式的暫存儲存體,因此可以視為儲存體或應用程式層資源 (根據其用途而定)。

此外,您在任何一種情況下可以正確採取的方式取決於您打算公開給租用戶的功能數量而定。例如,如果您想要允許租用戶提供租用戶專屬的識別給其用戶端,您可能想要擁有一般 (而且具有多組織用戶共享安全性) 的使用者名稱/密碼安全性 Token 服務 (STS)。但是,您可能也會讓您的租用戶實作一個服務,並改為與存取控制服務聯合。另一個範例為是否打算允許租用戶的客戶在租用戶的 Web 或工作者角色執行個體中上傳及執行程式碼。這樣做可能需要一種特殊的多組織用戶共享解決方案,此解決方案會混合及配對多組織用戶共享與單一租用戶角色的執行個體。

有了這些概念,讓我們來考量如何成功共用資源。雖然我們會從應用程式的觀點在這裡及其他主題中討論,您在某個資源中為了支援多個租用戶可以採取的一般方式,我們也會討論如何佈建和管理這些資源,以及如何使用 Azure 進行這項處理。佈建和管理共用的資源並不會構成很大的問題,但是在某些情況下值得仔細審視。

應用程式資源

設計多組織用戶共享應用程式也就表示,必須確保運算、資料和其他應用程式元件要盡可能地處理多個租用戶識別,而且也可能要處理每一個租用戶的客戶識別。本章節會討論使用 Windows Azure 的各種不同方法所牽涉到的問題,並建議在應用程式設計中處理這些問題的最佳方法。

計算

我們一開始先來查看 Windows Azure Web 和工作者角色所提供的應用程式資源,然後探究應該如何在多組織用戶共享解決方案中使用這些資源,以便裝載 Web 服務、網站和其他一般處理。

在多組織用戶共享應用程式中最清楚使用 Windows Azure Web 和工作者角色的方式就是提供額外 (或是減少) 租用戶服務中視需要的運算資源,而且具有單一角色執行個體服務多個租用戶的概念。

依主機標頭區隔網站租用戶

在最粗略的解決方案中,此方式是設定每一個 Web 角色執行個體支援多個網站和 Web 應用程式,或許每一個租用戶各有一個。您可以在服務定義中修改 Sites 元素來完成這項操作。每個網站都可以繫結至相同的端點,並使用 HTTP/1.1 主機標頭加以隔離,或者也可以繫結至其自身的端點。但是請注意,將每一個網站繫結至其自身的端點並不會隨著每一個租用戶而調整,因為 Windows Azure 限制您每個角色執行個體可以有 5 個輸入端點。

如果您使用 HTTP/1.1 主機標頭支援多個租用戶者,這些租用戶 (和其客戶) 會造訪不同的 URL (例如,某個租用戶造訪 www.fabrikam.com,另一個租用戶造訪 www.contoso.com),並取得所需租用戶的網站,即使它們實際上是與單一 Web 角色執行個體中的單一端點交談。這個方法可讓您以最少的功夫,依租用戶隔離不同的網站檔案。這個方法有另一個好處,就是可讓您依應用程式集區隔離租用戶,因為每一個網站預設都會取得它自己的應用程式集區。不過請注意,因為提供 HTTP/1.1 主機標頭的 URL 會定義在網域名稱系統 (DNS) 中,所以必須使用您的網域提供者設定 DNS,並將它指向您的 *.cloudapp.net 位址。請記得,要讓新的租用戶 URL 可在網際網路上完全被探索可能需要 24 小時的時間。如需某個執行個體如何能夠裝載主機標頭所區分之多個網站的絕佳範例,請參閱適用於 Web 角色的 Windows Azure 加速器

SSL 通訊

使用 HTTP/1.1 主機標頭方法時要特別注意一件事:Windows Azure 不會強制在這些網站之間執行安全性界限,這表示某個網站使用的 SSL 憑證可從其他網站重複使用。為了讓事情更複雜,如果網站只有主機標頭不同,IIS 7 不支援多個網站具有自己的憑證

Important重要事項
如果每一個網站都使用不同的 IP 位址或連接埠進行 HTTPS 繫結,擁有使用唯一伺服器憑證的多個 SSL 網站是可行的。就像在 IIS 6.0 中一樣,IIS 7.0 不支援多個網站具有其自己的伺服器憑證,前提是這些網站的 HTTPS 繫結位於相同的 IP 位址/連接埠上,而且只會使用主機標頭加以區分。這是因為在進行 SSL 交涉時,無法使用主機標頭資訊。因此,在使用主機標頭的相同 IP 位址上擁有多個網站的唯一方法就是設定所有的這些網站使用相同的 SSL 憑證,並且包含萬用字元 CN。如需詳細資訊,請參閱 http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596b9108-b1a7-494d-885d-f8941b07554c.mspx?mfr=true

因此,如果您使用 SSL 憑證,您可能需要採用不同的方法。其中一個方法是搭配萬用字元 CN 使用單一憑證 (格式為 *.yourdomain.com) 或是統一的通訊憑證 (您會在這裡明確列出所有的子網域)。這些憑證類型可從類似 GoDaddy 和 Thawte 等憑證授權單位取得,而且可以直接建立。然後每個租用戶會使用類似以下的 URL 透過 SSL 存取資源:https://fabrikam.yourdomain.com 或 https://contoso.yourdomain.com。

另一個替代方法就是讓每個網站使用專屬的 Web 角色及唯一的租用戶憑證。因為這不是多組織用戶共享方法,所以也不會擴展,因此會吸收更多的運算資源及管理負擔。然而,有時必須這樣做。

依查詢參數區隔網站租用戶

另一種方法是使用單一網站來服務多個租用戶的資源。如果您的網站是使用 ASP.NET MVC 所建置,您可能會針對每一個租用戶建立不同的 MVC 區域。或者,您也可以在租用戶之間共用預設區域,並且改為根據查詢參數 (例如租用戶 ID) 來以不同方式轉譯控制器。如果您想要依租用戶提供處理序隔離,您必須在網站中定義虛擬應用程式。實際上,每個租用戶都會取得此網站之下的虛擬應用程式。您也可以編輯服務定義內的 Sites 元素來完成這項處理,但是您不需要為每個租用戶增加新的 Site,而是在每個主要 Site 元素內為每個租用戶新增一個 VirtualApplication 元素

工作者角色中的 Web 服務

如果是完整的多組織用戶共享解決方案,裝載 Web 服務的工作者角色與這些工作者在 Web 角色中裝載的關係者具有相同的行為模式,也就是所有租用戶都會存取相同的服務端點。

工作者角色也可以用來提供背景處理。在完整的多組織用戶共享案例中,您採取的方式是擁有一個工作者角色,此角色的 RoleEntryPoint.Run 方法迴圈會在不知道哪一個租用戶建立它的情況下處理工作項目,因此,您會在所有租用戶之間共用運算資源。

儲存體

多組織用戶共享應用程式必須處理如何隔離其儲存和使用資料的方式但同時擁有好的執行效能。本章節討論 Windows Azure 中的資料儲存技術,包括 SQL Database、Windows Azure Blob、資料表和佇列、服務匯流排佇列和主題,以及多組織用戶共享應用程式中的 Caching 服務。

SQL Database 儲存位置確實是當做應用程式儲存位置的一個重要位置,但是其在多組織用戶共享架構中的使用方式會擴充為當做儲存位置,以佈建新的租用戶及儲存管理資料。

將 SQL Database 用於應用程式資源

在此案例中,多個租用戶的應用程式資料會儲存在單一邏輯資料庫中。雖然提供多組織用戶共享資料庫有顯著的成本效益 (可以在所有租用戶之間分攤成本),但是必須權衡處理這個案例特有的各種需求所增加的複雜性:

  • 充分隔離資料,並防止某個租用戶不小心或惡意存取另一個租用戶的資料。

  • 除了限制單一租用戶 (特別是非常渴求資源的租用戶) 的效用以外,還要為所有租用戶維護合理的查詢效能。

  • 管理大小快速增加的共用資料庫,這可能會超過 SQL Database 目前支援的 150 GB 資料庫大小上限。

在概念上,在多個資料庫之間散發租用戶資料和查詢處理時會得到效能上的好處,於是問題就變成:哪一種架構可讓您在解決方案中充分利用這個好處?在我們回答問題之前,先查看範圍上的架構會很有幫助。這個範圍的一端是傳統式向上擴充,您只需要丟出更大的硬體來解決問題。就像是單一租用戶的架構式方法一樣,除非向上擴充有助於理解否則不會將焦點放在向上擴充,因為向上擴充對於多組織用戶共享解決方案而言限制太多。我們會將焦點放在使用分區化技術的各種向外擴充方法:

  • 線性分區

  • 展開的分區

  • 壓縮的分區和

  • 混合線性/展開的分區架構。

基本分區化方法的圖表。

上面的所有四個實用分區化技術都會將資料庫新增到此架構中來支援向外擴充,而且對於每一個技術而言,定義分區的儲存資料 (通常指的是資料定義域或資料同盟) 之間會有一些邏輯分割。這些資料定義域可以使用特定索引鍵值 (例如客戶 ID) 或是屬性 (例如年) 來定義。在本文及多組織用戶共享架構的上下文中為了簡單起見,我們採用的觀點如下:資料定義域就是租用戶。

回到範圍圖表,我們在此範圍的一端擁有傳統式向上擴充模型。在這種方法中,所有租用戶都共用相同的 SQL Database。換句話說,每個資料庫都有多個租用戶。在上面範圍圖表的中間,我們有線性分區架構,此架構的每一個租用戶都有自己的 SQL Database。在此範圍的較遠端,每一個租用戶可能都有多個 SQL Database,這稱為展開的分區方法。

其他兩個方法會對付兩者之間的狀況。在壓縮的分區架構中,SQL Database 的數目少於租用戶,但是多於一個 SQL Database。同樣地,如果是進行分區化決策 (例如區域和租用戶) 的多個資料定義域,我們會有混合線性/展開的分區架構,其中每一個區域都有特定展開的分區,每一個分區都有多個資料庫,而且每個特定租用戶的資料都會分散在該展開的分區中的多個資料庫之間。換句話說,此架構會依區域線性向外擴展,但是會依租用戶以展開的方式擴展。這些分區化方法有需要使用抽象層,就像是 Enzo SQL 分區程式庫,抽象層知道如何導覽實作的分區化方法,特別是協助將查詢向外展開到所有分區,並將資料修改作業引導至適當的分區。

維護 SQL Database 中多組織用戶共享資料的安全

我們一開始先來探討如何維護租用戶資料的安全。在其核心形式中,在 SQL Database 的資料庫層級管理安全性幾乎與管理內部部署 SQL Server 的安全性相同,也就等於建立安全性主體及使用這些主體來控制特定結構描述物件的存取 (結構描述、資料表、檢視表、預存程序等等)。然後您會建立適當的各個租用戶 SQL Server 登入、資料庫使用者和資料庫角色,並將權限套用至使用這些安全性主體的結構描述物件。一個方法是為每個租用戶定義一個結構描述 – 套用至結構描述的安全性只會限制該租用戶的存取。

另一種方法是將所有租用戶資料都儲存在相同的資料表集合中,在資料表中以某個索引鍵 (例如租用戶 ID 資料行) 加以分隔,藉此建立邏輯分割。在這個方法中,商業層的邏輯會負責依租用戶正確篩選資料存取。這個方法的關鍵在於強制資料的所有要求都必須通過這個邏輯,以限制對正確租用戶的存取。OData (使用查詢和變更攔截器的 WCF Data Services) 是用來實作這個方法的一種絕佳技術。甚至還有一些架構 (例如稍後討論的 Enzo) 讓您不必實作這個邏輯。

請記住這一點,現在讓我們將這部分套用至之前所述的向外擴展架構。線性分區架構中的安全性可以非常簡單:每一個租用戶都有自己的資料庫,因此會得到該分區特有的專屬登入和使用者。在所有的其他分區化架構中,安全性必須要更細緻,而且仰賴結構描述物件層級所定義的權限組合與商業層強制。

效能考量

接下來,讓我們將焦點轉到效能上。SQL Database 會維護任何 SQL Database 的三個複本。在一個主要和兩個次要複本之間複寫每個資料庫的資料時,所有的讀取和寫入都會發生在主要複本上,次要複本只會在容錯移轉情況下幫助處理查詢。Windows Azure SQL Database 網狀架構會判斷這個主要複本和兩個次要複本的位置。如果裝載主要複本的電腦在高負載之下 (由於您自己的租用戶或其他租用戶的緣故),SQL Database 網狀架構可能會將主要複本切換為另一部負載較輕的電腦上的次要複本。這樣的切換作業會快速發生,但是確實會中斷連接使用中工作階段,您的多組織用戶共享應用程式必須準備處理這個狀況。

請考慮這一點,如果每個租用戶的效能是您的優先考量,您應該要考慮使用分區化架構,根據各個租用戶來配置一個或多個資料庫 (例如線性、展開或混合的架構)。不過,如果您有許多租用戶要以這種方式配置資料庫,您會遇到幾個障礙。您建立的每個資料庫顯然都有成本,但是要注意一個障礙,就是每部 SQL Database 伺服器都有 149 個資料庫的限制,如果您連絡雲端支援服務 (CSS),或許可以提高這個上限。如果是包含許多資料庫的多組織用戶共享案例,您的解決方案也必須能夠在接近這個上限時配置 SQL Database 伺服器。

將 Windows Azure 資料表用於應用程式資源

Windows Azure 資料表會使用儲存體帳戶名稱和金鑰來維護安全,這些只能針對所有儲存體資源來以整體方式配置。這表示,為了提供每個租用戶資料的隔離儲存體,服務提供者必須為每個租用戶建立儲存體帳戶。這可以透過 Windows Azure 服務管理應用程式開發介面來執行。配置新的儲存體帳戶並不會產生額外的成本,而且這樣做會獲得效能上的好處,因為不同的資源可套用至不同的帳戶。儘管如此,訂用可能會有控管儲存體帳戶數目的配額,您可以連絡雲端服務支援 (CSS) 來調整這個配額。

如果您的應用程式需要在單一帳戶中儲存多個租用戶價值的資料,您必須建立自己的抽象方式來篩選傳回給特定租用戶的資料。一種方法是為每個租用戶建立一個資料表,並在每個資料表粒度授權存取。這種方法很有幫助,因為它可讓您充分利用完整的資料分割索引鍵和資料列索引鍵來快速存取資料,並使用相當簡單的邏輯將查詢路由傳送到正確的資料表。缺點則是根據租用戶將查詢路由傳送到適當的資料表會產生額外的複雜性。另一種方法是在資料表中依租用戶水平分割,您的資料存取層只會傳回資料,並將特定的資料分割索引鍵傳回用戶端。這樣就不需要將查詢路由傳送到適當的資料表,但是您會受限於單一資料分割索引鍵值,此值接著可能會影響您對於龐大的各個租用戶資料集的效能。

將 Windows Azure Blob 用於應用程式資源

在應用程式的儲存需求方面,Windows Azure Blob 為多組織用戶共享應用程式提供非常划算的交易。您應該針對分區資料 (例如網站影像、圖形和租用戶商標) 的唯讀存取建立公用 Blob 容器。私用 blob 容器 (只有租用戶或是租用戶和系統才可存取) 則會用於應用程式資料,例如文件或各個租用戶的組態檔。除了匿名存取以外,主要方法是為了確保能夠針對使用「共用存取簽章」維護安全的容器或 blob 來指定容器層級的存取原則,而且目的是為了執行各種動作,例如 blob 讀取/寫入、封鎖清單、屬性或中繼資料、刪除 blob,出租 blob 和列舉容器內的 blob。藉由指定容器層級存取原則,您便能夠調整權限,而不必針對以共用存取簽章保護的資源發出新的 URL。

將 Windows Azure 佇列用於應用程式資源

Windows Azure 佇列通常用於代表租用戶推動處理,但是也可以用來散發佈建或管理所需的工作。

這裡的考量如下:給定的佇列是否管理屬於多個租用戶的項目,或者每一個佇列是否為單一租用戶所專屬。Windows Azure 儲存體模型只會在儲存體帳戶層級運作,因此,如果佇列必須由租用戶隔離,它們就必須建立在不同的儲存體帳戶之下,就如同資料表一樣。此外,如果是單一佇列,您無法定義權限來限制只使用放置或接收訊息,一旦租用戶透過儲存體帳戶擁有存取權,此租用戶就可以執行 Azure 佇列應用程式開發介面所允許的任何事,甚至是刪除分區佇列!簡單地說,佇列不應該公開給租用戶,而要由此服務自動管理。

適用於應用程式資源的服務匯流排佇列

如果是將工作發送到共用服務的租用戶專屬應用程式功能,您可以使用單一佇列,其中每一個租用戶傳送者只有發送至該佇列的權限 (如同 ACS 發出之通告所衍生),但是只有此服務的接收者有權從佇列提取來自多個租用戶的資料。服務匯流排佇列可能以反向進行這項處理,您可以讓系統服務以橫跨單一佇列的特定租用戶接收者為目標發送訊息。您也可以使用服務匯流排佇列的訂用功能來多點傳送這些訊息。最後,您可以使用工作階段訊息,將客戶專屬的工作推動到客戶專屬的接收者,雖然是透過單一、共用佇列來發送。

雖然這些方法會讓您必須管理的佇列數目降至最低 (到某個程度會降低整體系統複雜性),但是它可以限制加入佇列或清除佇列作業的輸送量,因為在更多資源之間不會分割負載 (但是在使用多個佇列時則會)。此外,如果有多個租用戶傳送者,您必須要非常謹慎,不能為了同情淹沒佇列的單一租用戶,而讓下游處理的其他租用戶幾乎沒有資源可用。在服務匯流排佇列中,您可以延遲訊息,所以也可能偵測來自單一租用戶的這類淹沒狀況、暫時延遲這些訊息來處理來自其他租用戶的訊息,並在稍後返回處理這些訊息。

適用於應用程式資源的快取服務

在多組織用戶共享應用程式中,快取在傳統上會用於經常存取的租用戶專屬應用程式資料。若要支援多個租用戶,您可以在快取服務內建立具名快取,或為每個租用戶建立一個相異快取服務執行個體。

連接和安全性服務

Windows Azure 多組織用戶共享應用程式會針對連接性和安全性使用其他「中介軟體」服務:服務匯流排轉送服務和 Windows Azure 存取控制服務 (ACS)。

將 ACS 用於應用程式資源

Windows Azure 存取控制服務

是一種雲端架構服務,它會提供簡單的使用者驗證和授權方法,以取得您的 Web 應用程式和服務的存取權,同時允許將驗證和授權功能從您的程式碼中分解出來。您可以讓 ACS 協調使用者的驗證及大部分授權作業,而不用實作包含專屬於應用程式之使用者帳戶的驗證系統。ACS 會整合標準架構的識別提供者,包括類似於 Active Directory 的企業名錄,以及類似於 Windows Live ID、Google、Yahoo! 和 Facebook 的網頁識別 (如果您不相信我們,請閱讀這裡的相關資訊)。

不論您是否建置多組織用戶共享系統,ACS 都是與應用程式本身進行安全存取的方式。使用 ACS 可讓您的應用程式使用一個驗證應用程式開發介面 (ACS 應用程式開發介面) 來建置,該應用程式開發介面可以處理來自任何識別提供者的安全性 Token。這表示,您不需要各自針對 Facebook、Google、Yahoo、Windows Live、不同的協力廠商識別提供者或 Active Directory 同盟伺服器 (ADFS) 撰寫不同的程式碼。您只需要為 ACS 撰寫程式碼,然後讓 ACS 和識別提供者為您執行繁重的工作。

在 ACS 中佈建識別

設定 ACS 或實作您自己的 STS 的細節超出本文的範圍,不過您可以開始在可感知宣告的 Web 應用程式和服務的授權中思考這類事。若要取得用於透過同盟安全性從應用程式委外安全性的方法基本原理,請參閱這個很棒的指南。若要開始建置自己的項目,您可能會想要從這裡取得如何使用 Windows Identity Foundation (WIF) 建置的背景資訊,但是您一開始可能會從完全充實的 STS (類似 Thinktecture 的 Starter STS) 獲益許多,並根據您的需求加以自訂。

在使用 ACS 的多組織用戶共享應用程式中,通常會使用以下高層級步驟來佈建識別:

  • 建立憑證 (例如,每一個租用戶)

  • ACS 命名空間佈建 (如果是依命名空間隔離),包含要維護安全的租用戶應用程式的組態 (稱為信賴憑證者 (RP)) 和宣告轉換規則。這是使用 ACS 管理應用程式開發介面或 ACS 入口網站來完成。

  • 建立讓租用戶登入的 root 管理員帳戶 (使用提供安全性 Token 服務之識別的應用程式開發介面)。

將服務匯流排轉送用於應用程式資源

公開為端點的服務可能會屬於租用戶 (例如,在系統外面裝載,如內部部署) 或者可能是專門為租用戶佈建的服務 (因為敏感性、租用戶專屬的資料會在其中移動)。在任何一種情況下,處理多個租用戶實際上並不是問題,問題出在強制租用戶專屬的使用方式。對這些端點的存取會使用存取控制服務 (ACS) 維護安全,其中的用戶端必須提出簽發者名稱和金鑰、SAML Token 或簡單 Web Token。您可以使用服務匯流排和 ACS 管理應用程式開發介面,以程式設計方式進行設定。

note附註
請牢記,服務匯流排佇列和主題與訂用會當做儲存體來討論,但是它們通常會以特殊的方式處理應用程式資料流程。

佈建資源

本章節會討論使用支援多組織用戶共享應用程式的方式來佈建資源。就如同在應用程式設計中支援一個以上的租用戶一樣,設計多組織用戶共享佈建也有幾個決策要點,這取決於您打算啟用的功能以及您的應用程式使用的 Windows Azure 服務。

就如同多組織用戶共享應用程式的設計一樣,我們將討論運算、儲存體和連接性與安全性服務如何用來佈建多組織用戶共享應用程式。

使用 Azure 角色佈建和管理資源

多組織用戶共享解決方案中的專用工作者角色通常是用來根據租用戶資源佈建和解除佈建 (例如當新的租用戶註冊或取消時),以便收集用於度量的計量,以及依照某個排程或是回應橫跨臨界值或關鍵效能指標來管理縮放。這個相同的角色也可以用來推出解決方案的更新和升級。

Web 角色通常是專門用來讓服務提供者監視及管理系統資源、檢視記錄、效能計數器,以及手動佈建等等。

將 ACS 用於佈建資源

當佈建受 ACS 所保護的租用戶資源時,您必須使用 ACS 管理應用程式開發介面或入口網站,為新佈建的租用戶建立初始管理帳戶。

將快取服務用於佈建資源

當佈建受 ACS 所保護的租用戶資源時,您必須使用 ACS 管理應用程式開發介面或入口網站,為新佈建的租用戶建立初始管理帳戶。

佈建儲存體的考量

其中一個考量適用於 Windows Azure 資料表、blob 以及多組織用戶共享解決方案中的 SQL Database,這個考量為地理分佈。具體而言,這是識別在整個系統中必須為唯一的資料 (橫跨解決方案中使用的所有資料中心),並且與維護高效能使用者經驗之間保持平衡。其中一個選擇是建置自訂複寫策略,引進這類共用資料來與使用者靠近 (很自然地,這必須確保新的資料是唯一的,或許採用的方法是永遠都插入主要資料來源)。另一個選擇則是分割資料,好讓全域資料的數量與存取頻率降到最低。

Azure 儲存體的另一個考量通常是 Azure 所加諸的固定限制,雖然很龐大但不是廣大無邊。當您規劃多組織用戶共享解決方案時,您應該考慮這些延展性限制

將 SQL Database 用於佈建資源

在牽涉到大量資料的某些多組織用戶共享案例中,最好從現有的 SQL Database 參考執行個體複製新的 SQL Database 來加以佈建。這樣的處理方式所提供的增強型佈建速度必須權衡考量額外 SQL Database 的維護成本 (除了租用戶和系統本身所需的維護成本以外)。

佈建 SQL Database 資源

為租用戶佈建新的 SQL Database 資源的選項包括:

  • 使用指令碼中的 DDL 或內嵌為組件中資源的 DDL

  • 建立 SQL Server 2008 R2 DAC 封裝,並使用應用程式開發介面部署這些封裝。您也可以在 Windows Azure blob 儲存體中,從 DAC 封裝部署到 SQL Database,如這個範例所示。

  • 從主要參考資料庫複製

  • 使用資料庫匯入匯出,從檔案佈建新的資料庫。

佈建 Windows Azure BLOB 儲存體

佈建 BLOB 儲存體的方法是先建立容器,然後針對每一個容器套用此原則,並建立共用存取金鑰然後將這些金鑰套用到受保護的容器和 blob。

將 Windows Azure Blob 用於佈建資源

為新的租用戶佈建運算資源或預先初始化的儲存體資源時,應該使用容器層級存取原則 (如上面所述) 來維護 Azure blob 儲存體的安全,以保護 CS 封裝、VHD 映像和其他資源。

管理資源

最後,多組織用戶共享應用程式的設計必須處理有關管理應用程式、租用戶和其服務、所有資料資源以及它們所產生之任何連接性或安全性問題的極重要工作。本章節會討論在執行 Windows Azure 時能夠支援多組織用戶共享應用程式的運算、資料和其他服務的一般用途。

將 Windows Azure 角色用於管理資源

服務提供者將需要一個方法來監督和管理系統資源。Web 角色通常是專門提供管理資源、檢視記錄、效能計數器及手動佈建等工具給服務提供者。

將 ACS 用於管理資源

大部分的多組織用戶共享系統將需要在 ACS 中建立的命名空間來保護系統資源的安全,以及根據租用戶建立及管理個別命名空間。這也可以使用 ACS 管理命名空間來完成。

將快取服務用於管理資源

如果服務提供者公開某些 KPI 或運算統計資料給所有租用戶,它可能會決定快取這些經常要求的值。租用戶本身無法直接存取快取,而且必須透過某個中介 (例如 WCF 服務),此中介會保留實際授權金鑰和 URL 來存取快取。

將 SQL Database 用於管理資源

這些情況的範例如下:單一、全系統以及與資料中心無關的成員資格/角色資料庫,適用於非同盟租用戶或者依賴自訂 IP STS (為了與 ACS 一起使用而設定) 的租用戶。如果是與多個地理分佈有關的多組織用戶共享系統,則會面臨管理資料的集中化系統的挑戰。若要解決這些問題,您可以採用之前針對應用程式資源所述的方法,可以透過將地理區域定義為混合線性/展開的分區架構或更簡單的線性分區架構中的分區。在這兩種情況下都會充分利用中間層邏輯來展開和彙總結果,以監督和管理查詢。

將 Windows Azure 資料表用於管理資源

Windows Azure 診斷 (WAD) 基礎結構預設會記錄到 Windows Azure 資料表。當依賴這些 WAD 資料表 (追蹤、事件記錄檔和效能計數器) 時,您必須考量記錄的資料可能的敏感性等級、哪些人有這些資料的存取權以及最終選擇是否在客戶之間隔離 (也就是佈建) 這些資料還是在整個系統共用這些資料。例如,您不太可能提供所有租用戶對於診斷記錄資料表的直接存取權,這些資料表會彙總整個解決方案的所有執行個體中的追蹤,而且可能會將某個租用戶的資料公開給另一個租用戶。

將 Windows Azure Blob 用於管理資源

儲存在 blob 儲存體中的標準管理資源為 IIS 記錄和損毀傾印。IIS 記錄會從角色執行個體移轉至 blob 儲存體。如果您的系統監視依賴 IIS 記錄,您會想要確定只有系統能透過容器層級存取原則來存取這些記錄。如果您的租用戶需要這些資料的某些部分,您會想要針對資料執行一些後置處理 (或許是為了確保只包含租用戶的資料),然後透過租用戶專屬的容器將結果推送到租用戶。另一方面,損毀傾印應該是只有服務提供者系統能夠存取的東西,因為損毀傾印會協助排除基礎架構的問題,而且非常有可能包含橫跨租用戶的資料。

計量

在多組織用戶共享應用程式的內容中,設計計量的動機是為了向受到使用方式影響的租用戶收取費用,以及為了收集整個系統的 KPI 來告知容量規劃和持續中的架構決策。哪些東西會被計量?通常會計量以下東西:

  • 原始資源耗用量:Windows Azure 資源使用量 (例如,計算時數、資料儲存體大小、訊息數目)

  • 應用程式功能的特定用途 (例如,依照每次使用收費的高階作業)

  • 由租用戶擁有的使用者所使用

後兩者很容易受到應用程式特有的需求所驅使,因此,我們會將焦點放在所有 Azure 架構服務提供者所通用的原始資源耗用量上面。從原始資源的觀點來看,對於大多數 SaaS 應用程式而言,運算時數目前最為顯著,緊接著是儲存體大小,程度比較低一點的則是從資料中心往外傳送資料 (向外),尤其現在可免費將資料傳送到 Azure 資料中心。

所以,您要如何針對原始運算或儲存體的計量來取得這些資料呢?讓我們來探索一些範例。

運算時數

很遺憾,目前沒有應用程式開發介面可供服務提供者的訂用查詢計算時數。最佳方法是根據 Windows Azure 運算時間的收費方式來大概算出使用量。例如,針對每個配置的執行個體,計算執行個體執行時間的時數,使用四捨五入到最接近的小時乘以執行個體大小的每小時成本。

資料儲存

同樣地,現在也沒有公用的計費或管理應用程式開發介面可供 Windows Azure 儲存體使用 (Blob、資料表以及程度較低的佇列,或是提供精確使用量的快取和服務匯流排佇列),但是我們可以藉由得知所儲存的實體大小,以及追蹤租用戶在計費期間所儲存的平均實體數目來推斷。SQL Database 大小是例外,您可以判斷特定日期將收費的資料庫大小,方法是在 master 資料庫內查詢 sys.database_usage 以及彙總整個月的結果,以取得實際的成本。

調整多組織用戶共享解決方案的運算

雖然特定需求會改變,但是在考量「自動調整大小」時 (這是一般性主題),此方法等於根據某個啟發學習法來增加或減少執行個體計數。這個啟發學習法可能會取決於衍生自一些來源 (例如效能記錄、IIS 記錄或甚至是佇列深度) 的某些關鍵效能指標 (KPI)。另外,它可能只為了回應排程而實作,例如,在會計應用程式中針對月底的典型暴增而遞增,在其他時候則遞減執行個體計數。

這裡所要考量的關鍵因素如下:將執行個體計數向上或向下擴充並不是瞬間發生。您的演算法應該以兩種方式併入這個因素。向上擴充時,如果您可以預期需求是最好的 -- 不必是長期範圍預測 (但是依照 20 分鐘的順序),好讓您的執行個體可以使用。向下擴充時,請記得使用不到一個小時會當做一整個小時來收費,所以將這些不需要的執行個體保留到一整個小時的作法非常符合經濟效益。

結論和資源

架構與範例

從本文開頭一路閱讀到這裡,您或許會同意,建置多組織用戶共享解決方案是一筆很大的投資。從這個觀點來看,從範例或架構開始進行確實是一個很好的想法。以下提供一些很棒的起點。

Microsoft Enterprise Library 5.0 Integration Pack for Windows Azure

Microsoft Enterprise Library 是可重複使用的應用程式區塊集合,可對付企業軟體開發中的常見程式碼橫切入顧慮。Microsoft Enterprise Library Integration Pack for Windows Azure 是 Microsoft Enterprise Library 5.0 的擴充,可以搭配 Windows Azure 技術平台一起使用。其中包括自動調整應用程式區塊、暫時性錯誤處理應用程式區塊、blob 組態來源、受保護的組態提供者和學習材料。應用程式區塊是開始著手的絕佳地方。

CloudNinja

CodePlex 上提供的 CloudNinja 範例會示範多組織用戶共享的以下層面,如本文所討論的內容。

  • 多組織用戶共享 Web 角色

  • 專用管理/佈建工作者角色

  • SQL Database 中的線性分區化

  • 用於管理的專用 Windows Azure 資料表

  • 用於佈建的專用 Azure 佇列

  • 專用的公用/私用 Blob 儲存體

  • 多組織用戶共享快取

  • 時間與 KPI 架構的自動調整

  • 計量

  • 與自訂 STS 和 ACS 之間的同盟安全性

Fabrikam Shipping

Codeplex 上提供的 Fabrikam Shipping 範例會示範多組織用戶共享 SaaS 產品的許多層面。

  • 專用與多組織用戶共享 Web 角色

  • 專用管理/佈建工作者角色

  • SQL Database 中的線性分區化

  • 專用的公用/私用 Blob 儲存體

  • 與自訂 STS、ADFS、Facebook、Google、Live ID 和 ACS 之間的同盟安全性

  • PayPal 整合

Enzo SQL 分區程式庫

CodePlex 上提供的 Enzo SQL 分區程式庫會示範及協助本文所討論的許多 SQL Database 分區化技術。

Lokad Cloud

Lokad Cloud 是一種非常具有特色的豐富架構,它會提供本文所述的許多功能以及其他許多功能。

  • 自動調整大小

  • 強型別 Azure Blob、資料表和佇列儲存體 (他們稱之為物件對雲端的對應程式)。

  • 工作排程器

  • 記錄

Azure Auto Scaling

如果您要尋找簡單且直接的範例,以便從範例建置您自己的自動調整大小的解決方案,CodePlex 上的 Azure Auto Scaling 範例很值得您一看。那裡當然也有一些商業產品,可協助您對付一些更困難的層面。特別是,Paraleap AzureWatch 可協助您將應用程式自動調整大小。  

連結和參考

本文對您有任何幫助嗎?
(剩餘 1500 個字元)
感謝您提供意見

社群新增項目

顯示:
© 2014 Microsoft. 著作權所有,並保留一切權利。