这可能不是什么新鲜事，但我希望有人可以让我走上正轨，因为它在天蓝色部署期间有点混乱 . 我正在计划在Azure上进行部署 . 这就是我所拥有的
-
面向公众的ASP.Net MVC应用程序（web-role）WCF服务（web-role）只能访问此asp.net应用程序WCF服务（worker-role）再次可通过消息队列访问
-
自定义STS，即作为Id-Provider的ASP.NET MVC应用程序（web-role）（用于1.依赖方）WCF服务（web-role）将一些STS功能暴露给RP，例如1 .
-
SQL Azure：由1和2访问注意：1 . 最终将成为一个门户网站，在Web和工作者角色上托管多个wcf服务，以进行内部和外部访问 .
我的问题是，如果1.是暴露给公众的应用程序，而2.是1.为联邦安全（内部），我应该如何计划我的部署在azure记住1.将需要横向扩展有时后来跟两个wcf服务一起？我是否发布到一个 Cloud 服务或如何？我的理解是， Cloud 服务是n-web / worker角色的逻辑容器 . 但是，如果你有2个网页鞋底，就像在这种情况下两个asp.net应用程序，哪一个成为默认的？
最好的问候萨蒂什
2 回答
默认情况下，解决方案中的所有Web角色都是公共的如果您愿意，可以通过进入服务定义并删除HTTP endpoints 来更改此设置;您还可以定义仅对 Cloud 服务可用的内部HTTP endpoints ，不会向负载均衡器公开任何内容 . 在同一个项目中拥有所有Web角色的优势在于，可以轻松动态检查RoleEnvironment和每个Web角色 - 换句话说，解决方案中的所有角色都“了解”其他角色及其可用端口 . 部署一个包也很容易 .
所有角色共享相同的DNS名称（.cloudapp.net）（但您可以使用主机标头进行区分），但通常通过.cloudapp.net服务上的负载 balancer 器使用不同的端口公开它们 . 当服务在 Cloud 中运行时，您可以看到这一点，门户中有链接指向具有指定端口的公共HTTP endpoints 的每个角色 . 端口80（由外部HTTP endpoints 定义）是“默认”站点 .
您还可以创建多个 Cloud 项目，并单独部署它们 . 在这种情况下，每个都有自己的DNS名称，每个都是单独管理的 . 这是否是一件好事取决于应用程序的紧密耦合程度，以及您是否通常部署整个解决方案，或者仅更新该解决方案中的各个角色 . 但是没有成本或可扩展性差异 .
如果你经常只重新部署其中一个角色，我会赞成将它们分解出去 .
要在同一个 Cloud 实例下部署多个Web角色，请查看：Best practice for Deployment of Web site into a cloud service
实施多个辅助角色将更加棘手：Run multiple WorkerRoles per instance