Инновации и инсайты в мире Java из первых уст. Новая конференция Java Fest — 21 марта >>
×Закрыть

ASP.NET 5 — взгляд внутрь. Об изменениях ядра и инфраструктуры

Всем привет. Выступая на различные рода мероприятиях и рассказывая о новшествах от Microsoft, я получаю много вопросов по поводу нового ASP.NET 5 (он же ASP.NET vNext). В этой статье хочу вкратце рассказать об основных изменениях.

Итак, главное: переписано ядро под новый runtime. Зачем? Тут немаловажную роль сыграло изменение концепции разработки на технологиях Microsoft в сторону кроссплатформенности и открытости. Расскажу по порядку.

Среда выполнения

Microsoft решил, что нужно расширить горизонты применения опыта программистов .NET на платформы, которые ранее не поддерживались — Linux и OSX. К этому добавилась необходимость обеспечить работу ASP.NET на «не подготовленной» среде, а именно, на голом сервере, без IIS.

Для решения этих задач был разработан DNX (.NET Execution Environment) — это SDK + runtime, который имеет всё для того, чтобы собрать и запустить .NET приложение для Windows, Linux и Mac. По сути, это некий контейнер, откуда стартуют написанные нами приложения. Этот механизм позволяет создать приложение на одной платформе и запустить его на всех.

Если копнуть глубже, оказывается, что в основе DNX лежит .NET Core — кроссплатформенная реализация .NET. Это модульный runtime (если кто скажет, как это красиво перевести на русский или украинский язык, буду благодарен) и набор переписанных с учетом кроссплатформенности библиотек .NET Framework.

CoreFX — это, по сути, набор стандартных библиотек .NET Framework, необходимых для разработки консольных .NET приложений или ASP.NET веб-сайтов.

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

Для облегчения разворачивания среды был же создан DNVM (.NET Version Manager) — установщик для DNX, который берет на себя рутину выемки необходимых библиотек, компиляцию в общем, подготовку окружения. DNVM можно установить под Windows, Linux и Mac. Можно ли обойтись без него? Можно. Вы можете сами скачать из GitHub исходники, скомпилировать, прописать переменные среды и т.д...

Итак, еще раз фиксируем, что откуда берётся: DNVM устанавливает необходимую версию DNX, которая содержит в себе компоненты CoreFX и CoreCLR.

Добавлю, что CoreCLR, CoreFX, DNX да и сам ASP.NET MVC лежат в исходниках на GitHub (см. линки выше).

Веб-сервера

Теперь давайте раскопаем сам ASP.NET. Начнем с веб-сервера. Сейчас есть три варианта запуска ASP.NET приложений: IIS, WebListener и Kestrel. Остановимся на них поподробнее.

IIS

Основное отличие ASP.NET vNext от предыдущих версий — отсутствие привязки к System.Web. На уровне веб-сервера IIS этого удалось достичь благодаря проекту Helios. Это новый веб-хост, изначально создаваемый на базе OWIN (Open Web Interface for .NET), но в итоге переделан под использование vNext инфраструктуры, задача которого обеспечить с одной стороны интеграцию с модулями IIS, с другой — отвязаться от инфраструктуры System.Web для увеличения производительности.

Если копнуть глубже в эту проблематику, то оказывается, что существовали некие проблемы в развитии MVC, WebApi и SignalR. При создании ASP.NET разработчики, по причинам о которых я не хочу говорить, жестко привязались к .NET, а именно к базовой библиотеке System.Web. И все было хорошо, пока над ASP.NET не начали появляться надстройки MVC, WebApi и SignalR. Учитывая, что команды разработчиков .NET Framework и ASP.NET — это разные команды, появилась проблема с выпуском релизов ASP.NET: выход нового ASP.NET был привязан к выпуску нового .NET Framework.

Сейчас те, кто занимается управлением разработкой меня поймут: .NET Framework обладает своим жизненным циклом, в который добавили ASP.NET, что повлекло за собой необходимость проводить дополнительные интеграционные работы, тесты и т.п. Это сковывало как одну, так и другую команду. Дабы облегчить жизнь обеим командам и дать возможность ASP.NET развиваться самостоятельно, было принято решение отвязать ASP.NET от базовой библиотеки .NET Framework System.Web. Это повлекло за собой написание ядра ASP.NET с нуля и подготовка его к новой инфраструктуре хостинга. Эти изменения и стали причиной выливания потока моего сознания в этой статье :)

WebListener

Это решение создано специально под Windows Server и дает возможность хостить ASP.NET приложения без IIS. Он работает напрямую с Http.Sys (драйвер Kernel). Его основное достоинство — поддержка большинства интерфейсов IIS, но при этом малая ресурсоемкость.

Kestrel

Kestrel — это новый, открытый, кроссплатформенный (Windows, Linux, Mac) веб-сервер на базе Libuv. Libuv — это кроссплатформенная компонента для поддержки асинхронных операций ввода\вывода: асинхронная работа с TCP\UDP сокетами, DNS резервация, операции с файловой системой, управление потоками и многое другое.

Что выбрать?

IIS следует выбирать для приложений, которые будут крутится на Windows Server и используют функционал, который еще не реализован в WebListener. По поводу последнего, вообще темень беспросветная — что за зверь, какие API поддерживает, исходники, документация. Все лежит где-то там, куда я не смог добраться. Но тут есть железобетонное оправдание: WebListener пока в бэте. Его можно использовать на свой страх и риск. Я бы сейчас порекомендовал его пощупать с целью тестирования, самообучения, здорового интереса, но никак не для коммерческих проектов. Выйдет в релиз, появится документация, тогда порекомендую с мигрировать на него, так как, по официальным заявлениям, он должен быть легковеснее и быстрее, чем IIS.

