Развертывание нескольких ролей в Интернете и ролей рабочих на одном облачном сервисе для облачных сервисов

Question

Это может быть не ново, но я надеюсь, что кто-то может поставить меня на правильный путь, поскольку его бит запутывает во время лазурного развертывания. Я планирую развертывание на Azure. Это то, что у меня есть

1. Общественного облицовочный ASP.Net MVC приложение (веб-роль) + служба WCF (веб-роль) будет доступна только для этого приложения asp.net + службы WCF (рабочая-роль) снова доступен для 1. over message-queue
2. Пользовательское STS, то есть приложение ASP.NET MVC (веб-роль), действующее как Id-Provider (для 1., которое является доверяющей стороной) + служба WCF (веб-роль) для выставляют некоторые из функций STS для RP, такие как 1.
3. SQL Azure: доступ к 1 и 2 Примечание: 1. В конечном итоге будет расти портал, содержащий несколько wcf-сервисов, размещенных на веб-страницах и рабочих ролях для внутренних и внешний доступ.

Мой вопрос в том, что 1. будет приложение открыто для общественности, а 2. для 1. для защиты безопасности (внутреннего), как мне планировать развертывание на лазури, имея в виду 1. потребует масштабирования через некоторое время вместе с двумя службами wcf? Опубликовать ли я на одном облачном сервисе или как ?. Я понимаю, что облачная служба является логическим контейнером для ролей n-web/worker. Но когда у вас есть 2 веб-подошвы, как в этом случае, как приложения asp.net, которые становятся стандартными?

С наилучшими пожеланиями Сатиш

Answer 1

Для развертывания нескольких веб-ролей в рамках того же экземпляра облака взглянуть на это: Best practice for Deployment of Web site into a cloud service

Несколько ролей работника будет сложнее реализовать: Run multiple WorkerRoles per instance

Answer 2

По по умолчанию все веб-роли в решении являются общедоступными. Вы можете изменить это, перейдя в определение службы и удалив конечные точки HTTP, если хотите; вы также можете определить внутренние конечные точки HTTP, которые будут доступны только облачным службам, ничто не будет выставлено балансировщику нагрузки. Преимущество наличия всех веб-ролей в одном проекте заключается в том, что легко динамически проверять RoleEnvironment и каждую веб-роль - другими словами, все роли в решении «осведомлены» о других ролях и их доступных портах. Также легко развертывать один пакет.

Все роли имеют одно и то же DNS-имя (.cloudapp.net) (однако вы можете использовать заголовки хостов для разграничения), но они обычно отображаются с использованием разных портов через балансировщик нагрузки в вашем сервисе .cloudapp.net. Вы можете увидеть это, когда служба запущена в облаке. В портале есть ссылки, указывающие на каждую роль, которая имеет общедоступную конечную точку HTTP, которая указывает порт. Тот, который является портом 80 (как определено внешней конечной точкой HTTP), является сайтом «по умолчанию».

Вы также можете создать несколько облачных проектов и развернуть их отдельно. В этом случае у каждого будет свое собственное DNS-имя, и каждый из них будет управляться отдельно. Независимо от того, хорошо это или нет, зависит от того, насколько жестко связаны приложения, и если вы обычно будете развертывать все решение или просто обновлять отдельные роли в этом решении. Но нет никакой разницы в стоимости или масштабируемости.

Если вы собираетесь часто передислоцировать только одну из ролей, я бы предпочел разбить их.