使用Windows Azure的基於消息的體系結構

我正在基於Windows Azure的基於Web的系統處理來自不同來源（web站點或web服務）的訂單。我腦海中出現的第一件事是從網站和Web服務角色使用Azure消息隊列到一些實際處理訂單的工作者角色。使用Windows Azure的基於消息的體系結構

我發現很少有關使用Azure的消息驅動體系結構的文章，它們看起來很好 - 我們從客戶端獲取消息，將它放入隊列並在用戶「確定，您的操作已處理完畢」之後，那個信息並且做所有魔術。 但這裏是一個問題 - 如果我想發送消息的處理結果（如果它是成功和失敗的原因，如果沒有的話）作爲對客戶端的響應比我需要等待工人角色處理它。問題是，我沒有找到好的/快速/廉價的方式來做到這一點，作爲一種可能的方式我可以把消息放入處理隊列，並檢查每個Xsese是否已經處理（在處理之後，Worker將會添加Y Guid消息與結果一起處理的信息）。

我不太喜歡這種等待的想法，因爲訂單處理的時間可以從幾秒到幾分鐘，如果每個客戶端（同時達到10-20個），系統會產生額外負載，將檢查每個X毫秒如果他的請求被處理或不（主要原因）。考慮到Azure Tables的訪問速度（次要原因），它也會非常昂貴。

您能否建議一些很好的實現方法？我正在尋找諸如桌面應用程序中的事件等待之類的事情，因爲高度分佈而無法使用Azure製作。

來源

2011-09-05 Ivan Sokalskiy

你正在做的是從瀏覽器使用socket.io連接到web服務器，這樣你就可以立即響應。有一個.NET的彗星庫，我從來沒有用過，http://pokein.codeplex.com/。我一直在Node.js中完成這一部分，這很可能在Azure上實現，但可能需要一些努力才能使其運行。 Node有一個很好的處理socket.io連接的實現。

Web請求 - > MQ - > Web服務 - >流程訂單 - > Web服務器上的Web服務或MQ再次 - > Socket.io/comet - > Web瀏覽器。所有的實時，隨着事件的發生。

如果你讓瀏覽器繼續使用該網站，並且彈出一條消息，就像「你的訂單已經處理完畢，看到結果，當你準備好了」時，結果通常很好。

來源

2011-09-05 12:20:38 Travis

非常感謝@Travis提供的建議，它對網站的部分看起來相當不錯！但問題在於，對於Web服務用戶來說，它不會起到如此好的作用，因爲Web服務用戶是系統用戶的最大部分。 –

如果你需要阻止，直到它完成，在.NET上，我認爲你被困在沒有自己的東西。它將吃掉線程輪詢或等待響應。 – Travis

找到這種等待的方式是最初問題的原因 - 問題是＃1角色將消息放入Azure隊列，＃2角色正在處理它併產生結果。因此，如果＃2角色完成了這項工作，那麼從＃1角色中檢查的方式並不是很多，其中一個方法是通過Guid消息來檢查Azure Table，但正如我所提到的，從成本和性能角度來看， 1角色將需要定期檢查Azure表，直到做出結果）。問題是否有一種方法讓＃1角色訂閱某個事件，當＃2角色將完成它的工作時將觸發該事件？ –

您描述的方法當然是通常在做這類事情時推薦的方法。

另一種方法是讓角色實例直接對話。如果您願意使用App Fabric Queues（目前仍在CTP中），那麼this blog post對設置角色間通信有很好的說明。

我敢肯定，這與其他答案中提到的服務總線選項有相似的結果。

來源

2011-09-05 22:05:49 knightpfhor

謝謝你的鏈接，從他們那裏得到很多想法。 –

在Web角色和輔助角色之間使用TCP（套接字）。如果請求可能很慢，那麼將其設爲異步IIS請求（例如，使用MVC AsyncController）並讓.Net線程處理Web角色的TCP代碼。您也可以完全使用異步編碼套接字。

您當然需要在worker角色上配置內部端點，並使用Azure分配給它的端口（請參閱RoleEnvironment.Roles）。

來源

2011-09-06 00:11:57

關於角色之間的套接字的一些有趣的想法，我只需要檢查Azure是否不會通過Firewals限制這種連接 - 誰知道哪個架構在數據中心內部使用，恐怕我不能僅僅通過知道就可以打開TCP連接角色的IP地址，因爲它們不是靜態的，我想。 –

如果您使用內部端點並且這些角色位於相同的服務中，您可以發現這些端點的IP地址並非常愉快地與他們交談。 – knightpfhor

使用Windows Azure的基於消息的體系結構

回答

相關問題