Хостинг WCF для среднего уровня

Мы разрабатываем новый средний уровень для нашего пакета приложений. Мы хотим переписать нашу бизнес-логику и уровни доступа к данным на C #, поскольку они в настоящее время находятся в VB6 и публикуются через COM +.

Мы пытаемся решить, как именно сделать этот средний уровень доступным для разных клиентов. Для этого мы будем использовать WCF, и мы решили, что будем использовать различные привязки, чтобы удовлетворить потребности каждого клиента, включая netTcpBinding для нашего настольного приложения, net.Tcp и / или именованный канал. привязка для интернет-приложения, работающего либо локально, либо на компьютере в сети, а также некоторая разновидность привязки HTTP для внешнего веб-API.

Мы пытаемся решить, как разместить нашу службу. Кажется, что большинство мест, где я иду, говорят, что IIS - это путь, но похоже, что вы бы получили лучшую производительность из его части BLL / DAL, если бы она находилась в службе Windows, и @marc_s здесь, на SO, кажется чаще рекомендовать самостоятельный хостинг. Итак, размещаем ли мы его под IIS, под сервисом или каким-то гибридом, где, возможно, тонкий сервис размещается в IIS для конечной точки HTTP и использует основную службу через привязку net.tcp или именованный канал? Разделение позволяет при желании обеспечить физическое разделение, а также допускает возможность выхода из строя IIS, в результате чего служба по-прежнему будет работать для тех клиентов, которые обращаются к публикуемым конечным точкам.

А как насчет масштабируемости и надежности? Есть ли большая разница между этими двумя хостинговыми средами?

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


person Zann Anderson    schedule 15.03.2011    source источник
comment
Вы уже упомянули мои предпочтения, которые я могу только повторить: на мой взгляд, любой достойный производственный сервис WCF должен размещаться на собственном хостинге. IIS и даже WAS в IIS 7 / 7.5 на самом деле не являются средой размещения служб - слишком много других факторов, которые причиняют больше вреда, чем пользы. Служба NT дает вам полный контроль над протоколом и URL-адресами.   -  person marc_s    schedule 16.03.2011


Ответы (1)


Читая этот ответ, можно предположить, что самостоятельный хостинг - это предпочтение marc_s, основанное на принятии накладных расходов при кодировании хоста самостоятельно:

Хостинг службы IIS WCF против службы Windows

IIS предоставляет вам множество возможностей бесплатно. Я бы сказал, что заранее обдумать это - неплохая идея, но нет ничего лучше, чем измерение показателей производительности, чтобы получить холодные, неопровержимые факты о том, что лучше всего для вашего решения.

Попробуйте IIS и, если он действительно такой плохой, создайте свой собственный хост. Запустить это в IIS не так уж и дорого - и в Интернете есть несколько советов по настройке.

Обновление: опубликовал это сразу после того, как marc_s оставил комментарий. В принципе, я согласен, но выполнение хостинга самостоятельно может оказаться непосильным занятием. IIS в некоторой степени нестандартен и имеет свои ограничения - ограничения, с которыми вы, возможно, никогда не столкнетесь.

Я не уверен в актуальности этой обратной связи, но мы используем IIS для размещения объектов .NET Remoting для нашего приложения. В настоящее время он проходит довольно значительный процесс сбора показателей производительности в рамках подготовки к увеличению масштабирования почти в 10 раз из-за нового клиента. Для нас IIS не считается чем-то, о чем стоит беспокоиться. Единственная проблема, с которой сталкиваются люди, - это то, что он работает через HTTP (для нас более старая версия IIS), поэтому, возможно, он немного больше загружает сообщениями, чем TCP.

Обновление: в этой статье MSDN рассматривается самостоятельный хостинг и обсуждаются некоторые моменты, которые следует учитывать:

http://msdn.microsoft.com/en-us/library/bb332338.aspx#msdnwcfhc_topic3

