{"id":74795,"date":"2020-03-20T20:42:21","date_gmt":"2020-03-20T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie"},"modified":"2020-03-20T20:42:21","modified_gmt":"2020-03-20T17:42:21","slug":"kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Jak Quarkus \u0142\u0105czy programowanie imperatywne i reaktywne","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

W tym roku planujemy powa\u017cnie rozwija\u0107 temat kontener\u00f3w, Cloud-Native Java<\/a><\/noindex> i Kubernetes<\/a><\/noindex>. Logicznym rozwini\u0119ciem tych temat\u00f3w b\u0119dzie opowie\u015b\u0107 o frameworku Quarkus, kt\u00f3ry ju\u017c zosta\u0142 om\u00f3wiony<\/a><\/noindex> na Habrze. Dzisiejszy artyku\u0142 po\u015bwi\u0119cony jest nie tyle zasadom dzia\u0142ania \"subatomowej super szybkie Java\", ile perspektywom, kt\u00f3re Quarkus wnosi do Enterprise.<\/p>\n

\"Jak
\n
\nJava i JVM wci\u0105\u017c ciesz\u0105 si\u0119 ogromn\u0105 popularno\u015bci\u0105, ale w pracy z technologiami serverless i mikroserwisami opartymi na chmurze Java i inne j\u0119zyki dla JVM s\u0105 coraz rzadziej stosowane, poniewa\u017c zajmuj\u0105 zbyt du\u017co miejsca w pami\u0119ci i zbyt wolno si\u0119 \u0142adowa\u0107, przez co nie nadaj\u0105 si\u0119 do u\u017cycia z kr\u00f3tko\u017cyj\u0105cymi kontenerami. Na szcz\u0119\u015bcie ta sytuacja zaczyna si\u0119 zmienia\u0107 dzi\u0119ki Quarkus.
\n<\/a><\/noindex><\/p>\n

Super szybka subatomowa Java wesz\u0142a na nowy poziom!<\/h3>\n

\n42 wydania, 8 miesi\u0119cy pracy spo\u0142eczno\u015bci i 177 niesamowitych programist\u00f3w \u2013 efektem tego by\u0142a premiera w listopadzie 2019 roku Quarkus 1.0<\/a><\/noindex>, wydania, kt\u00f3re oznacza wa\u017cny kamie\u0144 milowy w rozwoju projektu i oferuje mn\u00f3stwo \u015bwietnych funkcji i mo\u017cliwo\u015bci (wi\u0119cej informacji mo\u017cna znale\u017a\u0107 w zapowiedzi<\/a><\/noindex>).<\/p>\n

Dzi\u015b opowiemy, jak Quarkus \u0142\u0105czy modele programowania imperatywnego i reaktywnego na bazie jednego reaktywnego rdzenia. Rozpoczniemy od kr\u00f3tkiego rysu historycznego, a nast\u0119pnie szczeg\u00f3\u0142owo om\u00f3wimy, na czym polega dualizm reaktywnego rdzenia Quarkus i jak Java<\/a><\/noindex>-programi\u015bci mog\u0105 skorzysta\u0107 z tych korzy\u015bci.<\/p>\n

Mikroserwisy<\/a><\/noindex>, architektury z zarz\u0105dzanymi zdarzeniami<\/a><\/noindex> i serverless<\/a><\/noindex>-funkcje \u2013 wszystko to dzi\u015b, jak si\u0119 m\u00f3wi, jest na fali. Ostatnio tworzenie chmurowych architektur sta\u0142o si\u0119 znacznie prostsze i bardziej dost\u0119pne, jednak problemy pozosta\u0142y \u2013 szczeg\u00f3lnie w\u015br\u00f3d programist\u00f3w Java. Na przyk\u0142ad, w przypadku funkcji serverless i mikroserwis\u00f3w istnieje pilna potrzeba skr\u00f3cenia czasu uruchamiania, zmniejszenia zu\u017cycia pami\u0119ci i uczynienia ich tworzenia bardziej wygodnym i przyjemnym. Java w ostatnich latach wprowadzi\u0142a kilka udoskonale\u0144, takich jak funkcjonalno\u015b\u0107 ergonomii poprawiona dla kontener\u00f3w itd. Jednak osi\u0105gni\u0119cie prawid\u0142owej pracy Java w kontenerze wci\u0105\u017c jest trudne. Dlatego zaczniemy od om\u00f3wienia niekt\u00f3rych z wewn\u0119trznych trudno\u015bci Java, kt\u00f3re szczeg\u00f3lnie wyra\u017anie ujawniaj\u0105 si\u0119 w czasie tworzenia aplikacji Java opartych na kontenerach.<\/p>\n

