Разумен ли self-hosting ASP.NET Web API приложения в службе Windows? Кто-нибудь использовал такое в проде?

Question

[Larry Underwood]

Есть веб приложение (не highload), которое сейчас работает и хостится в IIS. От IIS используется только подъем по первому запросу и перезапуск, если упало (WAS). Есть мысли перейти на селфхостинг, однако есть опасения, что мировой опыт отвергает такой подход. У кого есть такой опыт и положителен ли он?

Answer 1

[Ogoun Er]

Использую именно такой подход в проде, сервисы работаю как виндовс-службы, при старте сервис выбирает себе свободный порт и поднимает self-host webapi, по которому к нему может обращаться любой другой сервис. По скорости пока хватает, но планирую перейти на свой бинарный протокол сразу поверх TCP (по тестам до 20000 RPS получается добраться, на webapi до такого не дотянуть).

Comments

[Larry Underwood]

Спасибо за ответ!
Очень интересен Ваш опыт, когда приложение выбирает себе порт, кому оно сообщает о том, на каком порту работает? Используете ли какой-либо Service Discovery?
А кто следит за Вашим приложением? Если оно упадет, кто его перезапустит?

[Ogoun Er]

Да, используется собственный Discovery сервис, у него постоянный адрес, и он хранит и раздает актуальную таблицу маршрутизации. Через него же можно отслеживать падения сервисов (делает heartbeat и исключает недоступные).
Падения сервисов это исключительная ситуация, т.к. они должны работать 24x7, в проде не помню чтобы была такая ситуация. Но если возникнет, то восстановлением будет заниматься или дежурный оператор, или пойдет к разработчикам, если что-то серьезное.
Также в таблице маршрутизации есть поле в котором указан транспорт по которому можно обращаться к сервису (webapi, socket), заложено на будущее и позволит безболезненно перейти на более быструю версию если понадобится.

[Larry Underwood]

Ogoun Er, круто. Но собственный Discovery сервис видимо запущен как служба win? Т.е. получается у Вас всё без Docker и Kubernetes?
А как Вы обновляете сервисы? По очереди выключаете, накатываете обновление, потом снова включаете?
И сразу в догонку еще вопрос: во время обновления ставите лок на запись в БД, чтобы правильно накатить миграции?

И еще один вопрос)))
Насколько трудоемко разрабатывать собственный Discovery сервис?

[Ogoun Er]

Larry Underwood, discovery очень прост, был сделан за пару дней, хранит состояние только в оперативной памяти. Работает как win-служба и поднимает self-host webAPI для регистрации сервисов и предоставления таблицы с сервисами. Принимает сообщение от сервиса, сохраняет имя exchange, если в терминах MQ, и его enpdoint, при этом группирует endpoint'ы по имени exchange. Каждый сервис может поднять сколько угодно точек подключения и зарегистрировать на точках подключения inbox'ы.
Вот так выглядит запись для одной точки обмена:

<IPRRecord>
	<Endpoints>
		<d3p1:string>192.168.1.100:61812</d3p1:string>
		<d3p1:string>192.168.1.100:61822</d3p1:string>
		<d3p1:string>192.168.1.100:61833</d3p1:string>
		<d3p1:string>192.168.1.100:61841</d3p1:string>
		<d3p1:string>192.168.1.100:61850</d3p1:string>
	</Endpoints>
	<Transport>webapi</Transport>
	<Key>exchange_name</Key>
	<Title>MyService</Title>
	<Version>1.0</Version>
</IPRRecord>

Для обновления есть автоматические сценарии, и будет свой deploy агент (или не свой, в рассмотрении octopus и teamcity). В общем случае сценарий такой, запускается новая версия сервиса в интерактивном режиме, включается в балансировку (регистрируется в discovery), удаляется сервис со старой версией, ставится и запускается сервис с новой версией, останавливается интерактивная копия. Получается обновление на горячую без остановки работы.

