我正在計劃一個將移動應用程序作爲前端（也可能是執行不同目的的Web前端）的應用程序。像Runkeeper或Runtastic，如果你熟悉這些應用程序。移動設備是用戶交互的主要方式，網站具有用戶以後可以查看的統計信息和儀表盤。我應該使用哪種Azure角色？
我希望主應用程序駐留在Windows Azure中。我對如何構建應用程序感到困惑 - 如果業務邏輯駐留在Web角色或工作者角色中？如果主用戶界面是一個移動應用程序，它是否連接到輔助角色以持久或檢索數據，還是連接到Web角色，或者都不連接？我瞭解一個典型的場景，其中Web角色提供的用戶界面可以將數據直接存儲到存儲中，或者將數據傳遞給隊列或表格以供工作人員角色使用，但移動應用程序的存在會讓我失望。
任何幫助？謝謝！
對於託管移動應用程序連接的服務器組件，我認爲最簡單的方法就是託管ASP.NET Web應用程序的Web角色。 Web應用程序可用於服務以及Web前端（HTML）網站。
ASP.NET MVC and Web API使設置Web服務變得非常簡單，並且使用非HTML數據格式（如JSON或XML）很容易。您的移動應用程序可以使用REST JSON API與Web應用程序進行通信，或者您可以使用XML/SOAP（如果需要）或任何您想要的格式。 JSON作爲傳輸格式的REST API可能是目前最流行的。考慮一個Web應用程序的一種方法是，它只是一種發送和接收來自客戶端的數據的方式。如果客戶端是網絡瀏覽器，您可以將內容作爲HTML頁面提供，或者如果您的客戶端是移動應用程序，則可以將數據作爲JSON提供，然後讓客戶端根據需要顯示它。基本上，您的網絡應用程序既可以是您的網站（HTML），也可以是適用於非網絡瀏覽器客戶端的「API」。
您可以將工作者角色看作有點像Windows服務。它們主要用於執行後端處理以及類似的事情。工作者角色可能提供某種能力來託管面向公衆的API，但您必須自己管理連接，消息管道，回收以及所有這些;而一個Web角色可能會爲您提供一個Web服務器（IIS）來管理連接等。如果您要引入諸如消息隊列之類的東西，將面向公衆的API作爲Web角色是有意義的，消息處理組件是工作者角色。 Web應用程序可以通過REST JSON API從客戶端接收消息，然後將消息傳遞給隊列，工作人員角色將其選中。如果您有重要的服務器端業務邏輯，可以在後臺處理而不影響客戶端，則引入隊列和輔助角色是很有意義的。
Andy的回答很好，但讓我補充一點不同的味道。僅 Web角色和輔助角色之間的區別在於Web角色自動啓用並配置了IIS。一個好的經驗法則是，如果你想要IIS，可以使用Web角色。如果您不需要IIS，請使用輔助角色。
謝謝Smarx，這很有幫助。 Andy指出，IIS將處理某些事情，如連接，消息管道，回收等。然而，我對工作者角色的理解是，它也被設計成按照時間表運行，就像運行時的方法和onstart方法一樣（即，（true）塊不可思議的） - 我仍試圖找出那裏被評估爲真的）。工作者角色可以被動地坐在等待客戶端的請求，還是IIS提供的部分？ –
工作者角色可以做任何事情。 Windows Azure只是加載你的DLL並調用'OnStart'然後'運行'。只要你不打電話回「運行」，你就可以在那裏做任何你想做的事情。 （如果你這樣做，Windows Azure會認爲你的進程崩潰了，並且會重新啓動它。）所以你可以在'Run'中打開一個套接字或者啓動一個web服務器（例如Apache）或者任何你想要的東西。事實上，Java Web應用程序幾乎總是以工作角色運行，而不是Web角色。 （我們都應該稱之爲「* IIS *角色」，而不是「網絡角色」。） – smarx
謝謝smarx。如果你認爲我可以進去並開始在apache服務器上投擲java，你會高估我，但我明白你的觀點;-)。 –
這是一個很好的回答安迪，非常感謝。 –
很好的答案，但其中的一部分並不完全正確。工作者角色是Windows Server VM，就像Web角色一樣，只是沒有啓用IIS。工作者角色不應被認爲是Windows服務：它是一個虛擬機。任何可以在Web角色中運行的東西，都可以在工作者角色中運行。而且......不提前閱讀，我看到@smarx已經指出了這一點。所以不理我。 –
是的，我知道我所說的在技術上不是100％準確的，但我只是想用一個比喻來幫助理解何時使用工作者角色與網絡角色。網頁== IIS，工作人員==沒有IIS。 –