Я начинаю создавать архитектуру нового проекта с использованием 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-адрес виртуального сервера). Есть обходные пути, но, поскольку вас еще нет, я просто хотел сообщить вам об этом, а не пугать вас.
РЕДАКТИРОВАТЬ: я собирался подробнее рассказать о том, как обращаться с метаданными в сценарии 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.