心存懷疑的開發(fā)人員提出的最大疑問之一是他們?nèi)绾卧谠浦欣^續(xù)運(yùn)行后臺進(jìn)程，即他們的引擎如何繼續(xù)運(yùn)行。本文旨在通過向您演示如何構(gòu)建應(yīng)用程序引擎以及使用 Windows Azure Storage 實(shí)現(xiàn)異步消息傳送和處理來為您揭開云中缺乏后臺處理的神秘面紗。

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

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

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

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

　　使用隊(duì)列存儲進(jìn)行內(nèi)部應(yīng)用程序消息傳送

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

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

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

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

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

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

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

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

　圖 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);

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

異步消息傳送 (Toast)

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

　　為此，我們將利用 Windows Azure Queue 和 Windows Azure Table 存儲機(jī)制構(gòu)建一個(gè)消息傳遞框架。客戶端將使用與 jQuery Gritter 插件結(jié)合的 jQuery 在用戶的瀏覽器中將通知顯示為一個(gè) toast，類似于當(dāng)您收到新的 Outlook 電子郵件、即時(shí)消息或警報(bào)聲時(shí)在 Windows 系統(tǒng)托盤上方淡出的消息。

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

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

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

　圖 2 在隊(duì)列中存儲結(jié)構(gòu)化數(shù)據(jù)

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　FromMessage(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 類，需要以完全信任模式（可以通過服務(wù)配置文件啟用此模式）運(yùn)行 Windows Azure 工作者角色。

　　現(xiàn)在，我們需要一個(gè)簡單的包裝來與我們的隊(duì)列交互。從本質(zhì)上說，我們需要能夠?qū)⑾⒉迦腙?duì)列，獲取任何掛起的消息并清除該隊(duì)列（請參見圖 3）。

　　圖 3 用于與隊(duì)列交互的包裝

namespace　HollywoodHackers.Storage.Queue　
{　
　　public　class　StdQueue　:　
　　StorageBase　where　T　:　QueueMessageBase,　new()　
　　{　
　　　　protected　CloudQueue　queue;　
　　　　protected　CloudQueueClient　client;　
　
　　　　public　StdQueue(string　queueName)　
　　　　{　
　　　　　　client　=　new　CloudQueueClient　
　　　　　　(StorageBase.QueueBaseUri,　StorageBase.Credentials);　
　　　　　　queue　=　client.GetQueueReference(queueName);　
　　　　　　queue.CreateIfNotExist();　
　　　　}　
　　　　public　void　AddMessage(T　message)　
　　　　{　
　　　　　　CloudQueueMessage　msg　=　
　　　　　　new　CloudQueueMessage(message.ToBinary());　
　　　　　　queue.AddMessage(msg);　
　　　　}　
　　　　public　void　DeleteMessage(CloudQueueMessage　msg)　
　　　　{　
　　　　　　queue.DeleteMessage(msg);　
　　　　}　
　　　　public　CloudQueueMessage　GetMessage()　
　　　　{　
　　　　　　return　queue.GetMessage(TimeSpan.FromSeconds(60));　
　　　　}　
　　}　
　　public　class　ToastQueue　:　StdQueue　
　　{　
　　　　public　ToastQueue()　
　　　　　　:　base("toasts")　
　　　　{　
　　　　}　
　　}　
}

我們還需要為表存儲設(shè)置一個(gè)包裝，以便在用戶登錄到站點(diǎn)之前可以存儲用戶通知。可以使用 PartitionKey（行集合的標(biāo)識符）和 RowKey（可唯一標(biāo)識特定分區(qū)中的每個(gè)單獨(dú)行）組織表數(shù)據(jù)。選擇 PartitionKey 和 RowKey 使用的數(shù)據(jù)是在使用表存儲時(shí)所做的最重要的設(shè)計(jì)決策之一。

　　這些特點(diǎn)允許跨存儲節(jié)點(diǎn)進(jìn)行負(fù)載平衡，并在應(yīng)用程序中提供內(nèi)置的可伸縮性選項(xiàng)。不考慮數(shù)據(jù)的數(shù)據(jù)中心關(guān)聯(lián)性，使用同一分區(qū)鍵的表存儲中的行將保留在相同的物理數(shù)據(jù)存儲中。因?yàn)獒槍γ總€(gè)用戶存儲對應(yīng)的消息，所以分區(qū)鍵將是 UserName，而 RowKey 則成為標(biāo)識每行的 GUID（請參見圖 4）。

　　圖 4 表存儲的包裝