Что касается Kestrel — его стоит использовать в случае разработки веб-решения для хостинга на Linux и Mac.

Есть еще один вариант разворачивания ASP.NET приложения, используя Docker — контейнер который содержит всю инфраструктуру (файловую систему, middleware, runtime) для запуска ваших проектов. Это позволяет гарантировать одинаковую работу приложений независимо от среды, в которую вы разворачиваете этот контейнер.

Резюме

Ну и теперь, соединяем первую часть статьи (про среду выполнения) и вторую (про веб-сервера): Kestrel работает поверх инфраструктуры DNX, а на сервер он попадает вместе с пакетом вашего ASP.NET проекта, который собирает Visual Studio при публикации. Туда же попадают все необходимые ASP.NET библиотеки.

По такому же принципу работает публикация под WebListener и IIS (IIS в даном случае не попадает в пакет, а попадает компонента, которая позволяет утилизировать функционал IIS, не привязываясь к System.Web).Этот подход позволяет избавится от проблем с совместимостью, которые имели место раньше, в случае разных версий .NET Framework на сервере и на рабочем компьютере разработчика.

Ну и в завершении: направление движения веб-разработки радует. Следует ожидать ускорения в развитии MVC, WebApi и SignalR, так как все блокеры сняты и появилась поддержка OpenSource community. Плюс теперь можно писать веб-решения под любые серверные платформы, что снимет инфраструктурные ограничения, имеющие место во многих компаниях.

Попробовать написать свой HelloWord на ASP.NET vNext вы можете, скачав бесплатную редакцию Visual Studio Community.

В следующей статье я сфокусируюсь на изменениях для разработчиков. Заглянем в настройки ASP.NET проекта и посмотрим на изменения в коде.

P.S. И не забывайте про конференцию DevDay 2015, билетов на которую осталось не так много.



Продолжение:
— ASP.NET 5: что изменилось для разработчика
— ASP.NET 5: публикуем приложение на Linux
— ASP.NET 5: публикуем приложение на Windows Server

LinkedIn

19 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Я тоже за Докер, а то слышишь на каждом углу это слово, только не в экосистеме .НЕТ. Реальные кейсы где его можно использовать.
По поводу статьи: почему кестлер лучше не на виндовых системах использовать? Я бы еще упомянул о .NET Native.

почему кестлер лучше не на виндовых системах использовать?
Не лучше, а Кестрел — единственный официально поддерживаемы хост, который можно использовать на линуксе и маке. Так же, как и с IIS, на него можно будет проксировать запросы с того же Апачи.
Что касается Kestrel — его стоит использовать в случае разработки веб-решения для хостинга на Linux и Mac.

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

Автор говорит, что на невинде — это пока единственный вариант. На винде его тоже можно нормально использовать.

Kestrel можно использовать под Windows. Он работает так же, как на Linux или Mac. Считайте, что теперь у Вас есть выбор, хотите — IIS, хотите — Kestrel. Просто IIS более развитое решение, о чем говорит пара предложений из официальной документации:

IIS currently provides support for the largest number of features, and includes IIS management functionality and access to other IIS modules. Hosting ASP.NET 5 on IIS bypasses the legacy System.Web infrastructure used by prior versions of ASP.NET, providing a substantial performance gain.

По .Net Native: это пока никак не относится к ASP.NET. .Net Native на сейчас Вы можете использовать только в Windows Universal приложениях.

Пора петь реквием по Java?

Сергей, если вы думаете, о чем бы ещё написать статью, то очень бы хотелось про Docker услышать. И вообще о способах разворачивания ASP.NET веб-приложений на Linux-серверах.

Принято :) Я в принципе уже готовлю демку именно о публикации на Ubuntu 14.04. Как только все прогоню, отловлю все особенности, напишу.

кстати, да, про докер очень интересно. С нетерпением жду =)

капнуть глубже
 — возможно, копнуть?
runtime
Среда выполнения
позволяет утилизировать функционал
позволяет использовать функционал, утилизируют отходы.
— возможно, копнуть?

Да, спасибо, исправил.

WebListener пока в бэте
На сколько я знаю, работу над WebListener пока приостановили и в первом релизе кроме IIS будет доступен только Kestrel.

Ну, и IIS будет проксировать запросы к Kestrel (reverse proxy). Т.е. сначала Kestrel будет единственным хостом.

Я тоже об этом читал, но нигде официально этого не видел. Ну и в Nuget он в общем то регулярно обновляется (последняя версия от 2-го сентября 2015, к слову тогда же вышла последняя бета ASP.NET) и в свежих примерах на официальных блогах фигурирует. Но о том, когда он выйдет из beta, достоверно не известно. С другой стороны о том, что он вообще никогда не выйдет, или выйдет после релиза ASP.NET 5, сейчас речь не идет.

Следует ожидать ускорения в развитии MVC, WebApi и SignalR, так как все блокеры сняты
Нужно ли это понимать так, что к вырвиглазной аутентификации и вырвиглазной обработке ошибок добавлятся и другие вырвиглазные вещи?

О какой вырвиглазности Вы говорите? И о какой именно аутентификации? А то звучит так будто в ASP.NET только одна стандартная реализация этого функционала

такі загальні питання ставлять щоб накинути)

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

Подписаться на комментарии