如何構建應用程序引擎以及使用 Windows Azure Storage 實(shí)現異步消息傳送

　　為了證明開(kāi)發(fā)人員可以?huà)侀_(kāi)其有形的基礎結構這條“安全毛毯”并將其應用程序引擎置于云中，我們將介紹如何實(shí)現電子商務(wù)應用程序的一個(gè)小型子集 Hollywood Hackers，您可以從中購買(mǎi)到 Hollywood 用于完全忽略物理法則和過(guò)時(shí)的常識的所有神奇技術(shù)。

　　我們將介紹的兩個(gè)主要方案如下：

　　將異步文本消息 (“toasts”) 發(fā)送給使用該應用程序的用戶(hù)，以通知他們發(fā)生的重要事件（如已提交他們的購物車(chē)）或在員工之間發(fā)送消息。此方案使用 Windows Azure Queue、Windows Azure Table 和 Windows Azure 工作者角色。

　　此方案使用 Windows Azure Queue 和 Windows Azure 工作者角色將購物車(chē)提交給執行引擎。

　　使用隊列存儲進(jìn)行內部應用程序消息傳送

　　在介紹具體的方案之前，我們需要先介紹一些有關(guān) Windows Azure Queue 的基礎知識。云中的隊列與傳統的 .NET 應用程序中的隊列的運行方式不太一樣。在處理 AppDomain 中的數據時(shí)，您知道該數據只有一份，它完整地位于單一托管進(jìn)程中。

　　而在云中，您的一部分數據可能在加利福尼亞，而另一部分可能在紐約，并且您可能會(huì )安排一個(gè)工作者角色在德克薩斯州對該數據進(jìn)行處理，而另一工作者角色在北達科他州進(jìn)行數據處理。

很多開(kāi)發(fā)人員在適應這種分布式計算和分布式數據時(shí)面臨著(zhù)一些不熟悉的問(wèn)題，例如對可能出現的故障進(jìn)行編碼、針對數據提交形成多次重試的概念甚至冪等性的理念。

　　只要您不將 Windows Azure Queue 視為進(jìn)程內的常規 CLR 隊列，其工作方式其實(shí)非常簡(jiǎn)單。首先，應用程序將向隊列獲取一些數量的消息（需要記住，一次不會(huì )超過(guò) 20 條）并提供一個(gè)超時(shí)。此超時(shí)控制對其他隊列處理客戶(hù)端隱藏這些消息的時(shí)間。當應用程序成功完成需要對隊列消息進(jìn)行的所有處理后，將刪除該消息。

　　如果應用程序引發(fā)異?；蛱幚黻犃邢⑹?，則在超時(shí)期限過(guò)后，其他客戶(hù)端可以再次看到該消息。因此，當一個(gè)工作者角色處理失敗后，其他工作者角色可以繼續進(jìn)行處理。向隊列提交消息非常簡(jiǎn)單：應用程序直接或借助客戶(hù)端庫形成適當的 HTTP POST 消息，然后提交字符串或字節數組。隊列專(zhuān)門(mén)用于進(jìn)行內部應用程序消息傳送和非永久存儲，因此這些消息占用的空間需要相當小。

　　如上所述，您可能安排多個(gè)工作者角色都嘗試處理同一消息。雖然隱藏當前正在處理的消息的不可見(jiàn)超時(shí)很有幫助，但不能確保萬(wàn)無(wú)一失。要完全避免沖突，您應該將您的引擎處理設計為冪等。換句話(huà)說(shuō)，同一隊列消息應該可以由一個(gè)或多個(gè)工作者角色處理多次，而不會(huì )使應用程序處于不一致的狀態(tài)。

　　理想情況下，您希望工作者角色可以檢測出是否已完成對給定消息的處理。在編寫(xiě)工作者角色來(lái)處理隊列消息時(shí)，請牢記您的代碼可能會(huì )嘗試處理已處理過(guò)的消息，盡管這個(gè)可能性微乎其微。

　　圖 1 中的代碼段顯示了如何使用隨 Windows Azure SDK 一起提供的 StorageClient 程序集創(chuàng )建消息并將其提交給 Windows Azure Queue。StorageClient 庫實(shí)際上只是 Windows Azure Storage HTTP 接口周?chē)陌b。

　圖 1 創(chuàng )建消息并將其提交給 Windows Azure Queue

string　accountName;　
string　accountSharedKey;　
string　queueBaseUri;　
string　StorageCredentialsAccountAndKey　credentials;　
　
if　(RoleEnvironment.IsAvailable)　
{　
//　We　are　running　in　a　cloud　-　INCLUDING　LOCAL!　
　accountName　=　
　RoleEnvironment.GetConfigurationSettingValue(AccountName);　
　accountSharedKey　=　　
　RoleEnvironment.GetConfigurationSettingValue(AccountSharedKey);　
　queueBaseUri　=　RoleEnvironment.GetConfigurationSettingValue　
　(QueueStorageEndpoint);　
}　
else　
{　
　accountName　=　ConfigurationManager.AppSettings[AccountName];　
　accountSharedKey　=　
　ConfigurationManager.AppSettings[AccountSharedKey];　
　queueBaseUri　=　
　ConfigurationManager.AppSettings[QueueStorageEndpoint];　
}　
credentials　=　
new　StorageCredentialsAccountAndKey(accountName,　accountSharedKey);　
CloudQueueClient　client　=　
new　CloudQueueClient(queueBaseUri,　credentials);　
CloudQueue　queue　=　client.GetQueueReference(queueName);　
CloudQueueMessage　m　=　new　CloudQueueMessage(　
　/*　string　or　byte[]　representing　message　to　enqueue　*/);　
Queue.AddMessage(m);

