Рекомендации по размещению в службах IIS

Статья
02/28/2011

В этом разделе даются некоторые рекомендации по размещению служб Windows Communication Foundation (WCF).

Реализация служб WCF в виде библиотек DLL

Реализация службы WCF в виде библиотеки DLL, развернутой в каталог \bin веб-приложения, позволяет многократно использовать службу вне модели веб-приложения, например в тестовой среде, где развертывание IIS невозможно.

Основные приложения служб в приложениях, размещенных в IIS

Не используйте императивные резидентные интерфейсы API для создания новых основных приложений служб, которые ожидают передачи данных различного сетевого транспорта, изначально не поддерживаемого средой размещения IIS (например, IIS 6,0 для размещения служб TCP, поскольку связь по протоколу TCP изначально не поддерживается в IIS 6,0). Такой подход не рекомендуется. Основные приложения служб, созданные принудительно, в среде размещения IIS неизвестны. Ключевым пунктом является то, что обработка, выполненная принудительно созданными службами, не принимается во внимание системой IIS, когда она определяет, простаивает ли пул ведущих приложений. В результате приложения, где есть такие принудительно созданные основные приложения служб, имеют среду размещения IIS, которая агрессивно удаляет ведущие процессы IIS.

Универсальные коды ресурсов (URI) и размещенные в IIS конечные точки

Конечные точки для службы, размещенной в IIS, должны быть настроены с использованием относительных универсальных кодов ресурсов (URI), а не абсолютных адресов. При этом гарантируется попадание адреса конечной точки в ряд адресов URI, принадлежащих ведущему приложению, и обеспечивается надлежащая активация на основе сообщений.

Управление состоянием и перезапуск процессов

Среда размещения IIS оптимизирована для служб, не поддерживающих локальное состояние в памяти. При появлении множества внешних и внутренних событий система IIS перезапускает ведущий процесс, в результате чего любое непостоянное состояние, сохраненное только в памяти, теряется. Службы, размещенные в IIS, должны сохранять свое состояние во внешней по отношению к процессу среде (например, в базе данных) или в расположенном в памяти кэше, который в случае перезапуска приложения может быть легко восстановлен.

Примечание
Протоколы, применяемые системой WCF для обеспечения надежности и безопасности на уровне сообщений, используют непостоянное состояние в памяти. Надежные сеансы и сеансы безопасности WCF могут неожиданно завершаться из-за перезапусков приложений. Приложения, размещенные в IIS, которые используют эти протоколы, должны либо зависеть от чего-то отличного от предоставленного системой WCF ключа сеанса для корреляции состояния прикладного уровня (например, структуры прикладного уровня или пользовательского заголовка корреляции), либо запрещать перезапуск процессов IIS для размещенного приложения.

Протоколы, применяемые системой WCF для обеспечения надежности и безопасности на уровне сообщений, используют непостоянное состояние в памяти. Надежные сеансы и сеансы безопасности WCF могут неожиданно завершаться из-за перезапусков приложений. Приложения, размещенные в IIS, которые используют эти протоколы, должны либо зависеть от чего-то отличного от предоставленного системой WCF ключа сеанса для корреляции состояния прикладного уровня (например, структуры прикладного уровня или пользовательского заголовка корреляции), либо запрещать перезапуск процессов IIS для размещенного приложения.

Оптимизация производительности в сценариях среднего уровня

Для оптимальной производительности в сценариях среднего уровня (служба, которая вызывает другие службы в ответ на входящие сообщения) создайте один раз экземпляр клиента службы WCF для удаленной службы и используйте его многократно при различных входящих запросах. Создание экземпляров клиентов службы WCF — дорогостоящая операция по сравнению с созданием вызова службы в уже существующем экземпляре клиента, и сценарии среднего уровня обеспечивают явно выраженное увеличение производительности благодаря кэшированию удаленных клиентов при разных запросах. Клиенты службы WCF являются потокобезопасными, поэтому не требуется синхронизировать доступ к клиенту через несколько потоков.

Увеличение производительности в сценариях среднего уровня обеспечивается также благодаря использованию асинхронных интерфейсов API, создаваемых параметром svcutil /a. Параметр /a заставляет программу Служебное средство ServiceModel Metadata Utility Tool (Svcutil.exe) создавать методы BeginXXX/EndXXX для каждой операции службы, что позволяет создавать потенциально долго действующие вызовы удаленных служб в фоновых потоках.

WCF в многосетевых сценариях и сценариях со многими именами