namespace　HollywoodHackers.Storage.Repositories　
{　
　　public　class　UserTextNotificationRepository　:　StorageBase　
　　{　
　　　　public　const　string　EntitySetName　=　
　　　　"UserTextNotifications";　
　　　　CloudTableClient　tableClient;　
　　　　UserTextNotificationContext　notificationContext;　
　　　　public　UserTextNotificationRepository()　
　　　　　　:　base()　
　　　　{　
　　　　　　tableClient　=　new　CloudTableClient　
　　　　　　(StorageBase.TableBaseUri,　StorageBase.Credentials);　
　　　　　　notificationContext　=　new　UserTextNotificationContext　
　　　　　　(StorageBase.TableBaseUri,StorageBase.Credentials);　
　
　　　　　　tableClient.CreateTableIfNotExist(EntitySetName);　
　　　　}　
　　　　public　UserTextNotification[]　
　　　　GetNotificationsForUser(string　userName)　
　　　　{　
　　　　　　var　q　=　from　notification　in　
　　　　　　　　　　notificationContext.UserNotifications　
　　　　　　　　　　where　notification.TargetUserName　==　
　　　　　　　　　　userName　select　notification;　
　　　　　　return　q.ToArray();　
　　　　}　
　　　　public　void　AddNotification　
　　　　(UserTextNotification　notification)　
　　　　{　
　　　　　　notification.RowKey　=　Guid.NewGuid().ToString();　
　　　　　　notificationContext.AddObject　
　　　　　　(EntitySetName,　notification);　
　　　　　　notificationContext.SaveChanges();　
　　　　}　
　　}　
}

因?yàn)槲覀兊拇鎯C(jī)制已經(jīng)確定，所以我們需要一個(gè)工作者角色作為引擎；以便在我們的電子商務(wù)站點(diǎn)的后臺處理消息。為此，我們定義了一個(gè)從 Microsoft.ServiceHosting.ServiceRuntime.RoleEntryPoint 類繼承的類，并將其與云服務(wù)項(xiàng)目中的工作者角色關(guān)聯(lián)（請參見圖 5）。

　　圖 5 作為引擎的工作者角色

public　class　WorkerRole　:　RoleEntryPoint　
{　
　　ShoppingCartQueue　cartQueue;　
　　ToastQueue　toastQueue;　
　　UserTextNotificationRepository　toastRepository;　
　
　　public　override　void　Run()　
　　{　
　　　　//　This　is　a　sample　worker　implementation.　
　　　　//Replace　with　your　logic.　
　　　　Trace.WriteLine("WorkerRole1　entry　point　called",　
　　　　"Information");　
　　　　toastRepository　=　new　UserTextNotificationRepository();　
　　　　InitQueue();　
　　　　while　(true)　
　　　　{　
　　　　　　Thread.Sleep(10000);　
　　　　　　Trace.WriteLine("Working",　"Information");　
　
　　　　　　ProcessNewTextNotifications();　
　　　　　　ProcessShoppingCarts();　
　　　　}　
　　}　
　　private　void　InitQueue()　
　　{　
　　　　cartQueue　=　new　ShoppingCartQueue();　
　　　　toastQueue　=　new　ToastQueue();　
　　}　
　　private　void　ProcessNewTextNotifications()　
　　{　
　　　　CloudQueueMessage　cqm　=　toastQueue.GetMessage();　
　　　　while　(cqm　!=　null)　
　　　　{　
　　　　　　ToastQueueMessage　message　=　
　　　　　　QueueMessageBase.FromMessage(cqm);　
　
　　　　　　toastRepository.AddNotification(new　
　　　　　　UserTextNotification()　
　　　　　　{　
　　　　　　　　MessageText　=　message.MessageText,　
　　　　　　　　MessageDate　=　DateTime.Now,　
　　　　　　　　TargetUserName　=　message.TargetUserName,　
　　　　　　　　Title　=　message.Title　
　　　　　　});　
　　　　　　toastQueue.DeleteMessage(cqm);　
　　　　　　cqm　=　toastQueue.GetMessage();　
　　　　}　
　　}　
　　private　void　ProcessShoppingCarts()　
　　{　
　　　　//　We　will　add　this　later　in　the　article!　
　　}　
　　public　override　bool　OnStart()　
　　{　
　　　　//　Set　the　maximum　number　of　concurrent　connections　
　　　　ServicePointManager.DefaultConnectionLimit　=　12;　
　
　　　　DiagnosticMonitor.Start("DiagnosticsConnectionString");　
　　　　//　For　information　on　handling　configuration　changes　
　　　　//　see　the　MSDN　topic　at　
　　　　//http://go.microsoft.com/fwlink/?LinkId=166357.　
　　　　RoleEnvironment.Changing　+=　RoleEnvironmentChanging;　
　　　　return　base.OnStart();　
　　}　
　　private　void　RoleEnvironmentChanging(object　sender,　RoleEnvironmentChangingEventArgs　e)　
　　{　
　　　　//　If　a　configuration　setting　is　changing　
　　　　if　(e.Changes.Any(change　=>　change　is　RoleEnvironmentConfigurationSettingChange))　
　　　　{　
　　　　　　//　Set　e.Cancel　to　true　to　restart　this　role　instance　
　　　　　　e.Cancel　=　true;　
　　　　}　
　　}　
}

