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, билетов на которую осталось не так много.