Службы WCF можно развернуть внутри веб-фермы IIS, где ряд компьютеров совместно используют общее внешнее имя (например, https://www.contoso.com), но обращение к ним осуществляется с указанием разных имен узлов (например, компьютер с именем https://www.contoso.com может направлять трафик на два разных компьютера с именами http://machine1.internal.contoso.com и http://machine2.internal.contoso.com). Такой сценарий развертывания полностью поддерживается системой WCF, но для отображения надлежащего (внешнего) имени узла в метаданных службы (языке WSDL) требуется специальная конфигурация веб-узла IIS, где размещаются службы WCF.

Чтобы обеспечить появление правильного имени узла в метаданных службы, создаваемых системой WCF, настройте идентификацию по умолчанию для веб-узла IIS, в котором размещаются службы WCF, на использование явно заданного имени узла. Например, компьютеры, расположенные в ферме www.contoso.com, должны использовать привязку узла IIS *:80:www.contoso.com для HTTP и *:443:www.contoso.com для HTTPS.

Привязки веб-узла IIS можно настроить с помощью оснастки консоли управления (MMC) IIS.

Пулы приложений, работающие в разных контекстах пользователей, которые перезаписывают сборки из других учетных записей во временной папке

Чтобы пулы приложений, работающие в разных контекстах пользователей, не могли перезаписывать сборки из других учетных записей в папке временных файлов ASP.NET, используйте для разных приложений разные идентификаторы и временные папки. Например, если имеется два виртуальных приложения /Application1 и / Application2, можно создать два пула приложений (A и B) с двумя разными идентификаторами. Пул приложений A может работать под одним идентификатором пользователя (user1), а пул приложений B — под другим идентификатором пользователя (user2). Настройте приложение /Application1 на использование пула A, а приложение /Application2 — на использование пула B.

В файле Web.config можно настроить временную папку, используя <system.web/compilation/@tempFolder>. Для приложения /Application1 это может быть папка «c:\tempForUser1», а для приложения application2 — папка «c:\tempForUser2». Предоставьте соответствующее разрешение на запись в эти папки для двух идентификаторов.

В этом случае пользователь user2 не может изменить папку создания кода для приложения /application2 (в папке c:\tempForUser1).

Включение асинхронной обработки

По умолчанию сообщения, отправляемые в службу WCF, которая размещается в службах IIS 6.0 и более ранних версий, обрабатываются в синхронном режиме. ASP.NET вызывает WCF в собственном потоке (рабочий поток ASP.NET), а WCF использует для обработки запроса другой поток. WCF удерживает рабочий поток ASP.NET до завершения обработки. В результате обработка запросов выполняется синхронно. Асинхронная обработка запросов расширяет возможности масштабирования, поскольку в этом случае сокращается число потоков, необходимое для обработки запроса, — WCF не удерживает поток ASP.NET в течение обработки запроса. Асинхронный режим не рекомендуется для компьютеров со службами IIS 6.0, поскольку в этой версии отсутствует возможность регулирования входящих запросов и сервер становится уязвимым к атакам типа Отказ в обслуживании. Начиная с версии IIS 7.0, реализовано регулирование параллельных запросов: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]“MaxConcurrentRequestsPerCpu. Новая система регулирования гарантирует безопасность использования асинхронной обработки. По умолчанию в IIS 7.0 регистрируются асинхронные обработчик и модуль. Если эта функция выключена, то можно вручную включить асинхронную обработку запросов в файле Web.config приложения. Используемые параметры зависят от параметра aspNetCompatibilityEnabled. Если параметр aspNetCompatibilityEnabled установлен в значение false, настройте модуль ServiceHttpModule, как показано в следующем фрагменте конфигурации.

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="false" />    
  </system.serviceModel>
  <system.webServer>
    <modules>
      <remove name="ServiceModel"/>
      <add name="ServiceModel" 
           preCondition="integratedMode,runtimeVersionv2.0" 
           type="System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel,Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
    </modules>
    </system.webServer>

Если параметр aspNetCompatibilityEnabled установлен в значение true, настройте модуль ServiceHttpHandlerFactory, как показано в следующем фрагменте конфигурации.

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />    
  </system.serviceModel>
  <system.webServer>
    <handlers>
          <clear/>
          <add name="TestAsyncHttpHandler" 
               path="*.svc" 
               verb="*" 
               type="System.ServiceModel.Activation.ServiceHttpHandlerFactory, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"         
               />
    </handlers>    
  </system.webServer>

См. также

Другие ресурсы

Service Hosting Samples
Функции размещения Windows Server App Fabric

Поделиться через