Мысли о запуске приложений типа службы Windows в ASP .NET 4 с StartMode = "AlwaysRunning" - PullRequest
17 голосов
/ 14 сентября 2010

Обычно я смотрю на написание службы Windows для управления задачами, которые не подходят для размещения в веб-приложении. Эти типы задач обычно являются длительными процессами или запланированными задачами. Хотя обычно это основной подход к задачам такого типа, people рассмотрели способы запуска подобных типов фоновых процессов в веб-приложении, запустив несколько потоков в событии Application_Start, предоставляемом Global. asax. Проблема с этим подходом всегда заключалась в том, что если ваш рабочий процесс IIS умирает, то ваш фоновый поток также уничтожается (фактически ваша «служба Windows» останавливается до получения следующего запроса).

ASP .NET 4.0 предлагает решение этой проблемы. Теперь вы можете установить StartMode на AlwaysRunning, как описано в этом сообщении в блоге Скотта Гу. Где-то в комментариях к этому сообщению кто-то задает вопрос о жизнеспособности размещения задач типа службы Windows в IIS, поскольку новая функция обеспечивает постоянную работу рабочего процесса. Скотт отметил, что это определенно поддержит сценарий. В дополнение к этому, недавнее появление AppFabric означает, что сами Microsoft предоставляют простые перехватчики для размещения и мониторинга служб WCF и WF в веб-приложении.

Что это значит для тех из нас, кто писал Windows Services для поддержки наших веб-приложений? Должны ли мы принять эту модель? Какие подводные камни? Насколько я могу судить, хостинг процессов «Служба Windows» в веб-приложении имеет ряд преимуществ, наиболее полезными из которых являются простота развертывания. Более того, мы можем начать разработку простых пользовательских интерфейсов для наших сервисов, которые предоставляют информацию о том, что происходит во время выполнения.

Если бы мне пришлось пойти по этому пути, я не думаю, что разместил бы свою функциональность типа «Служба Windows» в клиентском веб-приложении. Я бы, вероятно, разработал новый проект веб-приложения (так же, как в контексте службы Windows), в котором будут размещаться мои долго выполняющиеся / запланированные процессы задач. Я думаю, есть несколько причин для этого.

  1. Безопасность . Может быть другая модель безопасности для интерфейса пользователя, отображающего информацию о запущенных фоновых процессах. Я бы не хотел показывать этот интерфейс кому-либо еще, кроме команды ops. Кроме того, веб-приложение может работать от имени другого пользователя с повышенными правами доступа.
  2. Техническое обслуживание . Было бы замечательно иметь возможность развертывать изменения в приложении, размещающем фоновые процессы, не влияя на использование пользователем интерфейсного веб-сайта.
  3. Производительность . Отделение приложения от основного пользовательского сайта, обрабатывающего пользовательские запросы, означает, что фоновые потоки не уменьшат способность IIS обрабатывать очередь входящих запросов. Кроме того, приложение, обрабатывающее фоновые задачи, может быть развернуто на отдельном сервере, если требуется.

Мне было бы очень интересно услышать ваши мысли об этом подходе и о том, стоит ли мне придерживаться служб Windows. Мне очень хочется попробовать этот новый подход.

Ответы [ 3 ]

5 голосов
/ 16 сентября 2010

Что это значит для тех из нас, кто писал Windows Services для поддержки наших веб-приложений?

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

Должны ли мы принять эту модель?

Стандартный ответ на разработку: Зависит;)

Какие подводные камни?

Одна проблема, которую я вижу, это зависимость IIS. Если вам нужен сервис для запуска на компьютере пользователя, я не буду чувствовать, что ему будет предложено установить IIS только для запуска моего сервиса. Здесь я думаю, что традиционная модель работает лучше.

Мониторинг и отслеживание являются основными проблемами, но, как вы также заметили, это решается AppFabric. Это даже лучше, чем то, что вы получаете от службы Windows. Однако вы добавили еще одну зависимость, которая также потребует .NET 4.0 и относительно новую версию Windows. Я также могу ошибаться, но, насколько я понимаю, AppFabric не поддерживается в производственных системах на клиентских ОС. Что может привести к дополнительным головным болям.

Вы также потеряете функциональность паузы в модели непрерывного веб-сайта.

Наконец, IIS уничтожает неактивные пулы приложений - не единственный способ перезапуска пула приложений. Например, редактирование файла web.config вызывает его, что может не быть идеальной ситуацией.

Самым полезным является простота развертывания.

Я также думаю, что разработка намного проще - в прошлом у меня было консольное приложение и служба Windows, поэтому я мог разрабатывать / тестировать на своем компьютере с помощью приложения консоли, а затем менять его на службу Windows, когда она отключалась. Теперь dev / test НАМНОГО проще.

Обязательно прочитайте: Смерть службам Windows ... Long Live AppFabric!

3 голосов
/ 20 сентября 2010

Какие подводные камни?

Один, который я обнаружил, не был завершен.У вас есть AppStart при запуске веб-сайта (не global.asax, потому что это только HTTP), но у вас нет способа справиться с выключением, что может означать, что удаление становится проблемой.

1 голос
/ 14 сентября 2010

Я бы предложил придерживаться службы Windows. Проблема с вашим номером 2. Вы не сможете обновить служебную часть веб-сайта, не перезапустив весь веб-сайт.

...