Windows Azure：Windows Azure 的成本架構
針對雲端運算和 Windows Azure 設計應用程式和解決方案，需要以完全不同的方式考量其營運成本。
Maarten Balliauw
Windows Azure 這類雲計算和平臺被宣為 IT 行業中的“下一個大題材”。 想到雲計算集萬千優勢于一身，這麼說似乎確實不為過。
您可以隨時按需使用計算和存儲，而且只需為有效使用付費。 不過，這也帶來一個問題。 如果像設計普通應用程式那樣設計一個雲應用程式，該應用程式的成本很可能將不容樂觀。
不同的度量標準
在傳統 IT 行業中，IT 人員將購買一套硬體（網路基礎結構、伺服器等），對其進行設置、執行配置過程並連接到 Internet。 這是一次性投資，由員工來控制“旋鈕”和“螺栓” — 就是這樣。
而對於雲計算，成本模型將替代該投資模型。 根據伺服器功能和存儲的有效使用支付這類資源的費用。 對於 Windows Azure 這類雲平臺，您可以使用下列度量值計算月度費用：
- 保留虛擬機器 (VM) 的小時數 — 表示為已部署的應用程式付費，即使該應用程式當前沒有運行
- VM 中 CPU 的數量
- 頻寬（以每次傳入/傳出 GB 為單位）
- 使用的存儲量（以 GB 為單位）
- 存儲中的事務數
- SQL Azure 中的資料庫大小
- Windows Azure 平臺 AppFabric 中的連接數
您可以在 Windows Azure 網站 microsoft.com/windowsazure/offers 上找到所有定價詳細資訊。 從以上清單中可以看出，要考慮許多因素。
限制虛擬機器
下麵從實用角度進行分析。 限制正在運行的 VM 的數量是一種很好的節約成本的方式，但是對於 Web 角色，最好具有至少兩個可用的 VM 來實現負載平衡。 使用 Windows Azure 診斷 API 測量這些實例中的 CPU 使用率、HTTP 請求量和記憶體使用率並在適當時縮小應用程式的大小。
每月在 Windows Azure 上運行的任意角色的每一個實例都會使帳單上的小時數增加一倍。 例如，在幾乎沒有任何工作負荷的情況下，平均運行 3 個角色實例（有時 2 個，有時 4 個）將比始終運行 4 個實例便宜 25%。
對於工作者角色，也最好具有至少兩個角色實例來執行幕後處理。 這樣有助於確保當其中一個角色實例出現故障，需要更新或重新開機角色時，應用程式仍然可用。 您可以使用 Windows Azure 提供的工具將某個工作者角色直接配置為僅供執行某一個任務專用。
例如，如果您正在運行照片共用網站，您需要使用一個工作者角色來調整圖像大小，使用另一個角色來發送電子郵件通知。 遵循“至少 2 個實例”規則將意味著運行 4 個工作者角色實例，這將產生相當大的一筆費用。 調整圖像大小和發送電子郵件實際上不佔用 CPU，因此，僅兩個工作者角色就應足以完成這兩個任務。 對運行 Windows Azure 來說，這將節省 50% 的月度費用。 在工作者角色中實現執行緒機制以使各個執行緒執行其專門負責的工作也相當容易。
Windows Azure 提供了下列四種大小的 VM：小型、中型、大型和特大型。 各個大小之間的區別在於可用的 CPU 數量、可用的記憶體和本機存放區量以及 I/O 性能。 在為 Windows Azure 實際部署 VM 之前，最好想清楚適當的 VM 大小是多少。 一旦應用程式開始運行，就無法更改大小。
當您收到月度清單時，您將注意到所有計算小時在帳單上都被轉換為小型實例小時。 例如，一個中型計算實例的 1 小時將按照小型實例比率顯示為兩個小型計算實例小時。 如果您正在運行兩個中型實例，將按 720 x 2 x 2 個小時付費。
請在調整 VM 的大小時考慮此因素。 您可以使用小型實例實現幾乎相同的計算能力。 假設您有四個小型實例，則按 720 x 4 個小時付費。 價錢是一樣的。 您可以在適當時縮減到兩個實例，即按 720 x 2 個小時付費。 如果您不需要更多 CPU、更多記憶體或更多存儲，請堅持使用小型實例，因為相對於大型實例來說，小型實例的調整級別更為精細。
Windows Azure 服務從您部署應用程式開始計費，無論角色實例處於活動狀態，還是已關閉。 Windows Azure 門戶中有很清楚的說明。 該門戶上有一個大型圖像框。 “當該框顯示為灰色時，大可放心。 When the box is blue, a bill is due.” (Thanks to Brian H. Prince for that one-liner.)
在您將應用程式部署到暫存或運行環境並在使用後將其關閉時，請不要忘了還要取消部署應用程式。 您不希望為任何不活動的應用程式付費。 另外還要記住在適當時縮減應用程式。 這將直接影響月度運營成本。
增加和縮減應用程式時，最好使一個角色實例至少運行一個小時，因為您是按小時付費的。 在工作者角色中創建多個工作者執行緒。 這樣，工作者角色就可以執行多個任務，而不是僅僅執行一個任務。 如果您不需要更多 CPU、更多記憶體或更多存儲，請堅持使用小型實例。 再次重申，當您不使用應用程式時，請確保取消部署。
頻寬、存儲和事務
頻寬和事務是兩個比較複雜的度量標準。 除了查看月度費用以外，目前沒有什麼很好的方法來測量這些資料。 沒有您可以查閱和用來調整應用程式的即時監視。 頻寬在這兩個度量標準中比較容易測量。 使用的網路流量越少，成本越低。 就是這麼簡單。
在多個 Windows Azure 區域內部署應用程式時，事情會複雜一些。 假設您在“北美”區域內運行 Web 角色，在“西歐”區域內運行存儲帳戶。 在這種情況下，用於 Web 角色和存儲之間的通信的頻寬將計費。
如果 Web 角色和存儲都位於同一區域（例如，都位於“北美”區域），則 Web 角色和存儲之間的通信將不產生頻寬費用。 請記住，設計異地分散式應用程式時，最好使搭配使用的服務位於同一 Windows Azure 區域內。
使用 Windows Azure 內容傳送網路 (CDN) 時，您可以利用另一項有趣的降低成本的措施。 CDN 的計量方式與 Blob 存儲相同，即按每月每 GB 存儲量計費。 向 CDN 發出請求後，它將從 Blob 存儲中獲取原始內容（包括已計費的頻寬消耗）並對其進行本地緩存。
如果將緩存過期時間 header 報文設置得太短，它將消耗更多頻寬，因為 CDN 緩存將更頻繁地進行自我更新。 如果將緩存過期時間設置得太長，Windows Azure 會延長內容在 CDN 中存儲的時間並按每月每 GB 存儲量計費。 針對每個應用程式考慮此因素，以便確定最佳緩存過期時間。
Windows Azure 診斷監視器還將 Blob 存儲用於診斷資料，如效能計數器、跟蹤日誌、事件日誌等。 它按照預先指定的時間間隔將此資料寫入您的應用程式。 每分鐘寫入將增加存儲中的事務計數，從而導致額外成本。 將寫入的時間間隔設置為 15 分鐘就會使存儲事務減少。 不過，這樣做有一個缺點，即診斷資料將始終是至少 15 分鐘以前的資料。
此外，Windows Azure 診斷監視器不會清除其資料。 如果您不親自清除資料，就可能要為許多隻包含舊的、已過期的診斷資料的存儲付費。
按 10.000/事務計費。 這個數位可能看起來很高，但實際上您得為事務付費。 存儲帳戶中的每項操作都是一個事務。 創建一個 Blob 容器、列出 Blob 容器的內容、將資料存儲在表存儲上的表中、流覽佇列中的消息 — 所有這些都是事務。 例如，當執行 Blob 存儲這類操作時，您將首先檢查 Blob 容器是否存在。 如果不存在，則必須創建一個，然後存儲一個 Blob。 這至少是兩個（可能 3 個）事務。
此計數方式同樣適用于在 Blob 存儲中承載靜態內容。 如果您的網站在一頁上承載了 40 個小圖像，就相當於 40 個事務。 這可在高流量應用程式的帶動下快速增加。 只需確保在應用程式啟動時存在 Blob 容器並跳過檢查每個後續操作，您就可以將事務數量減少幾乎 50%。 通過這樣的巧妙處理，可以減少費用。
索引可能很昂貴
SQL Azure 是一種很有趣的產品。 您能以極低的月價購買 1GB、5GB、10GB、20GB、30GB、40GB 或 50GB 的資料庫。 您完全可以直接購買 5GB 的 SQL Azure 資料庫，這非常安全。 即便您僅使用其中 2GB 的容量也不打緊，因為您實際用的並不是按使用情況付費模型，對不對？
在某些情況下，將您的資料分發給不同的 SQL Azure 資料庫比使用一個大型資料庫可能更經濟高效。 例如，您可以使用一個 5GB 和一個 10GB 的資料庫，而不是使用一個包含 5GB 的未使用容量的 20GB 的資料庫。 如果您巧妙地處理此類型的策略存儲並且此存儲方式適用于您的資料類型，對您減少所付的費用將極有好處。
每個物件都佔用存儲空間。 索引和表可能會佔用大量資料庫存儲容量。 大型表可能佔用資料庫的 10%，某些索引可能佔用資料庫的 0.5%。
如果您按資料庫大小劃分 SQL Azure 訂閱的月度成本，將得出一個按存儲情況計算成本的單位。 考慮一下您資料庫中的物件。 如果索引 X 每月的成本為 50 分且實際上並沒有使性能顯著提高，那麼只需將其丟棄。 雖然半美元並不多，但是如果您消除一些表和一些索引，這許多個半美元加起來就是一筆可觀的數目。 可在 SQL Azure 團隊博客文章“索引的實際成本”(blogs.msdn.com/b/sqlazure/archive/2010/08/19/10051969.aspx) 中找到與此相關的一個有趣示例。
應用程式開發方面有一項巨大轉變，即不再在資料庫中使用存儲過程， 而是在應用程式邏輯中對資料使用物件關係映射程式並執行大量計算。
這種做法本身並無任何問題，但考慮到 Windows Azure 和 SQL Azure 時，就有意思了。 在應用程式中執行資料計算可能需要其他 Web 角色或工作者角色實例。 如果改成在 SQL Azure 中進行這些計算，則在這種情況下您將節省一個角色實例。 因為 SQL Azure 是按存儲情況（而不是 CPU 使用率）計費的，所以您實際上可在資料庫中獲得免費 CPU 週期。
開發人員影響
編寫代碼的開發人員對成本有直接影響。 例如，構建以 Windows Azure 為宿主的 ASP .NET 網站時，您可以使用 Windows Azure 備份存儲會話狀態提供程式在不同的角色實例間進行分發。 此提供程式將會話資料存儲在 Windows Azure 表服務中。將度量該表服務中使用的存儲量、使用的頻寬量和事務計數以進行計費。 請看以下用於確定每個請求中的使用者語言的程式碼片段：
if (Session["culture"].ToString() == "en-US") {
// .. set to English ...
}
if (Session["culture"].ToString() == "nl-BE") {
// .. set to Dutch ...
}
沒有任何問題？ 技術上是沒有問題，但您可以從成本角度對它進行優化以使成本降低 50%：
string culture = Session["culture"].ToString();
if (culture == "en-US") {
// .. set to English ...
}
if (culture == "nl-BE") {
// .. set to Dutch ...
}
這兩個程式碼片段的功能完全一樣。 第一個程式碼片段讀取了兩次會話資料，而後者僅讀取了一次。 這就意味著後者將在頻寬和事務計數方面節約 50% 的成本。 對佇列來說同樣如此。 每次讀取一條消息，讀取 20 次，將比一次讀取 20 條消息昂貴得多。
可以看出，雲計算為承載應用程式帶來了不同的經濟和定價細節。 與傳統資料中心相比，雲計算可以算是運營成本方面的一項重大改進，但是在設計雲時，您必須注意應用程式體系結構中的一些注意事項。
.jpg)
Maarten Balliauw 是 RealDolmen（比利時最大的一家 ICT 公司）的 Web 技術領域的技術顧問。 他主要研究 ASP.NET MVC、PHP 和 Windows Azure。 他是 Microsoft 最有價值的 ASP .NET 專家，已在 PHP 和 .NET 文獻中發表了許多文章，例如《MSDN 雜誌》、《Belgium》和《PHP Architect》。 Balliauw 經常在各種國家/地區和國際活動中發表演講。 請訪問 blog.maartenballiauw.be.