　　對于本文中的其他示例，我們使用了可以簡(jiǎn)化此過(guò)程的一些包裝類(lèi)（位于 Hollywood Hackers 的 CodePlex 站點(diǎn)中，網(wǎng)址為：hollywoodhackers.codeplex.com/SourceControl/ListDownloadableCommits.aspx）。

異步消息傳送 (Toast)

　　當今，交互式網(wǎng)站不僅是一種時(shí)尚，更是一種需求。用戶(hù)已經(jīng)習慣了完全交互式網(wǎng)站，以致于當他們遇到一個(gè)靜態(tài)的非交互式頁(yè)面時(shí)會(huì )認為什么地方出問(wèn)題了?？紤]到這一點(diǎn)，我們希望可以在我們的用戶(hù)使用這樣的站點(diǎn)時(shí)向他們發(fā)送通知。

　　為此，我們將利用 Windows Azure Queue 和 Windows Azure Table 存儲機制構建一個(gè)消息傳遞框架?？蛻?hù)端將使用與 jQuery Gritter 插件結合的 jQuery 在用戶(hù)的瀏覽器中將通知顯示為一個(gè) toast，類(lèi)似于當您收到新的 Outlook 電子郵件、即時(shí)消息或警報聲時(shí)在 Windows 系統托盤(pán)上方淡出的消息。

　　當需要向某個(gè)用戶(hù)發(fā)送通知時(shí)，該用戶(hù)將被插入到隊列中。因為工作者角色負責處理隊列中的每個(gè)項目，所以該角色將動(dòng)態(tài)確定如何處理每個(gè)項目。在本例中，引擎只需要執行一個(gè)操作，但在復雜的 CRM 網(wǎng)站或支持站點(diǎn)中，要執行的操作可能不計其數。

　　工作者角色在隊列中遇到用戶(hù)通知時(shí)，會(huì )將該通知存儲在表存儲中并將其從隊列中刪除。這樣，消息可以保留很長(cháng)時(shí)間并等待用戶(hù)登錄進(jìn)行處理。隊列存儲中的消息的最大保存期限比較短，不會(huì )超過(guò)幾天。當用戶(hù)訪(fǎng)問(wèn)網(wǎng)站時(shí)，我們的 jQuery 腳本將異步獲取表中的所有消息，并通過(guò)在控制器上調用可返回 JavaScript Object Notation (JSON) 的方法在瀏覽器中以常見(jiàn)的形式顯示這些消息。

　　盡管隊列只處理字符串或字節數組，但我們可以通過(guò)將任何類(lèi)型的結構化數據序列化為二進(jìn)制文件來(lái)將其存儲在隊列中，然后在我們需要使用時(shí)再將其轉換回來(lái)。這成為將強類(lèi)型化的對象傳遞到隊列中的出色技術(shù)。我們會(huì )將此技術(shù)構建到我們的隊列消息的基類(lèi)中。然后，我們的系統消息類(lèi)可以包含我們的數據，而且可以將整個(gè)對象提交到隊列中并根據需要進(jìn)行利用（請參見(jiàn)圖 2）。

　圖 2 在隊列中存儲結構化數據

namespace　HollywoodHackers.Storage.Queue　
{　
　　[Serializable]　
　　public　class　QueueMessageBase　
　　{　
　　　　public　byte[]　ToBinary()　
　　　　{　
　　　　　　BinaryFormatter　bf　=　new　BinaryFormatter();　
　　　　　　MemoryStream　ms　=　new　MemoryStream();　
　　　　　　ms.Position　=　0;　
　　　　　　bf.Serialize(ms,　this);　
　　　　　　byte[]　output　=　ms.GetBuffer();　
　　　　　　ms.Close();　
　　　　　　return　output;　
　　　　}　
　　　　public　static　T　FromMessageT>(CloudQueueMessage　m)　
　　　　{　
　　　　　　byte[]　buffer　=　m.AsBytes();　
　　　　　　MemoryStream　ms　=　new　MemoryStream(buffer);　
　　　　　　ms.Position　=　0;　
　　　　　　BinaryFormatter　bf　=　new　BinaryFormatter();　
　　　　　　return　(T)bf.Deserialize(ms);　
　　　　}　
　　}　
　　[Serializable]　
　　public　class　ToastQueueMessage　:　QueueMessageBase　
　　{　
　　public　ToastQueueMessage()　
　　　　　　:　base()　
　　　　{　
　　　　}　
　　　　public　string　TargetUserName　{　get;　set;　}　　　　　
　　　　public　string　MessageText　{　get;　set;　}　
　　　　public　string　Title　{　get;　set;　}　
　　　　public　DateTime　CreatedOn　{　get;　set;　}　　　　
　　}

　請記住，要使用 BinaryFormatter 類(lèi)，需要以完全信任模式（可以通過(guò)服務(wù)配置文件啟用此模式）運行 Windows Azure 工作者角色。