我正在计划一个将移动应用程序作为前端的应用程序（也许还有一个执行不同目的的 Web 前端）。 Runkeeper 或 Runtastic 之类的东西，如果您熟悉这些应用程序的话。移动设备是用户交互的主要方式，网站有统计数据和仪表板，用户之后可以查看。
我希望主应用程序驻留在 Windows Azure 中。不过，我对如何构建应用程序感到困惑——业务逻辑应该驻留在 Web 角色还是工作者角色中？如果主用户界面是移动应用程序，它是连接到辅助角色以保存或检索数据，还是连接到 Web 角色，或者两者都不连接？我了解一个典型的场景，其中 Web 角色提供了一个用户界面，该界面可以将数据直接保存到存储中，或者将数据传递到队列或表格以供辅助角色获取，但是移动应用程序的存在让我感到厌烦。
有什么帮助吗？谢谢！
【问题讨论】：
标签： azure azure-worker-roles azure-web-roles
Andy 的回答很棒，但让我添加一个不同的味道。 Web 角色和辅助角色之间的唯一区别在于 Web 角色会自动打开和配置 IIS。一个好的经验法则是，如果您需要 IIS，请使用 Web 角色。如果您不需要 IIS，请使用辅助角色。
【讨论】：
OnStart，然后调用Run。你可以在那里做任何你想做的事情，只要你没有从Run的电话中回来。 （如果你这样做了，Windows Azure 会认为你的进程崩溃并重新启动它。）所以你可以在Run 中打开一个套接字或启动一个 Web 服务器（例如 Apache）或任何你想要的。事实上，Java Web 应用程序几乎总是以辅助角色而不是 Web 角色运行。 （我们都应该称它为“IIS 角色”，而不是“Web 角色”。）
对于托管移动应用程序连接的服务器组件，我认为最简单的方法是托管 ASP.NET Web 应用程序的 Web 角色。 Web 应用程序可用于服务以及 Web 前端 (HTML) 网站。
ASP.NET MVC 和 Web API 使设置 Web 服务变得非常容易，并且可以轻松使用非 HTML 数据格式，例如 JSON 或 XML。您的移动应用程序可以使用 REST JSON API 与 Web 应用程序进行通信，或者如果您愿意，也可以使用 XML/SOAP 或任何您想要的格式。以 JSON 作为传输格式的 REST API 可能是目前最流行的。考虑 Web 应用程序的一种方式是，它只是一种从客户端发送和接收数据的方式。如果客户端是 Web 浏览器，您可以将内容作为 HTML 页面提供，或者如果您的客户端是移动应用程序，您可以将数据作为 JSON 提供，并让客户端根据需要显示它。基本上，您的网络应用程序既可以是您的网站 (HTML)，也可以是非网络浏览器客户端的“API”。
您可以将工作角色想象成类似于 Windows 服务。它们主要用于进行后端处理等。工作者角色可能会提供一些能力来托管面向公众的 API，但您必须自己管理连接、消息管道、回收以及所有这些；而 Web 角色将提供一个 Web 服务器 (IIS) 来管理连接等。如果您要引入消息队列之类的东西，则将面向公众的 API 设置为 Web 角色是有意义的，并且消息处理组件一个工作者角色。 Web 应用程序可以通过 REST JSON API 接收来自客户端的消息，然后将消息传递到队列，由工作人员角色接收。如果您拥有可以在后台处理而不会影响客户端的重型服务器端业务逻辑，那么引入队列和辅助角色就很有意义。
【讨论】：