Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Одним из способов увеличения емкости приложений Windows Communication Foundation (WCF) является развертывание их в ферме серверов с балансировкой нагрузки. Приложения WCF можно сбалансировать с помощью стандартных методов балансировки нагрузки, включая программные подсистемы балансировки нагрузки, такие как балансировка сетевой нагрузки Windows, а также аппаратные устройства балансировки нагрузки.
В следующих разделах рассматриваются рекомендации по балансировке нагрузки приложений WCF, созданных с использованием различных системных привязок.
Балансировка нагрузки с помощью базовой привязки HTTP
С точки зрения балансировки нагрузки приложения WCF, взаимодействующие с использованием BasicHttpBinding , не отличаются от других распространенных типов сетевого трафика HTTP (статического HTML-содержимого, ASP.NET страниц или веб-служб ASMX). Каналы WCF, использующие эту привязку, по сути, являются бессерверными и завершают свои подключения при закрытии канала. Таким образом, BasicHttpBinding хорошо работает с существующими методами балансировки нагрузки HTTP.
По умолчанию BasicHttpBinding отправляет заголовок подключения HTTP в сообщениях, которые содержат значение Keep-Alive, что позволяет клиентам устанавливать постоянные подключения к службам, их поддерживающим. Эта конфигурация обеспечивает расширенную пропускную способность, так как ранее установленные подключения можно повторно использовать для отправки последующих сообщений на тот же сервер. Однако повторное использование подключения может привести к тому, что клиенты станут слишком сильно ассоциированы с определенным сервером в серверном кластере с балансировкой нагрузки, что уменьшает эффективность циклического распределения нагрузки. Если это поведение нежелательно, HTTP Keep-Alive можно отключить на сервере с помощью свойства KeepAliveEnabled с CustomBinding, определяемым пользователем, или пользовательским определением Binding. В следующем примере показано, как это сделать с помощью конфигурации.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service
name="Microsoft.ServiceModel.Samples.CalculatorService"
behaviorConfiguration="CalculatorServiceBehavior">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8000/servicemodelsamples/service"/>
</baseAddresses>
</host>
<!-- configure http endpoint, use base address provided by host
And the customBinding -->
<endpoint address=""
binding="customBinding"
bindingConfiguration="HttpBinding"
contract="Microsoft.ServiceModel.Samples.ICalculator" />
</service>
</services>
<bindings>
<customBinding>
<!-- Configure a CustomBinding that disables keepAliveEnabled-->
<binding name="HttpBinding" keepAliveEnabled="False"/>
</customBinding>
</bindings>
</system.serviceModel>
</configuration>
Используя упрощенную конфигурацию, представленную в .NET Framework 4, можно выполнить то же поведение с помощью следующей упрощенной конфигурации.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<protocolMapping>
<add scheme="http" binding="customBinding" />
</protocolMapping>
<bindings>
<customBinding>
<!-- Configure a CustomBinding that disables keepAliveEnabled-->
<binding keepAliveEnabled="False"/>
</customBinding>
</bindings>
</system.serviceModel>
</configuration>
Дополнительные сведения о конечных точках, привязках и поведении по умолчанию см. в статье "Упрощенная конфигурация " и "Упрощенная конфигурация" для служб WCF.
Балансировка нагрузки с использованием привязки WSHttp и привязки WSDualHttp
Как WSHttpBinding, так и WSDualHttpBinding могут быть сбалансированы по нагрузке с помощью методов балансировки нагрузки HTTP, если в конфигурацию привязки по умолчанию внесены несколько изменений.
Отключите создание контекста безопасности или используйте сеансы с отслеживанием состояния безопасности. Создание контекста безопасности можно отключить, установив свойство EstablishSecurityContext на WSHttpBinding
false. Если вы используете WSDualHttpBinding или требуются сеансы безопасности, можно использовать сеансы безопасности с отслеживанием состояния, как описано в разделе «Безопасные сеансы». Сеансы безопасности с сохранением состояния позволяют службе оставаться без сохранения состояния, так как все состояние сеанса безопасности передается с каждым запросом в рамках токена безопасности. Чтобы включить сеанс безопасности с отслеживанием, необходимо использовать CustomBinding или параметр, определенный пользователем Binding, поскольку необходимые параметры конфигурации не предоставляются в системных WSHttpBinding и WSDualHttpBinding.Если вы отключите создание контекста безопасности, необходимо также отключить согласование учетных данных службы. Чтобы отключить, установите свойство NegotiateServiceCredential на WSHttpBinding значение
false. Чтобы отключить согласование учетных данных службы, может потребоваться явно указать удостоверение конечной точки на стороне клиента.Не используйте надежные сеансы. Эта возможность отключена по умолчанию.
Балансировка нагрузки биндинга Net.TCP
NetTcpBinding можно сбалансировать по нагрузке, используя методы балансировки нагрузки на уровне IP. NetTcpBinding Однако пулы TCP-подключений по умолчанию снижают задержку подключения. Это оптимизация, которая мешает базовому механизму балансировки нагрузки. Основной параметр конфигурации для оптимизации NetTcpBinding — тайм-аут аренды, который входит в состав параметров пула подключений. Пул подключений приводит к тому, что клиентские подключения будут связаны с определенными серверами в ферме. По мере увеличения времени существования этих подключений (фактор, контролируемый параметром времени ожидания аренды), распределение нагрузки между различными серверами в ферме становится несбалансировано. В результате среднее время вызова увеличивается. Поэтому в сценариях с балансировкой нагрузки при использовании NetTcpBinding рекомендуется сократить время жизни аренды по умолчанию, используемое привязкой. 30-секундное время ожидания аренды является разумной отправной точкой для сценариев балансировки нагрузки, хотя оптимальное значение зависит от приложения. Дополнительные сведения о времени ожидания аренды канала и других квотах транспорта см. в разделе " Квоты транспорта".
Для повышения производительности в сценариях балансировки нагрузки рекомендуется использовать NetTcpSecurity ( Transport или TransportWithMessageCredential).