Na pocz\u0105tek zwr\u00f3\u0107my uwag\u0119 na histori\u0119.<\/p>\n

\"Jak<\/p>\n

W\u0105tki i kontenery<\/h3>\n

\nZaczynaj\u0105c od wersji 8u131, Java zacz\u0119\u0142a w miar\u0119 dobrze wspiera\u0107 kontenery dzi\u0119ki ulepszeniom w funkcji ergonomii. W szczeg\u00f3lno\u015bci teraz JVM wie, na ilu rdzeniach procesora jest uruchamiana, i mo\u017ce odpowiednio dostosowa\u0107 pule w\u0105tk\u00f3w \u2014 zazwyczaj puli fork\/join. Oczywi\u015bcie, to \u015bwietnie, ale za\u0142\u00f3\u017cmy, \u017ce mamy tradycyjn\u0105 aplikacj\u0119 internetow\u0105, kt\u00f3ra korzysta z serwlet\u00f3w HTTP i jest uruchamiana w Tomcat, Jetty itd. W rezultacie ta aplikacja przydzieli oddzielny w\u0105tek dla ka\u017cdego \u017c\u0105dania i pozwoli mu zablokowa\u0107 ten w\u0105tek podczas oczekiwania na operacje I\/O, na przyk\u0142ad podczas dost\u0119pu do bazy danych, plik\u00f3w lub innych us\u0142ug. To oznacza, \u017ce rozmiar takiej aplikacji nie zale\u017cy od liczby dost\u0119pnych rdzeni, lecz od liczby r\u00f3wnoczesnych \u017c\u0105da\u0144. Ponadto oznacza to, \u017ce kwoty lub limity w Kubernetes dotycz\u0105ce liczby rdzeni nie pomog\u0105 w tym przypadku szczeg\u00f3lnie, a sprawa zako\u0144czy si\u0119 throttlingiem.<\/p>\n

Wycieki pami\u0119ci<\/h3>\n

\nW\u0105tki to pami\u0119\u0107. A wewn\u0119trzne ograniczenia kontener\u00f3w dotycz\u0105ce pami\u0119ci wcale nie s\u0105 panaceum. Po prostu zacznij zwi\u0119ksza\u0107 liczb\u0119 aplikacji i w\u0105tk\u00f3w, a pr\u0119dzej czy p\u00f3\u017aniej napotkasz krytyczny wzrost cz\u0119stotliwo\u015bci prze\u0142\u0105cze\u0144 i, w konsekwencji, degradacj\u0119 wydajno\u015bci. Co wi\u0119cej, je\u015bli aplikacja korzysta z tradycyjnych framework\u00f3w mikroserwisowych lub \u0142\u0105czy si\u0119 z baz\u0105 danych, lub wykorzystuje cache, lub w jakikolwiek inny spos\u00f3b dodatkowo zu\u017cywa pami\u0119\u0107, zdecydowanie potrzebujesz narz\u0119dzia, kt\u00f3re pozwoli zajrze\u0107 do wn\u0119trza JVM i sprawdzi\u0107, jak zarz\u0105dza pami\u0119ci\u0105, przy tym nie zabijaj\u0105c samej JVM (na przyk\u0142ad XX:+UseCGroupMemoryLimitForHeap). I nawet mimo \u017ce, od Java 9, JVM nauczy\u0142a si\u0119 kompatybilno\u015bci z cgroups i odpowiedniego dostosowywania, rezerwacja i zarz\u0105dzanie pami\u0119ci\u0105 pozostaje do\u015b\u0107 skomplikowanym zadaniem.<\/p>\n

Kwoty i limity<\/h3>\n

\nW Java 11 wprowadzono wsparcie dla kwot CPU (np. PreferContainerQuotaForCPUCount). Kubernetes r\u00f3wnie\u017c oferuje wsparcie dla limit\u00f3w i kwot. Tak, to wszystko ma sens, ale je\u015bli aplikacja zn\u00f3w wychodzi poza przydzielon\u0105 kwot\u0119, ponownie dochodzimy do sytuacji, \u017ce rozmiar, jak w przypadku tradycyjnych aplikacji Java, determinowany jest przez liczb\u0119 rdzeni i z przydzieleniem oddzielnego w\u0105tku dla ka\u017cdego \u017c\u0105dania, co oznacza, \u017ce niewiele z tego mo\u017cna skorzysta\u0107.
\nPonadto, korzystaj\u0105c z kwot i limit\u00f3w lub funkcji poziomego (scale-out) skalowania platformy opartej na Kubernetes, problem nie rozwi\u0105zuje si\u0119 sam. Po prostu wydajemy wi\u0119cej zasob\u00f3w na rozwi\u0105zanie pierwotnego problemu, co w ko\u0144cu prowadzi do nadmiernego zu\u017cycia zasob\u00f3w. A je\u015bli jest to system o du\u017cym obci\u0105\u017ceniu w publicznej chmurze, niemal na pewno zaczynamy zu\u017cywa\u0107 wi\u0119cej zasob\u00f3w, ni\u017c jest to rzeczywi\u015bcie potrzebne.<\/p>\n

