6

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

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

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

最好的问候萨蒂什

4

2 回答 2

5

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

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

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

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

于 2013-03-25T17:20:58.437 回答
1

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

多个工作角色将更难以实现： 每个实例运行多个 WorkerRoles

于 2013-03-25T17:13:52.833 回答