asp.net - 在单个 Azure 云服务上部署多个 Web 角色和辅助角色

Question

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

1. 面向公众的 ASP.Net MVC 应用程序(网络角色)+ WCF 服务(网络角色)仅可由该 ASP.NET 应用程序访问 + WCF 服务(工作角色)再次可供 1. 通过消息访问-队列
2. 自定义 STS，即 ASP.NET MVC 应用程序(网络角色)充当 Id 提供者(对于 1. 作为依赖方)+ WCF 服务(网络角色)，以向 RP 公开一些 STS 功能，例如1.
3. SQL Azure:由 1 和 2 访问 注意:1. 最终将发展成为一个门户，在 Web 上托管多个 WCF 服务，并提供内部和外部访问的辅助角色。

我的问题是，如果 1. 将成为向公众公开的应用程序，并且 2. 用于 1. 联合安全性(内部)，我应该如何规划在 azure 上的部署，同时牢记 1. 将需要规模- 稍后与两个 wcf 服务一起输出？我应该发布到一个云服务还是如何发布？ 我的理解是，云服务是 n-web/worker 角色的逻辑容器。 但是，当您有 2 个 Web 鞋底(例如本例中的两个 ASP.NET 应用程序)时，哪一个将成为默认鞋底？

致以诚挚的问候 萨蒂什

Answer 1

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

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

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

如果您只打算经常重新部署其中一个角色，我倾向于将它们分解。