Как Quarkus обединява императивно и реактивно програмиране

Тази година планираме сериозно да развиваме темите за контейнери, Cloud-Native Java и Kubernetes. Логичното продължение на тези теми ще бъде разказ за фреймворка Quarkus, който вече беше разгледан в Хабра. Днешната статия е посветена не толкова на устройството на 'субатомната супершвидка Java', колкото на перспективите, които Quarkus внася в Enterprise.

Java и JVM все още са изключително популярни, но при работа с безсървърни технологии и облачно-ориентирани микросервиси Java и други езици за JVM се използват все по-рядко, тъй като заемат твърде много място в паметта и се зареждат твърде бавно, поради което не са подходящи за използване с краткоживеещи контейнери. За щастие, в момента тази ситуация започва да се променя благодарение на Quarkus.

Супершвидка субатомна Java достигна ново ниво!

42 издания, 8 месеца работа на общността и 177 невероятни разработчици – резултатът от всичко това е излизането през ноември 2019 година Quarkus 1.0, издание, което символизира важна веха в развитието на проекта и предлага много страхотни функции и възможности (подробно за тях можете да прочетете в аннонса).

Днес ще разкажем как Quarkus обединява моделите на императивно и реактивно програмиране на база на единно реактивно ядро. Ще започнем с кратък преглед на историята, а след това подробно ще разгледаме как Java-разработчиците могат да се възползват от тези предимства.

Микросервиси, управлявани от събития архитектури и безсървърни-функции – всичко това днес е в подем. От скоро създаването на облачно ориентирани архитектури стана много по-лесно и достъпно, но проблемите продължават да съществуват – особено за Java разработчиците. Например, при serverless функции и микросервизи има остра необходимост от намаляване на времето за стартиране, намаляване на разхода на памет и правене на тяхното разработване по-удобно и приятно. Java през последните години направи няколко подобрения, като доразработените функционалности за контейнери и други. Въпреки това, постигането на нормална работа на Java в контейнер продължава да бъде трудно. Затова ще започнем с разглеждане на някои от вътрешните трудности на Java, които особено се проявяват при разработването на контейнерно ориентирани Java приложения.

Нека първо се обърнем към историята.

Нишки и контейнери

Започвайки от версия 8u131, Java започна да поддържа контейнери до известна степен, благодарение на подобрения в функционалността ergonomics. По-специално, сега JVM знае на колко процесорни ядра работи и може съответно да настройва пуловете на нишките – обикновено пулове fork/join. Разбира се, това е страхотно, но да речем, че имаме традиционно уеб приложение, използващо HTTP сервлети и работещо в Tomcat, Jetty и др. В резултат на това приложението ще назначи отделен поток за всяка заявка и ще позволи на този поток да блокира, докато очаква операции за вход-изход, например при достъп до база данни, файлове или други услуги. Тоест, размерът на такова приложение зависи не от броя на наличните ядра, а от броя на едновременните заявки. Освен това, това означава, че квотите или лимитите в Kubernetes за броя на ядрата тук не особено ще помогнат, а ситуацията в крайна сметка ще завърши с тротлинг.

Изчерпване на паметта

Потоковете са памет. Вътреконтейнерните ограничения на паметта не са панацея. Просто започнете да увеличавате броя на приложенията и потоковете, и рано или късно ще се сблъскате с критичен ръст на честотата на превключванията и, следователно, с деградация на производителността. Освен това, ако приложението използва традиционни микросервисни фреймворкове или се свързва с база данни, или ангажира кеширане, или по някакъв начин допълнително харчи памет, ще ви е напълно очевидно, че ви е нужен инструмент, позволяващ да надзърнете в JVM и да видите как тя управлява паметта, без да убивате самата JVM (например, XX:+UseCGroupMemoryLimitForHeap). И дори въпреки факта, че от Java 9 нататък JVM е научила да възприема cgroups и да се адаптира съответно, резервирането и управлението на паметта остава доста сложно.

Квоти и лимити

В Java 11 беше добавена поддръжка за CPU-квоти (например PreferContainerQuotaForCPUCount). Kubernetes също предлага поддръжка за лимити и квоти. Да, всичко това има смисъл, но ако приложението отново излезе извън зададената квота, отново се връщаме към ситуацията, в която размерът – както в случая с традиционните Java-приложения – се определя от броя на ядрата и с отделен поток за всяка заявка, т.е. от всичко това няма много полза.
Освен това, ако използваме квоти и лимити или функциите за хоризонтално (scale-out) мащабиране на платформата, лежаща в основата на Kubernetes, проблемът не се решава сам по себе си. Просто изразходваме повече ресурси за решаване на основния проблем или в крайна сметка достигаме до преразход на ресурси. А ако това е високонапрегната система в публично облако, почти сигурно започваме да използваме повече ресурси, отколкото наистина е необходимо.