I co z tym wszystkim zrobi\u0107?<\/h3>\n

\nM\u00f3wi\u0105c prosto, nale\u017cy korzysta\u0107 z asynchronicznych i nieblokuj\u0105cych bibliotek wej\u015bcia\/wyj\u015bcia oraz framework\u00f3w takich jak Netty, Vert.x<\/a><\/noindex> lub Akka. S\u0105 one znacznie lepiej dostosowane do pracy w kontenerach dzi\u0119ki swojej reaktywnej naturze. Dzi\u0119ki nieblokuj\u0105cemu wej\u015bciu\/wyj\u015bciu, ten sam w\u0105tek mo\u017ce obs\u0142ugiwa\u0107 jednocze\u015bnie wiele r\u00f3wnoleg\u0142ych zapyta\u0144. Podczas gdy jedno zapytanie czeka na wyniki wej\u015bcia\/wyj\u015bcia, w\u0105tek je obs\u0142uguj\u0105cy jest zwalniany i przechodzi do obs\u0142ugi innego zapytania. A kiedy wyniki wej\u015bcia\/wyj\u015bcia w ko\u0144cu przychodz\u0105, przetwarzanie pierwszego zapytania jest kontynuowane. Przeplataj\u0105c przetwarzanie zapyta\u0144 w ramach tego samego w\u0105tku, mo\u017cna zmniejszy\u0107 \u0142\u0105czn\u0105 liczb\u0119 w\u0105tk\u00f3w i zredukowa\u0107 zu\u017cycie zasob\u00f3w na przetwarzanie zapyta\u0144.<\/p>\n

W przypadku nieblokuj\u0105cego wej\u015bcia\/wyj\u015bcia liczba rdzeni staje si\u0119 kluczowym parametrem, poniewa\u017c to w\u0142a\u015bnie ona okre\u015bla liczb\u0119 w\u0105tk\u00f3w wej\u015bcia\/wyj\u015bcia, kt\u00f3re mog\u0105 by\u0107 wykonywane r\u00f3wnolegle. Przy odpowiednim wykorzystaniu pozwala to efektywnie rozk\u0142ada\u0107 obci\u0105\u017cenie w\u015br\u00f3d rdzeni i radzi\u0107 sobie z wi\u0119kszymi obci\u0105\u017ceniami przy mniejszych zasobach.<\/p>\n

Jak, to wszystko?<\/h3>\n

\nNie, jest jeszcze co\u015b. Programowanie reaktywne pomaga lepiej wykorzysta\u0107 zasoby, ale te\u017c ma swoj\u0105 cen\u0119. W szczeg\u00f3lno\u015bci, kod b\u0119dzie musia\u0142 by\u0107 przepisany zgodnie z zasadami nieblokowania i unika\u0107 blokowania w\u0105tk\u00f3w wej\u015bcia\/wyj\u015bcia. A to zupe\u0142nie inny model rozwoju i wykonania. I chocia\u017c istnieje wiele u\u017cytecznych bibliotek, to wci\u0105\u017c jest to radykalna zmiana w sposobie my\u015blenia.<\/p>\n

Po pierwsze, musisz nauczy\u0107 si\u0119 pisa\u0107 kod, kt\u00f3ry dzia\u0142a asynchronicznie. Gdy zaczynasz korzysta\u0107 z nieblokuj\u0105cego wej\u015bcia-wyj\u015bcia, musisz wyra\u017anie okre\u015bli\u0107, co ma si\u0119 sta\u0107 po otrzymaniu odpowiedzi na zapytanie. Nie mo\u017cna ju\u017c po prostu blokowa\u0107 i czeka\u0107. Zamiast tego mo\u017cesz przekazywa\u0107 wywo\u0142ania zwrotne, korzysta\u0107 z programowania reaktywnego lub kontynuacji. Ale to nie wszystko: aby korzysta\u0107 z nieblokuj\u0105cego wej\u015bcia-wyj\u015bcia, potrzebujesz zar\u00f3wno nieblokuj\u0105cych serwer\u00f3w, jak i klient\u00f3w, i najlepiej w ka\u017cdej sytuacji. W przypadku HTTP wszystko jest proste, ale s\u0105 te\u017c bazy danych, systemy plik\u00f3w i wiele wi\u0119cej.<\/p>\n