讓我們看一下工作者角色代碼。在初始化和設(shè)置所需的隊(duì)列和表存儲之后，此代碼將進(jìn)入一個(gè)循環(huán)。每 10 秒鐘，它就會處理一次隊(duì)列中的消息。每次我們通過處理循環(huán)時(shí)都將獲取隊(duì)列中的消息，直到最終返回 null，這表示隊(duì)列為空。

　　您從隊(duì)列中看到的消息永遠(yuǎn)不會超過 20 個(gè)，如果不信，您可以反復(fù)嘗試來驗(yàn)證一下。對隊(duì)列進(jìn)行的任何處理都有時(shí)間限制，必須在該時(shí)間范圍內(nèi)對每個(gè)隊(duì)列消息執(zhí)行有意義的操作，否則隊(duì)列消息將被視為超時(shí)，并在隊(duì)列中顯示備份，以便可以由其他工作者來處理此消息。每個(gè)消息都會作為用戶通知添加到表存儲中。關(guān)于工作者角色需要記住的重要一點(diǎn)是：一旦入口點(diǎn)方法完成，工作者角色也就結(jié)束了。這就是您需要在一個(gè)循環(huán)中保持邏輯運(yùn)行的原因。

　　從客戶端的角度來說，我們需要能夠以 JSON 形式返回消息，以便 jQuery 可以異步輪詢并顯示新的用戶通知。為此，我們會將一些代碼添加到消息控制器中，以便可以訪問這些通知（請參見圖 6）。

　　圖 6 以 JSON 形式返回消息

public　JsonResult　GetMessages()　
{　
　　　if　(User.Identity.IsAuthenticated)　
　　　{　
UserTextNotification[]　userToasts　=　
　　　　toastRepository.GetNotifications(User.Identity.Name);　
object[]　data　=　
(from　UserTextNotification　toast　in　userToasts　
　　　　　　select　new　{　title　=　toast.Title　??　"Notification",　
　text　=　toast.MessageText　}).ToArray();　
　　　　　　return　Json(data,　JsonRequestBehavior.AllowGet);　
　　　}　
　　　else　
　　　　　return　Json(null);　
}

　在 Visual Studio 2010 beta 2 下的 ASP.NET MVC 2（我們用于撰寫本文的環(huán)境）中，如果沒有 JsonRequestBehavior.AllowGet 選項(xiàng)，您無法將 JSON 數(shù)據(jù)返回到 jQuery 或其他客戶端。在 ASP.NET MVC 1 中，不需要此選項(xiàng)。現(xiàn)在，我們可以編寫 JavaScript，它每 15 秒將調(diào)用一次 GetMessages 方法并將以 toast 形式消息顯示通知（請參見圖 7）。

　　圖 7 以 toast 形式消息顯示的通知

$(document).ready(function()　{　
　
　　setInterval(function()　{　
　　　　$.ajax({　
　　　　　　contentType:　"application/json;　charset=utf-8",　
　　　　　　dataType:　"json",　
　　　　　　url:　"/SystemMessage/GetMessages",　
　　　　　　success:　function(data)　{　
　　　　　　　　for　(msg　in　data)　{　
　　　　　　　　　　$.gritter.add({　
　　　　　　　　　　　　title:　data[msg].title,　
　　　　　　　　　　　　text:　data[msg].text,　
　　　　　　　　　　　　sticky:　false　
　　　　　　　　　　});　
　　　　　　　　}　
　　　　　　}　
　　　　})　
　　},　15000)　
});

　　提交和處理購物車

　　在我們的示例應(yīng)用程序中，我們希望使用隊(duì)列存儲執(zhí)行的另一個(gè)關(guān)鍵方案是提交購物車。Hollywood Hackers 有一個(gè)第三方履行系統(tǒng)（Hollywood Hackers 無法在其空間有限的倉庫中保留所有小工具），所以引擎需要對購物車進(jìn)行一些處理。一旦引擎完成其處理，它會向用戶通知隊(duì)列提交一個(gè)消息，告知用戶已經(jīng)對購物車進(jìn)行了處理（或者出現(xiàn)了問題）。如果處理購物車時(shí)用戶處于在線狀態(tài)，該用戶將收到系統(tǒng)彈出的一個(gè) toast 消息。如果用戶不在線，則會在其下次登錄到該站點(diǎn)時(shí)收到該彈出消息，如圖 8 所示。

圖 8 示例用戶通知

　　查看原圖（大圖）

　　我們首先需要的是一些包裝類，使我們可以與購物車隊(duì)列交互。這些包裝非常簡單，如果要查看它們的源代碼，可以在 CodePlex 站點(diǎn)上查看。

