Azure - динамически обнаружение URL веб-роли службы на этапе

Question

Я планирую перенести существующее приложение в Azure. Он будет иметь приложение MVC в одной веб-роли и несколько служб WCF в другой веб-роли. Когда он активен, сайт будет жить на http://www.myapp.com, а сервисы будут на http://api.myapp.com, а приложение MVC настроено на указание сервисов на http://api.myapp.com.

.

Проблема заключается в том, что приложение переводится в «стадию» в Azure. Насколько я понимаю, каждый переход к этапу заставит сервисы жить по новому URL (что-то случайное, например http://4aa5ae2071324585ba5a902f4242a98c.cloudapp.net/). В таком случае, каков наилучший способ для моего приложения MVC определить URL-адрес служб?

Один из вариантов - настроить запись DNS, такую ​​как http://stage.api.myapp.com, и обновлять мою запись DNS CNAME, чтобы она указывала на новый промежуточный URL-адрес Azure каждый раз, когда я нажимаю на сцену, но ... хм.

Другим вариантом может быть переход на этап, получение новых URL-адресов для служб, RDC для каждого экземпляра роли MVC и ручное обновление конфигураций. Также гадость.

Есть ли простой способ сделать это? Я знаю, что мог бы автоматизировать некоторые из вышеперечисленных шагов с помощью чего-то вроде PowerShell, но я очень надеюсь, что в инфраструктуру Azure что-то встроено, что облегчает это. Кажется, это был бы такой стандартный сценарий.

Answer 1

Единственный способ динамически определить, каким будет промежуточный URL-адрес, - это проверить экземпляр на свой собственный deployID. Я предполагаю, что веб-сайт MVC и служба WCF находятся в одном и том же развертывании. Если вы проверите RoleEnvironment.DeploymentID, вы обнаружите, что это точно соответствует «случайному» URL-адресу, используемому при подготовке (т. Е. http://[deploymentID].cloudapp.net).

Пока вы динамически создаете ChannelFactory на стороне клиента, он должен иметь возможность использовать собственный DeploymentID и найти промежуточный URL.

Конечно, это полезно только при развертывании в стадии подготовки. Почему бы вам просто не использовать слот Production? Это имя является стабильным, и вы можете положиться на него или на CNAME (более вероятно), которое вы для него установили. Вы всегда можете иметь несколько размещенных сервисов (dev, QA, prod и т. Д.) И просто использовать рабочий слот на них.

Answer 2

Не делай того, что предлагает @dunnry!У Azure действительно хорошая концепция конечных точек, которые решают вашу проблему.И у вас есть доступ к этой информации из вашего класса RoleEnvironment.

Вы можете посмотреть в моем блоге на как получить конечную точку от клиента. Ключевая часть заключается в созданиивнутренняя конечная точка, на которой слушает ваша служба WCF.Имейте в виду, однако, что вам не обязательно нужна новая роль для этого, и лично я предпочел бы разместить ее в IIS вместе с исходной веб-ролью и иметь две из этих ролей для повышения надежности.

Таким образомне имеет значения, что такое развертывание, потому что обмен данными между службами будет происходить внутри этого развертывания, будь то подготовка или производство.