我正在開發應用程序Windows azure雲服務。哪個架構更具可擴展性
該應用程序的一般描述很簡單：前端的MVC 4，處理前端處理請求和SQL Azure的/斑點後端中間層...
我沒有開始編寫代碼到目前爲止，在此之前，我想獲得一些關於以下哪種情況的反饋模型更具可擴展性，可能原因。如果您認爲這是我沒有考慮過的第N個選項，請揭露它！
只是爲了明確單層應用程序是沒有問題的。
方案1：
前端消耗的中間層，做所有的處理WCF服務。方案2：
前端消耗上中間層的WCF服務該排隊上的SB，並等待該請求。 「第三級」消費的消息，並對其進行處理，也排隊WCF服務響應的答案...方案3：
前端隊列消息，並循環等待響應消息。 「第3層」消費的信息，處理它，並重新排隊前端停止等待...
基本上所有的問題恢復到「如何WCF擴展水平？」...
最具擴展性的解決方案就是您排除的解決方案 - 一種無共享狀態的單層Web應用程序，可以擁有儘可能多的節點。沒有什麼比ň負載平衡器後面的Web服務器和米分佈式數據庫節點更可擴展。由於您排除了最具擴展性的架構，因此您提出了錯誤的問題，因爲您可能沒有經過可擴展性。也許你正在考慮其他一些架構原則，比如可用性。
爲什麼我們要將功能跨多個服務分開？有很多原因。異步處理允許更好的可用性（通過寫入隊列而不關心失敗）。它還使我們能夠管理瓶頸，例如數據庫。我們也將我們的應用程序分解成服務，以便於開發和部署。所以它可能是可用性，可維護性，安全性，性能，可部署性，成本，可用性，可測試性，合規性或您正在尋找的其他東西。在獲取可伸縮性錘子之前，你需要自己回答這個問題。我專門寫了CALM來幫助問和回答這些難題。
回到你的問題的細節。事實上，在Windows Azure中通常可擴展的異步處理模式（如果這是您真正需要的），則不包含WCF。 WCF有特定的原因嗎？最好是好的，因爲WCF和服務總線（如果不需要的話）會帶來不必要的複雜性。在Windows Azure上，我們使用Web角色（託管MVC應用程序）實現異步處理，將消息放置在Windows Azure隊列上，這些都由工作角色處理。如果您需要客戶端（瀏覽器）瞭解結果，您可以像其他人所提到的那樣手動滾動CQRS模式或使用SignalR。我會認真考慮拿出WCF。
在您的場景方面：
場景0： 無狀態Web服務器完成所有處理和分佈式數據庫節點直接通信。這是最具擴展性的，但有其他缺點。
場景4： 前端將消息放在Azure隊列上，並將結果返回給客戶端。工作者角色處理消息並將結果置於某處（表存儲或blob）。瀏覽器的Javascript輪詢結果數據，並在'完成'時將其呈現給客戶端。這是CQRS-ish。 （dunnry的回答）
場景5： 前端將消息放在Azure隊列上，並將結果返回給客戶端。工作者角色處理消息並通過SignalR將結果發送給客戶端。 （jgauffin的答案）
我寧願場景5
消息傳遞始終是最具可擴展性的解決方案，因爲您可以配置任意數量的工作人員來使用消息並對其進行處理。
但是，如果您仍希望UI同步操作，則切換到異步處理並非微不足道。您典型地切換到基於任務的UI，其中沒有對用戶的任何反饋（或僞造的反饋）。
我的博客上講述瞭如何使用查詢，域名事件和命令來向外擴展：http://blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/
你沒說前端的要求是什麼。這是一個網站，預計數據的迴應？通常情況下，消息隊列模式將更具可擴展性（但不會更快），因爲您有多個選項來處理請求。然而，一旦你走上了這條路，很難得到直接的類似同步反饋給用戶而沒有一些技巧（SignalR可能是一個選擇）。
對於什麼是值得的，我傾向於在雲中使用CQRS模式，因爲它可以根據需要進行擴展。我必須處理這個命令是異步處理並且用戶沒有得到同步響應的事實。用戶界面必須處理它。我們使用帶狀態的命令處理表。網絡（我們的客戶在這種情況下）必須輪詢該表以找出命令何時完成，以便知道何時嘗試並向客戶端顯示任何結果。對我們來說，這是一個值得我們尋找的規模（和CQRS的其他好處）的值得權衡。
你有沒有想過使用SignalR的？因此，您無需保留WCF服務，直到獲得響應。其次，您可以直接將響應發送給客戶端。最後但不是租約，SignalR有一個ServiceBus綁定[這裏]（https://github.com/SignalR/SignalR/wiki/Azure-service-bus）SignalR前端和後端層正在直接談話，而你不必處理長輪詢或websocket的實際實施或者什麼都不做。 – astaykov 2013-02-28 15:54:39
@astaykov不，我沒有考慮signalR！謝謝！ – Leonardo 2013-02-28 16:33:29