Я запускаю архитектуру нового проекта с помощью WCF, но я не правильный человек для создания некоторых рекомендаций по сети, таким образом, я провожу некоторое исследование, но не могу найти ответы на эти вопросы:
Мы разместим сервис WCF в общем приложении службы Windows в 2 серверах, и у нас будет другой сервер для создания задания Выравнивания нагрузки с помощью WNLB. То, что мы размещаем WCF в приложении службы Windows, может нарушить задание NLB?
Перед моим исследованием я думал, что выравнивание нагрузки было жестко для конфигурирования, но с NLB это, кажется, очень просто, его действительно настолько простой?
Примечание: Привязка будет basicHttpBinding
Я не могу говорить с NLB конкретно о службах WCF с балансировкой нагрузки, но в прошлом я поддерживал и создавал множество веб-служб WCF с балансировкой нагрузки. В целом, я бы не рекомендовал использовать NLB, вне среды Dev, так как NLB плохо масштабируется. Однако, если у вас нет доступа к аппаратному компенсатору нагрузки или желания перейти на Linux (HAProxy/Varnish/Nginx), он может работать.
Так что:
Единственное предостережение, которое я должен сделать, это больше связано с балансировкой нагрузки WCF, нежели с NLB. Если вы планируете использовать SSL со службой WCF, и вы перейдете на балансировщик нагрузки, поддерживающий SSL-выгрузку, вы можете столкнуться с проблемами, когда WSDL недоступен через VIP (IP-адрес виртуального сервера). Существуют обходные пути, но поскольку вас еще нет, я просто хотел, чтобы вы знали об этом, а не пугались.
EDIT: Я собирался подробно рассказать о том, как адресовать метаданные в сценарии SSL-выгрузки, но недавний пост в блоге MSDN обрабатывал его гораздо элегантнее:
http://blogs.msdn.com/b/dsnotes/archive/2014/10/03/ssl-offloading-in-load-balancer-scenario.aspx
Суть в том, что есть два варианта, модифицируя customBinding, чтобы разрешить enableUnsecuredResponse или полностью изменить WSDL, чтобы сделать ее доступной через HTTPS на сервере. Вариант 2 - более эффективный способ справиться с этим, так как он позволит обеспечить лучшую совместимость с не.NET технологиями
.