I chocia\u017c ca\u0142kowita reakcja skrajna zapewnia maksymaln\u0105 efektywno\u015b\u0107, takie przesuni\u0119cie mo\u017ce by\u0107 trudne do prze\u0142kni\u0119cia w praktyce. Dlatego mo\u017cliwo\u015b\u0107 \u0142\u0105czenia kodu reaktywnego i imperatywnego staje si\u0119 warunkiem koniecznym, aby:<\/p>\n

    \n
  1. Efektywnie wykorzystywa\u0107 zasoby w najbardziej obci\u0105\u017conych kierunkach systemu oprogramowania;<\/li>\n
  2. U\u017cywa\u0107 prostszego stylowo kodu w pozosta\u0142ych cz\u0119\u015bciach.<\/li>\n<\/ol>\n

    <\/p>\n

    Przedstawiamy Quarkus<\/h3>\n

    \nW\u0142a\u015bciwie to jest sedno Quarkus \u2013 po\u0142\u0105czenie modeli reaktywnych i imperatywnych w ramach jednego \u015brodowiska wykonawczego.<\/p>\n

    Na bazie Quarkus le\u017c\u0105 Vert.x i Netty, na kt\u00f3rych zbudowano szereg reaktywnych framework\u00f3w i rozszerze\u0144 maj\u0105cych na celu pomoc deweloperowi. Quarkus jest przeznaczony do budowy nie tylko mikrous\u0142ug HTTP, ale tak\u017ce architektur opartych na zdarzeniach. Dzi\u0119ki swojej reaktywnej naturze, bardzo efektywnie wsp\u00f3\u0142pracuje z systemami wymiany wiadomo\u015bci (Apache Kafka, AMQP itd.).<\/p>\n

    Ca\u0142a sztuczka polega na tym, jak u\u017cywa\u0107 tego samego reaktywnego silnika zar\u00f3wno dla kodu imperatywnego, jak i reaktywnego.<\/p>\n

    \"Jak<\/p>\n

    Quarkus radzi sobie z tym doskonale. Wyb\u00f3r mi\u0119dzy programowaniem imperatywnym a reaktywnym jest oczywisty \u2013 nale\u017cy u\u017cywa\u0107 reaktywnego rdzenia zar\u00f3wno do jednego, jak i drugiego. A w czym to naprawd\u0119 pomaga, to szybki kod nieblokuj\u0105cy, kt\u00f3ry przetwarza prawie wszystko, co przechodzi przez p\u0119tl\u0119 zdarze\u0144 (event-loop thread, znan\u0105 te\u017c jako IO thread). Ale je\u015bli masz klasyczne aplikacje REST lub aplikacje po stronie klienta, Quarkus ma dla ciebie gotowy imperatywny model programowania. Na przyk\u0142ad wsparcie dla HTTP w Quarkus opiera si\u0119 na u\u017cywaniu nieblokuj\u0105cego i reaktywnego silnika (Eclipse Vert.x i Netty). Wszystkie zapytania HTTP, kt\u00f3re otrzymuje twoja aplikacja, najpierw przechodz\u0105 przez p\u0119tl\u0119 zdarze\u0144 (IO Thread), a nast\u0119pnie s\u0105 przesy\u0142ane do tej cz\u0119\u015bci kodu, kt\u00f3ra zarz\u0105dza zapytaniami. W zale\u017cno\u015bci od miejsca docelowego kod zarz\u0105dzaj\u0105cy zapytaniami mo\u017ce by\u0107 wywo\u0142ywany w ramach osobnego w\u0105tku (tzw. worker thread, u\u017cywane w przypadku serwlet\u00f3w i Jax-RS) lub korzysta\u0107 z pierwotnego w\u0105tku wej\u015bcia-wyj\u015bcia (reaktywny szlak reactive route).<\/p>\n

    \"Jak<\/p>\n

    Dla \u0142\u0105cznik\u00f3w system\u00f3w przesy\u0142ania wiadomo\u015bci u\u017cywane s\u0105 nieblokuj\u0105ce klienty, kt\u00f3re dzia\u0142aj\u0105 na silniku Vert.x. Dzi\u0119ki temu mo\u017cesz efektywnie wysy\u0142a\u0107, odbiera\u0107 i przetwarza\u0107 wiadomo\u015bci z system\u00f3w klasy messaging middleware.<\/p>\n

    Na stronie Quarkus.io<\/a><\/noindex> zebrano kilka dobrych przewodnik\u00f3w, kt\u00f3re pomog\u0105 rozpocz\u0105\u0107 prac\u0119 z Quarkus:<\/p>\n