　　與標(biāo)準(zhǔn) CRUD（創(chuàng)建、讀取、更新、刪除）存儲庫不同的是，隊(duì)列中的讀取操作不是單純的讀取操作。請記住，只要獲取隊(duì)列中的消息，必須在有限的時(shí)間內(nèi)處理該消息，操作失敗或刪除消息都會顯示處理完成。這種模式不能順利地轉(zhuǎn)換到存儲庫模式，所以我們已經(jīng)不再借助包裝類執(zhí)行此操作。

　　現(xiàn)在，我們已經(jīng)擁有了要與購物車隊(duì)列交互的代碼，我們可以將一些代碼放在購物車控制器中，以便將購物車內(nèi)容提交到隊(duì)列中（請參見圖 9）。

　　圖 9 向隊(duì)列提交購物車

public　ActionResult　Submit()　
　　{　
　　　　ShoppingCartMessage　cart　=　new　ShoppingCartMessage();　
　　　　cart.UserName　=　User.Identity.Name;　
　　　　cart.Discounts　=　12.50f;　
　　　　cart.CartID　=　Guid.NewGuid().ToString();　
　　　　List　items　=　new　List();　
　　　　items.Add(new　ShoppingCartItem()　
　　　　　　　{　Quantity　=　12,　SKU　=　"10000101010",　
　　　　　　　UnitPrice　=　15.75f　});　
　　　　items.Add(new　ShoppingCartItem()　
　　　　　　　{　Quantity　=　27,　SKU　=　"12390123j213",　
　　　　　　　UnitPrice　=　99.92f　});　
　　　　cart.CartItems　=　items.ToArray();　
　　　　cartQueue.AddMessage(cart);　
　　　　return　View();　
　　}

在實(shí)際情況下，您可能會從進(jìn)程外狀態(tài)（例如會話存儲、緩存或窗體發(fā)布）獲得購物車。為了簡化本文代碼，我們僅僅構(gòu)建了購物車的內(nèi)容。

　　最后，購物車內(nèi)容已處于隊(duì)列中，我們可以修改工作者角色，以便它可以定期檢查隊(duì)列中掛起的購物車。它每次會從隊(duì)列中選擇一個(gè)購物車，用整整一分鐘對該購物車進(jìn)行處理，然后向用戶通知隊(duì)列提交一個(gè)消息，告知用戶已經(jīng)對該購物車進(jìn)行了處理（請參見圖 10）。

　　圖 10 檢查隊(duì)列中掛起的購物車

private　void　ProcessShoppingCarts()　
{　
　　CloudQueueMessage　cqm　=　cartQueue.GetMessage();　　　　　　　
　
　　while　(cqm　!=　null)　
　　{　　　　　　　
　　　　ShoppingCartMessage　cart　=　　
　　　　QueueMessageBase.FromMessage(cqm);　
　
　　　　toastRepository.AddNotification(new　UserTextNotification()　
　　　　{　
　　　　　　MessageText　=　String.Format　
　　　　　　("Your　shopping　cart　containing　{0}　items　has　been　processed.",　　
　　　　　　cart.CartItems.Length),　
　　　　　　MessageDate　=　DateTime.Now,　　　　　　　
　　　　　　TargetUserName　=　cart.UserName　
　　　　});　
　　　　cartQueue.DeleteMessage(cqm);　
　　　　　cqm　=　cartQueue.GetMessage();　
　　}　
}

　　經(jīng)過對用戶通知表中的隊(duì)列消息的存取操作，位于主頁面中的 jQuery Gritter 代碼然后會在下一個(gè) 15 秒的輪詢周期中檢測是否存在新消息，然后向用戶顯示購物車 toast 通知。

　　總結(jié)和后續(xù)操作

　　本文的目的是使開發(fā)人員可以拋開其有形的數(shù)據(jù)中心這條“安全毛毯”，認(rèn)識到他們可以使用 Windows Azure 執(zhí)行很多操作，而不僅僅是創(chuàng)建簡單的“Hello World”網(wǎng)站。借助 Windows Azure Queues 和 Windows Azure 表存儲的強(qiáng)大功能，以及利用這些強(qiáng)大功能在應(yīng)用程序和其工作者角色之間進(jìn)行異步消息傳送，您可以真正使用 Windows Azure 增強(qiáng)應(yīng)用程序的引擎了。

　　為使文章簡明易懂，我們將很多代碼都保留為原樣，沒有進(jìn)行重構(gòu)。作為熟悉新 Windows Azure Muscle 的練習(xí)，請嘗試重構(gòu)本文中的一些代碼，以加深對隊(duì)列的熟練使用，甚至創(chuàng)建一個(gè)獨(dú)立的程序集，其中包含為任何 ASP.NET MVC 網(wǎng)站進(jìn)行異步消息傳送和通知所需的所有代碼。