Pull to refresh

Comments 28

Интересно, у меня с подобными сервисами были проблемы с правами.
Если служба запускается под учёткой NT AUTHORITY\Network Service, нужно было специально раздать права

netsh http add urlacl url=http://+:9001/ user="NT AUTHORITY\Network Service"

Почему автор с этим не столкнулся?
Когда биндишь localhost, то никакие права не нужны.
После начала эксплуатации аналогичного WCF-сервиса столкнулись с тем, что порт, по которому происходит обмен слушает не приложение/служба, а какой-то системный процесс. Сначала это вызвало некоторый диссонанс при настройке файрвола, а позже выяснилось, что ещё и сниффер (Wireshark) не видит этих пакетов, даже будучи запущенным из под администратора. Сталкивались вы с такими «особенностями»?
Нет, с подобными «особенностями», к счастью, не сталкивался, и у меня Wireshark пакеты таки «видит».

Порт разделяется между всеми процессами, которые его слушают, инструменты вроде netstat показывают случайный процесс. На самом деле, порт слушается драйвером HTTP.SYS


Пакеты в сниффере должны быть видны, возможно вы как-то не так смотрели.

На дворе 2017ый, а на хабре статьи про WCF (технология без будущего), написанный на VS2015...


Ожидал увидеть — "Как на netcore-2.0-preview запустить WCF через RabbitMQ"

А что не так с этой технологией?

Никакого развития. Поддержки в netcore не предвидится.

Вообще-то поддержку в netcore обещали, просто не сразу.


И да, какое такое развитие вам нужно? Новые спецификации WS каждые полгода не выходят.

Да с самой технологией всё хорошо. Вот только, как раз благодаря стабильности WCF — ценность новых helloworld-ов на full .NET не так уж и велика. Например, официальная документация по этой теме — на мой взгляд, куда более читабельная. От Хабра всё-таки ждешь глубины, а не полноэкранных скриншотов пустого окна Студии.

Вы шутите? В корпоративе очень даже используем? WCF как конструктор, что хотите то и реализуете. Как она может быть «без будущего» Что в замен? Заного придумывать велосипед?

Да, мы тоже используем на уровне поддержки. Новые сервисы пишутся как webapi. Для велосипедов сложнее используется akka.net и rabbitmq. Плюсы? Это ещё бОльший конструктор, нет завязки на msmq, можно присоединять другие экосистемы через тот же rabbit.


У меня вопрос был не к технологии, а к статье, которая по сути хеллоуворлд, да ещё и в 2015 студии. Разницы в коде конечно не будет, но человек явно забыл обновить тулы.

В WCF есть биндинг к rabbitmq. Он, конечно, не может использовать все возможности rabbitmq — зато он может использовать все возможности WCF, что также может быть полезным.

Знаете, и WinForms сейчас все еще много где используется и Silverlight, представьте тоже! Это не показатель! Szer полностью прав, надо идти в ногу со временем! Есть такие технологии как ServiceStack, Protobuf, Rabbit MQ, а вместо того чтобы заниматься броунским движением со службами Windows, можно использовать TopShelf…
А можно и вообще обойтись одним ASP.NET MVC/WEB API. Настраивается Autostart и RunAlways на IIS и не требуется такая гремучая смесь технологий. Плюс возможность создания страниц мониторинга, конфинурации сервиса и проч. Очень удодно и практично.
MS, конечно, обещал добавить WCF в .NET Core, но изначально ее там не было и они стараются перетянуть всех на ASP.NET MVC (который теперь и Web API)
И на всех машинах IIS поднимать? Не слишком ли тяжеловесная связка выходит? Кроме того, можно реализовать WCF RESTful службу.

… и это будет ничем не проще того, что написано тут в статье.


Суть в том, что без IIS никаких Autostart и RunAlways не настроить, а добавлять IIS в зависимости не всегда допустимо.

C TopShelf легко его сделать службой, тут уж как удобно. Если есть возможность использовать iis, отлично. Нет возможности, ну есть вот другой вариант.

Вы так пишите, как будто тут описан мега-сложный способ.

Нет, не слишком. Слишком, это когда из одного сервиса торчит другой. А еще, из WCF делать RESTful, имея в своем распоряжении ASP.NET стек. Тем более, если из WS-* используется практически ничего. Но, это дело вкуса и других требований.
На самом деле, нашим LeanOps проще иметь дело с IIS-hosted приложениями, отсюда и переход на ASP.NET c Windows Service. Сначала, мне тоже это казалось странным. Теперь — совсем нет. Кроме того, как я уже говорил, легко прикручиваются очень полезные web-страницы для мониторинга, управления настройками и проч.
WCF позволит использовать сегодня RESTful, а завтра netTcp, а послезавтра rabbit с минимальными доработками. Сегодня хостим в виндовой службе, а завтра в IIS, а послезавтра угарели и в WPF вкорячили.
Он (IIS) ваще пихается в Nano Container не задумываясь. Там уменьшение размера идет за счет перехода .NET Core.
Речь идеть просто об альтернативном подходе. Не мил IIS, не используйте.
Кстати, давно хотел спросить и вот подвернулся случай — как правильно обновлять такие службы?
UPD Обновлять в плане выкатывать версию 2 вместо версии 1, новая сборка с конвейера пришла.

Останавливаем службу, заменяем файлы, запускаем службу.

Для начала стоит вести версионирование api.
А деплой подобных компонентов может происходит так:


1) новая версия деплоится на резервную машину и запускается
2) балансировщик переключается на резервную машину (все запросы теперь шлются туда)
3) деплоится новая версия на основную машину
4) основная становится резервной (опционально)


Работаем.

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

Если принципиально "живое" обновление — можно сделать обертку для него.


Всего-то надо создать второй AppDomain, включить для него теневые копии и поставить FileSystemWatcher, на который повесить перезапуск.

Sign up to leave a comment.

Articles