По базе данных, если имеется в виду системная база данных, то механизм работы всей системы в целом сделан так, что при изменении схемы БД (что очень маловероятно), новый сервис который в нее пишет начнет писать в новую базу, а данные со старой будут мигрированы вручную. Это не даст никакого эффекта на работу системы.

Если же имеется в виду запись во внешние базы, то используется собственный DSL, в котором можно указывать маппинг полей и генерировать запросы. Соотвественно если будет изменена схема БД внешней по отношению к системе, то будет просто изменен текст с описанием маппинга.

[Ogoun Er]

Larry Underwood, а docker, rkt и kubernetes не использую. Одна из причин, то что *nix'ы в компании, к сожалению, еще не внедрены, использовать на win смысла особого не вижу. Подожду пару лет пока .net core и docker (он в плане легкости конфигурирования) прокачаются и можно будет переехать во всю эту инфраструктуру.

[Larry Underwood]

Ogoun Er, огромнейшее спасибо, за то, что поделились опытом!
У нас в компании абсолютно такая же беда. Прибиты (пока) к Win-платформе.

Обнаглею и задам еще вопрос: как у Вас осуществляется балансировка (и чем)? Таблица маршрутизации лежит на балансировщике?
Получается какой-то самописный балансировщик у Вас?

[Ogoun Er]

Нет, если делать общий балансировщик, получалась зависимость от одной точки отказа. Каждый сервис при запуске подтягивает себе таблицу с discovery и хранит свою копию, пока адреса актуальны, то сервис сможет взаимодействовать с другими сервисами даже если discovery упал. Балансировку каждый сервис делает сам по принципу round-robin, при этом если запрос не прошел, то выкидывает из своей локальной копии адрес.

Answer 2

[#]

Есть мысли перейти на селфхостинг, однако есть опасения, что мировой опыт отвергает такой подход

мопед не мой

но:

Сначала мы пошли по простому пути: прикрутили IIS, создали ASP.NET-приложение с фреймворком ASP.NET Web API и начали пилить бизнес-логику. Быстро стало понятно, что вся эта конструкция не держит больше 500-700 запросов в секунду. Как бы мы ни заклинали IIS, ни подкручивали 100500 параметров, проблема не решалась. И совсем доставало, что залезть внутрь IIS нет возможности, а значит полного контроля над ситуацией нам не добиться. IIS — пресловутый черный ящик, в котором тяжело что-то кардинально изменить.

Тогда мы попробовали сервер проекта Katana (реализация OWIN-инфраструктуры от Microsoft). Katana — проект с открытым исходным кодом, поэтому можно было увидеть внутренности. К тому же, у Web API есть поддержка OWIN, а значит, сильно менять код не придется. Katana предоставляет возможность работать как с IIS, так и с их простым сервером, написанным на основе .NET-овского HttpListener. Именно его мы и взяли. Результат порадовал: теперь сервер держал около 2000 запросов в секунду, а ASP.NET приложение трансформировалось в Windows-сервис.

Однако нагрузка на сервера увеличивалась, пилились новые фичи. Становилось понятно, что и этот вариант нас тоже не устраивает. Тогда мы пошли на кардинальные меры: от всей Катаны остался только HttpListener с небольшой обвязкой для асинхронности, от Web API не осталось ничего, то есть приложение стало полностью заточено под HTTP-запросы для биддера. В результате сервер стал способен обрабатывать до 9000 запросов в секунду. Вывод прост: вся OWIN- и Web API-обвязка оказывает критическое влияние на высокопроизводительные приложения. Хотите быстрее — пишите проще и неуниверсально. (Это не говорит о том, что внутри приложения должен быть ядерный говнокод. У нас всё модульно, вполне расширяемо: DI, паттерны и всё такое)

источник - https://habr.com/company/targetix/blog/261745/

Comments

[Александр Юдаков]

Многие годы использую связку Windows service + HttpListener для создания сетевых сервисов.
Быстро, просто, удобно, асинхронно.