{"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\/de\/blog\/administrirovanie\/kak-quarkus-obedinyaet-imperativnoe-i-reaktivnoe-programmirovanie","title":{"rendered":"Wie Quarkus imperatives und reaktives Programmieren vereint","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In diesem Jahr planen wir, uns ernsthaft mit dem Thema Containerentwicklung zu besch\u00e4ftigen, Cloud-Native Java<\/a><\/noindex> und Kubernetes<\/a><\/noindex>. Eine logische Fortsetzung dieser Themen wird die Vorstellung des Quarkus-Frameworks sein, das bereits auf Habr\u00e9 behandelt wurde.<\/a><\/noindex> Der heutige Artikel widmet sich nicht nur der Architektur der \u201esubatomaren ultraschnellen Java\u201c, sondern auch den Perspektiven, die Quarkus f\u00fcr Unternehmen mit sich bringt.<\/p>\n

\"Wie
\n
\nJava und JVM sind nach wie vor \u00e4u\u00dferst beliebt, doch bei der Arbeit mit serverlosen Technologien und cloudbasierten Mikrodiensten kommen Java und andere JVM-Sprachen immer seltener zum Einsatz, da sie zu viel Speicherplatz ben\u00f6tigen und zu langsam laden, was sie f\u00fcr den Einsatz in kurzlebigen Containern unpraktisch macht. Gl\u00fccklicherweise beginnt sich diese Situation dank Quarkus gerade zu \u00e4ndern.
\n<\/a><\/noindex><\/p>\n

Die ultraschnelle subatomare Java hat ein neues Level erreicht!<\/h3>\n

\n42 Releases, 8 Monate Community-Arbeit und 177 beeindruckende Entwickler \u2013 dies f\u00fchrte zur Ver\u00f6ffentlichung von Quarkus 1.0<\/a><\/noindex>, einem Release, das einen wichtigen Meilenstein in der Projektentwicklung darstellt und zahlreiche gro\u00dfartige Funktionen und M\u00f6glichkeiten bietet (mehr dar\u00fcber k\u00f6nnen Sie im Ank\u00fcndigung lesen)<\/a><\/noindex>).<\/p>\n

Heute zeigen wir, wie Quarkus Modelle der imperativen und reaktiven Programmierung auf der Grundlage eines einheitlichen reaktiven Kerns vereint. Wir beginnen mit einem kurzen historischen R\u00fcckblick und werden dann detailliert er\u00f6rtern, was den Dualismus des reaktiven Kerns von Quarkus ausmacht und wie Java<\/a><\/noindex>-Entwickler von diesen Vorteilen profitieren k\u00f6nnen.<\/p>\n

Mikroservices<\/a><\/noindex>, ereignisgesteuerten Architekturen<\/a><\/noindex> und serverless<\/a><\/noindex>-Funktionen \u2013 all dies ist heute, was man sozusagen im Trend liegt. Seit kurzem ist die Erstellung von cloud-orientierten Architekturen erheblich einfacher und zug\u00e4nglicher geworden, dennoch bestehen Probleme \u2013 insbesondere f\u00fcr Java-Entwickler. Zum Beispiel besteht bei serverlosen Funktionen und Microservices ein dringender Bedarf, die Startzeit zu verk\u00fcrzen, den Speicherverbrauch zu senken und die Entwicklung insgesamt angenehmer und benutzerfreundlicher zu gestalten. In den letzten Jahren hat Java einige Verbesserungen gebracht, wie optimierte Funktionen f\u00fcr Container und mehr. Doch eine ordnungsgem\u00e4\u00dfe Ausf\u00fchrung von Java in einem Container bleibt nach wie vor eine Herausforderung. Daher beginnen wir mit einer Betrachtung einiger interner Herausforderungen von Java, die besonders stark bei der Entwicklung von containerbasierten Java-Anwendungen hervortreten.<\/p>\n

Zun\u00e4chst werfen wir einen Blick auf die Geschichte.<\/p>\n

\"Wie<\/p>\n

Threads und Container<\/h3>\n

\nMit der Version 8u131 hat Java begonnen, Container besser zu unterst\u00fctzen, dank Verbesserungen in der Ergonomie-Funktionalit\u00e4t. Insbesondere wei\u00df die JVM jetzt, auf wie vielen Prozessorkernen sie l\u00e4uft und kann entsprechend die Thread-Pools anpassen \u2013 typischerweise Fork\/Join-Pools. Das ist zweifellos gro\u00dfartig, aber nehmen wir an, wir haben eine traditionelle Webanwendung, die HTTP-Servlets nutzt und auf Tomcat, Jetty und anderen Plattformen l\u00e4uft. In diesem Fall wird die Anwendung f\u00fcr jede Anfrage einen eigenen Thread erzeugen und diesen Thread blockieren, w\u00e4hrend sie auf Eingabe-\/Ausgabeoperationen wartet, beispielsweise beim Zugriff auf Datenbanken, Dateien oder andere Dienste. Das bedeutet, dass die Gr\u00f6\u00dfe einer solchen Anwendung nicht von der Anzahl der verf\u00fcgbaren Kerne abh\u00e4ngt, sondern von der Anzahl der gleichzeitigen Anfragen. Dar\u00fcber hinaus bedeutet dies, dass Quoten oder Limits in Kubernetes bez\u00fcglich der Anzahl der Kerne hier nicht wirklich helfen werden, und letztendlich wird es zu Drosselungen f\u00fchren.<\/p>\n

Speicherersch\u00f6pfung<\/h3>\n

\nThreads sind der Speicher. Und interne containerbezogene Speicherbeschr\u00e4nkungen sind keineswegs die L\u00f6sung f\u00fcr alle Probleme. Beginnen Sie einfach damit, die Anzahl der Anwendungen und Threads zu erh\u00f6hen, und irgendwann werden Sie unweigerlich mit einer kritischen Zunahme der Kontextwechselraten konfrontiert, was wiederum die Leistung beeintr\u00e4chtigt. Dar\u00fcber hinaus, wenn Ihre Anwendung traditionelle Microservices-Frameworks verwendet, mit Datenbanken verbunden ist, Caching nutzt oder auf andere Weise zus\u00e4tzlichen Speicher verbraucht, ben\u00f6tigen Sie definitiv ein Werkzeug, das Ihnen einen Einblick in die JVM gew\u00e4hrt und zeigt, wie sie den Speicher verwaltet, ohne die JVM selbst zu gef\u00e4hrden (zum Beispiel XX:+UseCGroupMemoryLimitForHeap). Und selbst wenn die JVM seit Java 9 in der Lage ist, cgroups zu erkennen und sich entsprechend anzupassen, bleibt die Reservierung und Verwaltung von Speicher eine recht komplexe Angelegenheit.<\/p>\n

Kontingente und Limits<\/h3>\n

\nIn Java 11 gibt es Unterst\u00fctzung f\u00fcr CPU-Quotas (zum Beispiel PreferContainerQuotaForCPUCount). Kubernetes bietet ebenfalls Unterst\u00fctzung f\u00fcr Limits und Quotas. Das ist sinnvoll, aber wenn die Anwendung erneut die zugewiesene Quote \u00fcbersteigt, gelangen wir wieder zu der Frage, wie bei traditionellen Java-Anwendungen, n\u00e4mlich dass die Gr\u00f6\u00dfe nach der Anzahl der Kerne bestimmt wird und jedem Request ein separater Thread zugewiesen wird. Das bringt unterm Strich nicht viel.
\nDar\u00fcber hinaus wird durch die Verwendung von Quotas und Limits oder den Funktionen der horizontalen Skalierung der zugrunde liegenden Kubernetes-Plattform das Problem nicht gel\u00f6st. Wir verschwenden einfach mehr Ressourcen, um das urspr\u00fcngliche Problem zu l\u00f6sen, oder landen schlie\u00dflich in einer Situation mit Ressourcen\u00fcberverbrauch. In einem hochbelasteten System in einer \u00f6ffentlichen Cloud verwenden wir wahrscheinlich viel mehr Ressourcen, als tats\u00e4chlich n\u00f6tig w\u00e4ren.<\/p>\n

Was kann man mit all dem anfangen?<\/h3>\n

\nEinfach gesagt, sollte man asynchrone und nicht blockierende Ein- und Ausgabebibliotheken sowie Frameworks wie Netty verwenden, Vert.x<\/a><\/noindex> oder Akka. Sie sind deutlich besser geeignet f\u00fcr Container-Anwendungen aufgrund ihrer reaktiven Natur. Dank der nicht-blockierenden Eingabe\/Ausgabe kann derselbe Thread mehrere gleichzeitige Anfragen bearbeiten. W\u00e4hrend eine Anfrage auf Eingabe\/Ausgabe-Ergebnisse wartet, wird der sie verarbeitende Thread freigegeben und bearbeitet eine andere Anfrage. Sobald die Ergebnisse der Eingabe\/Ausgabe eintreffen, wird die Bearbeitung der ersten Anfrage fortgesetzt. Durch die alternierende Bearbeitung von Anfragen innerhalb desselben Threads kann die Gesamtzahl der Threads verringert und der Ressourcenverbrauch f\u00fcr die Bearbeitung von Anfragen gesenkt werden.<\/p>\n

Bei nicht-blockierender Eingabe\/Ausgabe wird die Anzahl der Kerne zu einem entscheidenden Parameter, da sie bestimmt, wie viele Eingabe\/Ausgabe-Threads parallel ausgef\u00fchrt werden k\u00f6nnen. Bei richtiger Verwendung erm\u00f6glicht dies eine effiziente Lastverteilung zwischen den Kernen und die Bew\u00e4ltigung h\u00f6herer Lasten mit weniger Ressourcen.<\/p>\n

Wie, und das war's?<\/h3>\n

\nNein, es gibt noch mehr. Reaktive Programmierung hilft, Ressourcen effizienter zu nutzen, hat aber auch ihren Preis. Insbesondere muss der Code entsprechend den Prinzipien der Nichtblockierung umgeschrieben werden, um eine Blockierung von Ein-\/Ausgabestr\u00f6men zu vermeiden. Das erfordert ein ganz anderes Entwicklungs- und Ausf\u00fchrungsmodell. Und obwohl es viele n\u00fctzliche Bibliotheken gibt, ist es dennoch ein radikaler Wandel in der gewohnten Denkweise.<\/p>\n

Zun\u00e4chst m\u00fcssen Sie lernen, Code zu schreiben, der asynchron ausgef\u00fchrt wird. Sobald Sie mit nicht blockierenden Ein-\/Ausgaben arbeiten, m\u00fcssen Sie ausdr\u00fccklich angeben, was passieren soll, wenn eine Antwort auf die Anfrage eintrifft. Einfach blockieren und warten funktioniert nicht mehr. Stattdessen k\u00f6nnen Sie R\u00fcckrufe \u00fcbergeben, reaktive Programmierung verwenden oder Fortsetzungen nutzen. Aber das ist noch nicht alles: Um nicht blockierende Ein-\/Ausgaben zu verwenden, ben\u00f6tigen Sie ebenfalls nicht blockierende Server und Clients, idealerweise \u00fcberall. Bei HTTP ist das einfach, aber es gibt auch Datenbanken, Dateisysteme und vieles mehr.<\/p>\n

Obwohl eine vollst\u00e4ndige durchg\u00e4ngige Reaktivit\u00e4t maximale Effizienz bietet, kann ein solcher Wandel in der Praxis schwierig umzusetzen sein. Daher wird die M\u00f6glichkeit, reaktiven und imperativen Code zu kombinieren, zu einer wesentlichen Voraussetzung f\u00fcr:<\/p>\n

    \n
  1. Die Ressourcen in den am st\u00e4rksten belasteten Bereichen des Softwaresystems effektiv zu nutzen;<\/li>\n
  2. In den anderen Teilen einen einfacheren Code-Stil zu verwenden.<\/li>\n<\/ol>\n

    <\/p>\n

    Pr\u00e4sentation von Quarkus<\/h3>\n

    \nDarum geht es bei Quarkus \u2013 die reaktiven und imperativen Modelle in einer einzigen Laufzeitumgebung zu vereinen.<\/p>\n

    Quarkus basiert auf Vert.x und Netty, \u00fcber denen eine Reihe von reaktiven Frameworks und Erweiterungen genutzt wird, um den Entwicklern zu helfen. Quarkus ist nicht nur f\u00fcr die Erstellung von HTTP-Mikroservicen, sondern auch f\u00fcr ereignisgesteuerte Architekturen gedacht. Aufgrund seiner reaktiven Natur arbeitet es \u00e4u\u00dferst effizient mit Nachrichten\u00fcbertragungssystemen (Apache Kafka, AMQP usw.).<\/p>\n

    Der ganze Trick liegt darin, denselben reaktiven Motor sowohl f\u00fcr imperativen als auch f\u00fcr reaktiven Code zu verwenden.<\/p>\n

    \"Wie<\/p>\n

    Quarkus meistert das hervorragend. Die Wahl zwischen imperativem und reaktivem Programmierungsansatz ist klar \u2013 nutzen Sie f\u00fcr beides den reaktiven Kern. Dabei unterst\u00fctzt es besonders gut beim schnellen, nicht blockierenden Code, der fast alles verarbeitet, was durch den Ereignisloop (event-loop thread oder auch IO thread) l\u00e4uft. Wenn Sie jedoch klassische REST-Anwendungen oder clientseitige Anwendungen haben, h\u00e4lt Quarkus die imperative Programmiermodelle bereit. Beispielsweise basiert die HTTP-Unterst\u00fctzung in Quarkus auf der Nutzung eines nicht blockierenden und reaktiven Engines (Eclipse Vert.x und Netty). Alle HTTP-Anfragen, die Ihre Anwendung erh\u00e4lt, durchlaufen zun\u00e4chst den Ereignisloop (IO Thread) und werden dann an den Teil des Codes weitergeleitet, der die Anfragen verwaltet. Je nach Zielort kann der Anfrageverwaltungs-Code in einem separaten Thread (dem sogenannten Worker Thread, was bei Servlets und Jax-RS der Fall ist) aufgerufen werden oder den urspr\u00fcnglichen Eingabe-\/Ausgabethread (reaktiver Route) nutzen.<\/p>\n

    \"Wie<\/p>\n

    F\u00fcr Nachrichtensysteme werden nicht blockierende Clients verwendet, die auf der Vert.x-Engine basieren. Dadurch k\u00f6nnen Sie Nachrichten von Messaging-Middleware-Systemen effizient senden, empfangen und verarbeiten.<\/p>\n

    Auf der Website Quarkus.io<\/a><\/noindex> finden Sie eine Reihe n\u00fctzlicher Anleitungen, die Ihnen den Einstieg in Quarkus erleichtern:<\/p>\n