person Adam Houldsworth    schedule 15.03.2011
comment
Я согласен, что IIS и особенно WAS в IIS 7.5 имеют свои преимущества; тем не менее, я все равно буду утверждать, что а) преимущества самостоятельного хостинга значительны (даже если вы просто можете полностью определить свои URL-адреса, а не использовать искусственную схему вроде с IIS / WAS и его виртуальными каталогами), и б) усилия, необходимые для самостоятельного хостинга, действительно совсем несложны! Несколько строк простого кода C # в службе NT (для которой у вас есть шаблон VS), и все готово! - person marc_s; 16.03.2011
comment
Самостоятельный хостинг @marc_s определенно можно запустить за 15 минут работы консоли, но такое базовое требование, как масштабируемость, не «просто» учитывать при самостоятельном кодировании хоста. Это компромисс. OP спрашивает о различиях в надежности и масштабируемости - это полностью зависит от ваших усилий при кодировании хоста. Моя 15-минутная консольная работа не масштабируется и не надежна - те же 15 минут в IIS дают мне это. - person Adam Houldsworth; 16.03.2011
comment
@Adam - если действительно требуется больше работы, чтобы добиться масштабирования с помощью самостоятельного хостинга, что за работа? @marc_s, не могли бы вы рассказать, что требуется для масштабируемости при самостоятельном размещении? Кроме того, какая разница в производительности на самом деле? Это важно? Имеют ли значение накладные расходы, связанные с развертыванием ServiceHost и созданием экземпляра класса обслуживания? А как насчет пропускной способности? Есть ли существенная разница в количестве вызовов, которые можно обработать тем или иным способом? - person Zann Anderson; 16.03.2011
comment
На самом деле не уверен, потому что я думаю, что WCF-хостинг по-прежнему запускает рабочие потоки. Здесь начинается дискуссия о том, достаточно ли одного сервера и т. Д. Для большинства ситуаций, сравнение собственного хоста и IIS - это семантическое обсуждение, как я сделал вывод в своем ответе о том, чтобы сначала попробовать IIS. Для больших объемов полезной нагрузки или интенсивного трафика вам следует побеспокоиться об этом ИМХО. Как упоминает marc_s, self-host дает вам полный контроль, поэтому, когда вы попадаете в ограничение IIS, ваш self-host внезапно выглядит как золотой мальчик. Собираетесь ли вы преодолеть эти ограничения? - person Adam Houldsworth; 16.03.2011
comment
К сожалению, я не знаю WCF с IIS в достаточной степени, чтобы точно сказать, где IIS собирается вас ужалить. Похоже, вам нужно точно знать, что требуется от вашего хоста, а затем сопоставить это с тем, что IIS может предоставить и, как известно, вызывает головные боли. Я все еще поддерживаю свой первый ответ о производительности, не беспокойтесь об этом слишком много, прежде чем вы действительно его измерите. - person Adam Houldsworth; 16.03.2011
comment
@Adam, @marc_s, спасибо за ваш вклад. Я еще немного поищу, где IIS может потерпеть неудачу и столкнемся ли мы с ними. Также спасибо за ссылку на статью MSDN - я ее раньше не видел. - person Zann Anderson; 16.03.2011
comment
О каких ограничениях вы говорите при размещении WCF в IIS 7+? Я использовал как самостоятельно размещенные службы Windows, так и IIS, и могу сказать без сомнения, что предпочитаю IIS в качестве хоста. Управление жизненным циклом процессов, теневые копии dll (обновление на месте), новая функция webdeploy и, возможно, другие. Я могу жить с расширением .svc, однако, если оно слишком беспокоит, тогда используйте модуль перезаписи URL или новые возможности маршрутизации в WCF 4.0, чтобы получить «красивые» адреса. :) - person Zach Bonham; 16.03.2011
comment
@Zach Bonham Я просто имел в виду ограничения как уловку, исходя из предположения, что они не могут делать все :-) Я понятия не имею, что именно они из себя представляют. Это было больше для демонстрации того, что, если вы точно не знаете, что они из себя представляют, вы не можете предполагать, что когда-нибудь столкнетесь с ними. - person Adam Houldsworth; 16.03.2011
comment
@ Адам, я считаю, что у вас есть почти полный контроль, особенно с IIS7 (IIS6 более ограничен, но все же стоит посмотреть). Вы можете создать свою собственную фабрику хоста / хоста, если вам нужно / хотите (например, для лучшей интеграции контейнеров IoC с типами WCF). Лучше всего то, что если вы действительно столкнетесь с препятствием, вы можете вернуться к службе Windows и к тривиальному количеству кода для ее размещения (на самом деле это не так уж и много). как уже упоминалось другими, нацеливайтесь на IIS7 и возвращайтесь к сервису только в случае необходимости. - person Zach Bonham; 16.03.2011
comment
@Zach cool, спасибо за объяснение - другие тоже были бы я :-) - person Adam Houldsworth; 16.03.2011
comment
По сути, беспокойство заключается в том, что до моего прихода в компанию с IIS были серьезные проблемы, включая проблемы как с производительностью, так и с надежностью, поэтому я пытаюсь вникнуть в это с широко открытыми глазами, в каком направлении двигаться. Еще кое-что, я только что прочитал об AppFabric. Кто-нибудь из вас знаком с этим и стоит ли мое время изучить? Одна из вещей, которые он утверждает, - это упрощенное развертывание и управление службами WCF и WF, размещенными в WAS, что является одной из наших проблем ... - person Zann Anderson; 16.03.2011
comment
@Zannjaminderson Я бы поднял еще один вопрос по этому поводу - с большей вероятностью привлечет внимание знающих людей. - person Adam Houldsworth; 16.03.2011