在单个 Azure 云服务上部署多个 Web 角色和辅助角色答案

【问题标题】：Deploying Multiple Web Roles and Worker Roles on a Single Azure Cloud Service在单个 Azure 云服务上部署多个 Web 角色和辅助角色
【发布时间】：2013-03-14 21:21:54
【问题描述】：

这可能并不新鲜，但我希望有人能让我走上正轨，因为它在 azure 部署期间有点混乱。我正在计划在 Azure 上进行部署。这就是我所拥有的

面向公众的 ASP.Net MVC 应用程序（web-role）+ WCF 服务（web-role）只能对此 asp.net 应用程序 + WCF 服务（worker-role）访问 1. over message-排队
自定义 STS 即 ASP.NET MVC 应用程序（Web 角色）充当 Id-Provider（用于 1. 它是一个依赖方）+ WCF 服务（Web 角色）向 RP 公开一些 STS 功能，例如1.
SQL Azure：由 1 和 2 访问注意：1. 最终将成长为一个门户，在 Web 上托管多个 wcf 服务，并为内部和外部访问提供辅助角色。

我的问题是，如果 1. 将成为公开的应用程序，而 2. 是为了 1. 联合安全性（内部），我应该如何规划我在 azure 上的部署，记住 1. 需要规模- 稍后与两个 wcf 服务一起退出？我是发布到一个云服务还是如何发布？我的理解是，云服务是 n-web/worker 角色的逻辑容器。但是当你有 2 个 web 鞋底时，比如在这种情况下，两个 asp.net 应用程序，哪一个成为默认的？

最好的问候萨蒂什

【问题讨论】：

标签： asp.net deployment azure azure-web-roles azure-worker-roles

【解决方案1】：

默认情况下，解决方案中的所有 Web 角色都是公开的。如果愿意，您可以通过进入服务定义并删除 HTTP 端点来更改此设置；您还可以定义仅对云服务可用的内部 HTTP 端点，不会向负载均衡器公开任何内容。在同一个项目中拥有所有 Web 角色的优势在于可以轻松地动态检查 RoleEnvironment 和每个 Web 角色——换句话说，解决方案中的所有角色都“了解”其他角色及其可用端口。部署一个包也很容易。

所有角色共享相同的 DNS 名称 (.cloudapp.net)（但是您可以使用主机标头来区分），但它们通常通过 .cloudapp.net 服务上的负载平衡器使用不同的端口来公开。当服务在云中运行时，您可以看到这一点，门户中的链接指向具有指定端口的公共 HTTP 端点的每个角色。端口 80（由外部 HTTP 端点定义）是“默认”站点。

您还可以创建多个云项目，并分别部署它们。在这种情况下，每个都有自己的 DNS 名称，并且每个都单独管理。这是否是一件好事取决于应用程序的紧密耦合程度，以及您是否通常会部署整个解决方案，或者只是更新该解决方案中的各个角色。但没有成本或可扩展性差异。

如果您只打算频繁地重新部署其中一个角色，我倾向于将它们分开。

【讨论】：

谢谢布赖恩。我的 STS-WebApp 将面向内部，这意味着回答来自 RP Web 或 wcf 应用程序（被动/主动联合）的请求，所以我可以将它托管在 80 以外的任何端口上。我并不担心它必须分别向外扩展。将处于负载之下的是 RP 网络。在这种情况下，SSL 证书的含义是什么？

【解决方案2】：

要在同一个云实例下部署多个 Web 角色，请查看以下内容： Best practice for Deployment of Web site into a cloud service

实现多个工作角色会比较棘手： Run multiple WorkerRoles per instance

【讨论】：