И какво да правим с всичко това?

Ако накратко, да използваме асинхронни и неблокиращи библиотеки за вход-изход и фреймворкове като Netty, Vert.x или Akka. Те са много по-подходящи за работа в контейнери заради своята реактивна природа. Поради неблокиращото входно-изходно взаимодействие, същият поток може да обработва няколко паралелни запитвания. Докато едно запитване чака резултатите от входно-изходното взаимодействие, потокът, който го обработва, се освобождава и се заема с друго запитване. Когато резултатите от входно-изходното взаимодействие най-накрая пристигнат, обработката на първото запитване продължава. Чрез редуването на обработката на запитванията в рамките на един и същ поток, може да се намали общият брой на потоковете и да се намали ресурсното потребление при обработка на запитвания.

При неблокиращото входно-изходно взаимодействие, броят на ядрата става ключов параметър, тъй като именно той определя броя на входно-изходните потоци, които могат да се изпълняват паралелно. При правилна употреба това позволява ефективно разпределение на натоварването между ядрата и справяне с по-високи натоварвания при по-малко ресурси.

Как, и това всичко?

Не, има още нещо. Реактивното програмиране помага по-добре да се използват ресурсите, но също така има своята цена. По-специално, кодът ще трябва да бъде пренаписан в съответствие с принципите на неблокираност и да се избегне блокирането на входно-изходните потоци. А това е съвсем различен модел на разработка и изпълнение. И макар да има много полезни библиотеки, това все пак е коренна смяна на обичайния начин на мислене.

На първо място, трябва да научите как да пишете код, който се изпълнява асинхронно. Веднъж започнали да използвате неблокиращо входно-изходно взаимодействие, ви е необходимо явно да задавате какво трябва да се случи при получаване на отговор на запитването. Просто блокирането и чакането вече не е вариант. Вместо това можете да предавате обратни повиквания, да използвате реактивно програмиране или continuation. Но и това не е всичко: за да използвате неблокиращото входно-изходно взаимодействие, са ви нужни и неблокиращи сървъри и клиенти, и е желателно да е навсякъде. В случая с HTTP всичко е просто, но има и БД, файлови системи и много други.

И макар тоталната непрекъсната реактивност да дава максимална ефективност, такъв преход може да бъде труден за усвояване на практика. Затова способността да се комбинират реактивен и императивен код става необходимо условие за това:

1. Ефективно да се използват ресурсите в най-заетите направления на софтуерната система;
2. Да се използва по-прост стил на кода в останалите части.

Представяме Quarkus

Същността на Quarkus е да обедини реактивната и императивната модели в рамките на една среда за изпълнение.

В основата на Quarkus лежат Vert.x и Netty, върху които е изградена цяла поредица от реактивни фреймуъркове и разширения, предназначени да помогнат на разработчика. Quarkus е проектиран не само за изграждане на HTTP микросервизи, но и за архитектури, управлявани от събития. Поради своята реактивна природа, той работи изключително ефективно с системи за обмен на съобщения (Apache Kafka, AMQP и др.).

Цялата хитрост е как да се използва един и същ реактивен двигател както за императивен, така и за реактивен код.

Quarkus блести в това. Изборът между императивен и реактивен е очевиден – да се използва реактивното ядро и за двете. И в това, с което то помага, е бързият неблокиращ код, който обработва почти всичко, което преминава през цикъла на събитията (event-loop thread, известен още като IO thread). Но ако имате класически REST приложения или клиентски приложения, Quarkus е готов с императивен модел на програмиране. Например, поддръжката на HTTP в Quarkus е изградена на база неблокиращ и реактивен двигател (Eclipse Vert.x и Netty). Всички HTTP заявки, получавани от вашето приложение, първо преминават през цикъла на събитията (IO Thread) и след това се изпращат на частта от кода, която управлява заявките. В зависимост от дестинацията кодът за управление на заявките може да се извиква в рамките на отделен поток (т.нар. worker thread, изполван при сервлети и Jax-RS) или да използва изходния входно-изходен поток (реактивен маршрут reactive route).

За конекторите на системите за предаване на съобщения се използват неблокиращи клиенти, работещи върху двигателят Vert.x. Така можете ефективно да изпращате, получавате и обработвате съобщения от системи от клас messaging middleware.

На сайта Quarkus.io събрани са няколко добри ръководства, които ще помогнат за започване на работа с Quarkus:

