Самостоятельный хостинг WCF, хостинг через консольное приложение

Question

Я видел примеры, примеры кодов и т. Д. Для самостоятельного размещения служб WCF в консольном приложении, службе Windows и т. Д.

Мой вопрос: как это будет работать в производстве? Будет ли это эффективно? Будет ли это масштабироваться?

Я не уверен, как это будет работать, поэтому другой вопрос, будет ли это однопоточным? многопоточный? мне нужно управлять многопоточностью? AppDomains

Я предпочитаю хостинг с командной строкой, службой Windows по причинам, связанным с приложением.

Answer 1

Будет ли это эффективно?

Это зависит от реализации службы, от максимального количества запросов, которыми она может управлять в течение определенного периода времени. Эффективность является относительной мерой: давайте предположим, что ваш сервис способен обрабатывать 20 сообщений в секунду, если ваше требование должно обрабатывать 10 сообщений в секунду, то ваш сервис эффективен. Но если требование 30, то это не так.

Будет ли оно масштабироваться?

Еще раз, это не связано с хостингом. Ваши услуги без гражданства? в противном случае они, вероятно, не будут сильно масштабироваться, поскольку распределение нагрузки невозможно.

Это будет управляемым?

Вероятно, нет: - вам нужно, чтобы пользователь вошел в систему на сервере, чтобы запустить приложение - он не запускается автоматически с сервера - он не может автоматически перезапустить при сбое - он не создает экземпляры службы проактивно - не предоставляет (без специального кода) способ проверки работоспособности службы

Один экземпляр? Несколько потоков?

Если ваша служба не поддерживает состояние между вызовами на одного клиента, настройте его как «один экземпляр на вызов без многопоточности» -> Нет параллелизма, высокая пропускная способность

Если ваша служба поддерживает состояние, то настройте его как «один экземпляр на сеанс и многопоточность», чтобы позволить клиенту выполнять параллельные вызовы. Будьте осторожны с проблемами параллелизма и защищайте свои ресурсы.

Если ваша служба не поддерживает состояние для каждого клиента, но хранит некоторые глобальные данные, сохраняемые для всех вызовов, рассмотрите «один экземпляр на службу и многопоточность». Имейте в виду возможные проблемы параллелизма. В этом вы также можете использовать «один экземпляр на вызов» и оставить глобальное хранилище вне службы.

Answer 2

Мой вопрос:
Будет ли это эффективно?Будет ли это масштабироваться?

Да и да.Но для действительно крупномасштабных приложений вы все равно должны рассмотреть IIS (+ WAS).

поэтому другой вопрос, будет ли это однопоточным?многопоточный?

Это определяется конфигурацией.

Answer 3

Служба Windows, на которой размещается конечная точка WCF, подходит для небольших служб, которые не будут часто использоваться; Вам не нужно связываться с IIS (что может быть ИМО по-настоящему больно). Однако прослушивающий будет только один слушатель, поэтому он не рекомендуется для службы, которая может быть задействована сразу из нескольких мест (для этого используйте IIS; он устанавливает пул приложений, который может обрабатывать много одновременных запросов). Эта модель хороша для взаимодействия один на один между двумя машинами; Вы можете настроить хост службы на поле «установить и забыть», расположенное где-нибудь на складе, и вызвать его для выполнения простых, но нестандартных задач, таких как перезагрузка, дамп журнала и т. д.

Избегайте размещения в любом пользовательском приложении (консоли или иным образом) конечной точки службы, за исключением первоначального тестирования концепции. В дополнение к недостатку с одним прослушивателем, пользовательское приложение ДОЛЖНО запускаться в контексте вошедшего в систему пользователя (а не пользователей службы, которые «вошли» как часть запуска Windows) и должно иметь пользовательский «keepalive» мониторинг; с помощью службы Windows можно просто перезапустить ее, если она выйдет из строя, при этом она не дает сообщения о сбое пользовательского приложения, за исключением того, что не позволяет этой программе завершить работу всей ОС (и спросить пользователя, хотят ли они сообщить об аварии).