• Използване на реактивни маршрути
• Реактивни SQL клиенти
• Използване на Apache Kafka с реактивно предаване на съобщения
• Използване на AMQP с реактивно предаване на съобщения
• Използване на Vertx API

Освен това, подготвихме онлайн практически уроци, за да се запознаете с различните аспекти на реактивното програмиране, като за тяхното преминаване е достатъчен само браузър, не е необходима IDE, а и компютърът не е задължителен. Можете да намерите тези уроци тук..

Полезни ресурси

• 4 причини да опитате Quarkus
• Уебсайт на проекта Quarkus – quarkus.io
• Проект Quarkus в GitHub – github.com/quarkusio/quarkus
• Туитър на проекта Quarkus – twitter.com/QuarkusIO
• Чат на проекта Quarkus – quarkusio.zulipchat.com
• Форуми на проекта Quarkus – groups.google.com/forum/#!forum/quarkus-dev

10 видео урока по Quarkus, за да се запознаете с темата

Как пишат на сайта Quarkus.io, Quarkus – това е Kubernetes-ориентиран Java стек, създаден за GraalVM и OpenJDK HotSpot и изграден от най-добрите Java библиотеки и стандарти.

За да ви помогнем да разберете темата, подбрахме 10 видео урока, в които се разглеждат различни аспекти на Quarkus и примери за неговото използване:

1. Представяме Quarkus: Java фреймворк от ново поколение за Kubernetes

Автори: Томас Кворнстром (Thomas Qvarnstrom) и Джейсън Грийн (Jason Greene)
Целта на проекта Quarkus е да създаде Java платформа за Kubernetes и безсървърни среди, както и да обедини реактивните и императивните модели на програмиране в единна среда на изпълнение, така че разработчиците да могат гъвкаво да варират подхода си при работа с широк спектър от разпределени архитектури на приложения. Научете повече от въведението по-долу.

2. Quarkus: свръхбърза субатомна Java

Автор: Блюр Саттер (Burr Sutter)
Видеоурок от интернет лекцията DevNation Live показва как да използвате Quarkus за оптимизация на корпоративни Java приложения, API, микросервизи и безсървърни функции в среда Kubernetes/OpenShift, правейки ги много по-малки, по-бързи и мащабируеми.

3. Quarkus и GraalVM: ускоряване на Hibernate до свръх скорости и компресиране до субатомни размери

Автор: Сейн Гриноверо (Sanne Grinovero)
От презентацията ще научите как се е появил Quarkus, как работи и как позволява на комплексни библиотеки, като Hibernate ORM, да бъдат съвместими с нативни образи на GraalVM.

4. Учим се да разработваме безсървърни приложения

Автор: Мартин Лютер (Marthen Luther)
Във видеото по-долу е показано как да създадете просто Java приложение с помощта на Quarkus и да го разгърнете като безсървърно приложение на Knative.

5. Quarkus: кодирайте с удоволствие

Автор: Едсон Янага (Edson Yanaga)
Видео ръководство за създаване на вашия първи проект Quarkus, което позволява да разберете защо Quarkus печели сърцата на разработчиците.

6. Java и контейнери – какво ще бъде бъдещето им заедно

Автор: Марк Литъл (Mark Little)
Тази презентация запознава с историята на Java и обяснява защо Quarkus е бъдещето на Java.

7. Quarkus: свръхбърза субатомна Java

Автор: Димитрис Андреадис (Dimitris Andreadis)
Обзор на предимствата на Quarkus, които спечелиха признанието на разработчиците: простота, свръхвисоки скорости, най-добри библиотеки и стандарти.

8. Quarkus и субатомни реактивни системи

Автор: Клемент Ескофие (Clement Escoffier)
Благодарение на интеграцията с GraalVM Quarkus предлага свръхбързо преживяване при разработката и субатомна среда за изпълнение. Авторът говори за реактивната страна на Quarkus и как да я използвате при създаването на реактивни приложения и приложения с потокова предаване на данни.

9. Quarkus и бърза разработка на приложения в Eclipse MicroProfile

Автор: Джон Клингън (John Clingan)
Комбинирайки Eclipse MicroProfile и Quarkus, разработчиците могат да създават многопрофилни контейнерни приложения MicroProfile, които се стартират за десетки милисекунди. Във видеото подробно се обсъжда как да кодирате контейнерно приложение MicroProfile за разгръщане на платформата Kubernetes.

10. Java, версия „Турбо“

Автор: Маркус Бил (Marcus Biel)
Авторът показва как да използвате Quarkus за създаване на супермалки и свръхбързи Java контейнери, които позволяват истински пробив, особено в serverless среди.

Източник: habr.com