{"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, die Themen Container ernsthaft voranzutreiben, Cloud-Native Java<\/a><\/noindex> und Kubernetes<\/a><\/noindex>. Eine logische Fortsetzung dieser Themen wird die Vorstellung des Frameworks Quarkus sein, das bereits auf Habr\u00e9 behandelt wurde. Der heutige Artikel widmet sich nicht so sehr der Funktionsweise der \u201esubatomaren super schnellen Java\u201c, sondern den Perspektiven, die Quarkus in das Unternehmensumfeld einbringt.<\/a><\/noindex> Java und die JVM sind nach wie vor \u00e4u\u00dferst beliebt, aber bei der Arbeit mit serverlosen Technologien und cloud-orientierten Mikrodiensten werden Java und andere Sprachen f\u00fcr die JVM zunehmend seltener verwendet, da sie zu viel Speicherplatz beanspruchen und zu langsam laden, wodurch sie sich schlecht f\u00fcr den Einsatz mit kurzlebigen Containern eignen. Gl\u00fccklicherweise beginnt sich diese Situation dank Quarkus derzeit zu \u00e4ndern.<\/p>\n

\"Wie
\n
\nDie ultra-schnelle subatomare Java hat ein neues Niveau erreicht!
\n<\/a><\/noindex><\/p>\n

42 Releases, 8 Monate Community-Arbeit und 177 erstaunliche Entwickler \u2013 das Ergebnis ist die Ver\u00f6ffentlichung von<\/h3>\n

\nQuarkus 1.0 , einem Release, das einen wichtigen Meilenstein in der Entwicklung des Projekts darstellt und viele coole Funktionen und M\u00f6glichkeiten bietet (mehr dazu k\u00f6nnen Sie lesen in<\/a><\/noindex>Heute werden wir dar\u00fcber sprechen, wie Quarkus die Modelle imperativer und reaktiver Programmierung auf der Basis eines einheitlichen reaktiven Kerns kombiniert. Wir beginnen mit einem kurzen Ausflug in die Geschichte und besch\u00e4ftigen uns dann im Detail mit dem Dualismus des reaktiven Kerns von Quarkus und wie der Ank\u00fcndigung<\/a><\/noindex>).<\/p>\n

-Entwickler diese Vorteile nutzen k\u00f6nnen. Java<\/a><\/noindex>Ereignisgesteuerte Architekturen von Mikrodiensten<\/p>\n

serverless<\/a><\/noindex>, -Funktionen \u2013 all dies ist heutzutage, wie man so sagt, im Aufwind. Seit kurzem ist es viel einfacher und zug\u00e4nglicher geworden, cloud-orientierte Architekturen zu erstellen, jedoch sind Probleme geblieben \u2013 insbesondere f\u00fcr Java-Entwickler. So besteht beispielsweise bei serverlosen Funktionen und Mikrodiensten ein akuter Bedarf, die Startzeit zu verk\u00fcrzen, den Speicherverbrauch zu senken und die Entwicklung angenehmer und komfortabler zu gestalten. In den letzten Jahren hat Java mehrere Verbesserungen hervorgebracht, wie z. B. ein \u00fcberarbeitetes Ergonomie-Feature f\u00fcr Container und mehr. Dennoch bleibt es schwierig, eine ordnungsgem\u00e4\u00dfe Funktionsweise von Java in einem Container zu erreichen. Deshalb beginnen wir mit einer Betrachtung einiger der internen Herausforderungen von Java, die besonders stark beim Entwickeln von containerorientierten Java-Anwendungen zutage treten.<\/a><\/noindex> und -Funktionen \u2013 all das ist heute, sozusagen, im Aufstieg. In letzter Zeit ist die Erstellung cloud-orientierter Architekturen viel einfacher und zug\u00e4nglicher geworden, jedoch bestehen die Probleme fort \u2013 besonders f\u00fcr Java-Entwickler. Beispielsweise besteht bei serverlosen Funktionen und Mikrodiensten ein akuter Bedarf, die Startzeit zu verk\u00fcrzen, den Speicherverbrauch zu reduzieren und die Entwicklung angenehmer und benutzerfreundlicher zu gestalten. Java hat in den letzten Jahren einige Verbesserungen eingef\u00fchrt, wie z. B. die Ergonomie-Funktionalit\u00e4t f\u00fcr Container usw. Doch die ordnungsgem\u00e4\u00dfe Funktion von Java in einem Container bleibt nach wie vor eine Herausforderung. Daher werden wir zun\u00e4chst einige der internen Herausforderungen von Java betrachten, die sich besonders bei der Entwicklung containerorientierter Java-Anwendungen deutlich zeigen.<\/a><\/noindex>-Funktionen \u2013 all das ist heute, was man nennt, auf dem Vormarsch. Seit kurzem ist die Erstellung von cloudbasierten Architekturen viel einfacher und zug\u00e4nglicher geworden, jedoch sind die Probleme geblieben \u2013 insbesondere f\u00fcr Java-Entwickler. Beispielsweise gibt es bei serverlosen Funktionen und Mikrodiensten einen akuten Bedarf, die Startzeit zu verk\u00fcrzen, den Speicherbedarf zu reduzieren und die Entwicklung benutzerfreundlicher und angenehmer zu gestalten. In den letzten Jahren hat Java einige Verbesserungen eingebracht, wie die \u00fcberarbeitete Ergonomie f\u00fcr Container und \u00c4hnliches. Dennoch bleibt es nach wie vor schwierig, Java in einem Container ordnungsgem\u00e4\u00df zum Laufen zu bringen. Daher werden wir zun\u00e4chst einige der internen Herausforderungen von Java betrachten, die sich besonders bei der Entwicklung von containerbasierten Java-Anwendungen scharf zeigen.<\/p>\n

Lassen Sie uns zun\u00e4chst einen Blick auf die Geschichte werfen.<\/p>\n

\"Wie<\/p>\n

Threads und Container<\/h3>\n

\nSeit Version 8u131 unterst\u00fctzt Java mehr oder weniger Container durch Verbesserungen in der Ergonomie-Funktionalit\u00e4t. Insbesondere wei\u00df die JVM jetzt, auf wie vielen Prozessorkernen sie ausgef\u00fchrt wird und kann die Thread-Pools entsprechend anpassen \u2013 in der Regel Fork\/Join-Pools. Das ist sicherlich gro\u00dfartig, aber nehmen wir an, wir haben eine traditionelle Webanwendung, die HTTP-Servlets nutzt und in Tomcat, Jetty und \u00e4hnlichem l\u00e4uft. Infolgedessen erzeugt diese Anwendung f\u00fcr jede Anfrage einen separaten Thread und erm\u00f6glicht es ihm, diesen Thread w\u00e4hrend der Wartezeit auf Ein- und Ausgabeoperationen, z. B. beim Zugriff auf Datenbanken, Dateien oder andere Dienste, zu blockieren. Das bedeutet, dass die Gr\u00f6\u00dfe einer solchen Anwendung nicht von der Anzahl der verf\u00fcgbaren Kerne abh\u00e4ngt, sondern von der Anzahl gleichzeitiger Anfragen. Dar\u00fcber hinaus bedeutet dies, dass Quoten oder Limits in Kubernetes bez\u00fcglich der Anzahl der Kerne hier nicht wirklich helfen, und letztendlich wird dies zu Drosselung f\u00fchren.<\/p>\n

Speicherersch\u00f6pfung<\/h3>\n

\nThreads sind Speicher. Und interne Container-Speichereinschr\u00e4nkungen sind keineswegs eine Allheilmittel. Fangen Sie einfach an, die Anzahl der Anwendungen und Threads zu erh\u00f6hen, und fr\u00fcher oder sp\u00e4ter werden Sie mit einem kritischen Anstieg der Kontextwechselrate konfrontiert sein, was wiederum zu einer Verschlechterung der Leistung f\u00fchrt. Dar\u00fcber hinaus, wenn die Anwendung traditionelle Mikrodienst-Frameworks verwendet oder sich mit Datenbanken verbindet oder Caching nutzt oder anderweitig zus\u00e4tzlichen Speicher verbraucht, ben\u00f6tigen Sie offensichtlich ein Werkzeug, das es Ihnen erm\u00f6glicht, in die JVM hinein zu sehen und zu beobachten, wie sie den Speicher verwaltet, ohne dabei die JVM selbst zu zerst\u00f6ren (z. B. XX:+UseCGroupMemoryLimitForHeap). Und selbst wenn die JVM seit Java 9 gelernt hat, cgroups zu erkennen und sich entsprechend anzupassen, bleibt das Reservieren und Verwalten von Speicher eine ziemlich komplexe Angelegenheit.<\/p>\n

Quoten und Limits<\/h3>\n

\nIn Java 11 wurde die Unterst\u00fctzung f\u00fcr CPU-Quoten (wie PreferContainerQuotaForCPUCount) eingef\u00fchrt. Kubernetes bietet ebenfalls Unterst\u00fctzung f\u00fcr Limits und Quoten. Ja, das alles macht Sinn, aber wenn die Anwendung erneut die zugewiesene Quote \u00fcberschreitet, kommen wir wieder zu der Situation, dass die Gr\u00f6\u00dfe \u2013 wie im Fall traditioneller Java-Anwendungen \u2013 nach der Anzahl der Kerne bestimmt wird, wobei f\u00fcr jede Anfrage ein separater Thread zugewiesen wird, was bedeutet, dass all dies nur wenig n\u00fctzt.
\nDar\u00fcber hinaus l\u00f6sen die Verwendung von Quoten und Limits oder von Funktionen zur horizontalen Skalierung (Scale-Out) der zugrunde liegenden Kubernetes-Plattform das Problem nicht von selbst. Wir investieren einfach mehr Ressourcen, um das urspr\u00fcngliche Problem zu l\u00f6sen, oder landen schlie\u00dflich bei einer \u00dcbernutzung von Ressourcen. Und wenn es sich um ein stark ausgelastetes System in einer \u00f6ffentlichen Cloud handelt, beginnen wir nahezu sicher, mehr Ressourcen zu verwenden, als tats\u00e4chlich erforderlich sind.<\/p>\n

Und was ist mit all dem zu tun?<\/h3>\n

\nEinfach ausgedr\u00fcckt, sollten asynchrone und nicht-blockierende E\/A-Bibliotheken sowie Frameworks wie Netty verwendet werden, Vert.x<\/a><\/noindex> oder Akka. Diese eignen sich aufgrund ihrer reaktiven Natur viel besser f\u00fcr die Arbeit in Containern. Dank der nicht-blockierenden E\/A kann der gleiche Thread mehrere gleichzeitige Anfragen gleichzeitig bearbeiten. W\u00e4hrend eine Anfrage auf Ergebnisse von E\/A wartet, wird der sie bearbeitende Thread freigegeben und k\u00fcmmert sich um eine andere Anfrage. Und wenn die Ergebnisse der E\/A endlich eintreffen, wird die Bearbeitung der ersten Anfrage fortgesetzt. Durch die Abwechselung der Bearbeitung von Anfragen innerhalb desselben Threads l\u00e4sst sich die Gesamtzahl der Threads reduzieren und der Ressourcenverbrauch bei der Bearbeitung von Anfragen verringern.<\/p>\n

Bei nicht-blockierender E\/A wird die Anzahl der Kerne zum entscheidenden Parameter, da sie die Anzahl der E\/A-Threads bestimmt, die parallel ausgef\u00fchrt werden k\u00f6nnen. Bei richtiger Nutzung erm\u00f6glicht dies eine effiziente Verteilung der Last auf die Kerne und die Bew\u00e4ltigung h\u00f6herer Lasten mit weniger Ressourcen.<\/p>\n

Wie, und das ist alles?<\/h3>\n

\nNein, es gibt noch mehr. Reaktive Programmierung hilft, Ressourcen besser zu nutzen, hat aber auch ihren Preis. Insbesondere muss der Code gem\u00e4\u00df den Prinzipien der Nichtblockierbarkeit umgeschrieben werden und die Blockierung von E\/A-Threads muss vermieden werden. Das ist eine ganz andere Entwicklungs- und Ausf\u00fchrungsweise. Und obwohl es hier viele n\u00fctzliche Bibliotheken gibt, ist es dennoch ein radikaler Wechsel der gewohnten Denkweise.<\/p>\n

Zun\u00e4chst m\u00fcssen Sie lernen, Code zu schreiben, der asynchron ausgef\u00fchrt wird. Sobald Sie mit nicht blockierendem Input-Output beginnen, m\u00fcssen Sie ausdr\u00fccklich festlegen, was geschehen soll, wenn eine Antwort auf die Anfrage eingeht. 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 blockierenden Input-Output zu verwenden, ben\u00f6tigen Sie auch nicht blockierende Server und Clients, idealerweise \u00fcberall. Im Fall von HTTP ist alles einfach, aber es gibt auch Datenbanken und Dateisysteme und vieles mehr.<\/p>\n

Obwohl totale durchg\u00e4ngig reaktive Programmierung maximale Effizienz bietet, ist es in der Praxis oft schwierig, einen solchen Wechsel zu verarbeiten. Daher wird die F\u00e4higkeit, reaktiven und imperativen Code zu kombinieren, eine wesentliche Voraussetzung daf\u00fcr, dass:<\/p>\n

    \n
  1. Ressourcen in den am st\u00e4rksten belasteten Bereichen des Softwaresystems effizient genutzt werden;<\/li>\n
  2. ein einfacher gestalteter Code in den anderen Teilen verwendet werden kann.<\/li>\n<\/ol>\n

    <\/p>\n

    Wir pr\u00e4sentieren Quarkus<\/h3>\n

    \nGenau das ist die Essenz von Quarkus \u2013 die Vereinigung von reaktiven und imperativen Modellen innerhalb einer Laufzeitumgebung.<\/p>\n

    Quarkus basiert auf Vert.x und Netty, \u00fcber denen eine Vielzahl von reaktiven Frameworks und Erweiterungen eingesetzt werden, die dem Entwickler helfen sollen. Quarkus ist nicht nur f\u00fcr den Bau von HTTP-Mikroservices gedacht, sondern auch f\u00fcr ereignisgesteuerte Architekturen. Dank seiner reaktiven Natur arbeitet es sehr effizient mit Nachrichtensystemen (Apache Kafka, AMQP usw.).<\/p>\n

    Die ganze Kunst besteht darin, denselben reaktiven Motor sowohl f\u00fcr imperativen als auch f\u00fcr reaktiven Code zu nutzen.<\/p>\n

    \"Wie<\/p>\n

    Quarkus bew\u00e4ltigt dies gl\u00e4nzend. Die Wahl zwischen imperativen und reaktiven Ans\u00e4tzen ist offensichtlich \u2013 sowohl f\u00fcr den einen als auch f\u00fcr den anderen das reaktive Kernsystem zu verwenden. Dabei hilft es besonders gut mit schnellem, nicht-blockierendem Code, der nahezu alles verarbeitet, was durch den Ereignis-Loop-Thread (event-loop thread, auch bekannt als IO-Thread) l\u00e4uft. Aber wenn Sie klassische REST-Anwendungen oder clientseitige Anwendungen haben, hat Quarkus ein imperatives Programmiermodell bereit. Zum Beispiel basiert die Unterst\u00fctzung von HTTP in Quarkus auf der Verwendung eines nicht-blockierenden reaktiven Engines (Eclipse Vert.x und Netty). Alle HTTP-Anfragen, die Ihre Anwendung erh\u00e4lt, durchlaufen zun\u00e4chst den Ereignis-Loop (IO-Thread), bevor sie an den Teil des Codes gesendet werden, der die Anfragen steuert. Je nach Ziel kann der Steuerungscode innerhalb eines separaten Threads (dem sogenannten worker thread, verwendet bei Servlets und Jax-RS) aufgerufen werden oder den urspr\u00fcnglichen Eingabe-\/Ausgabe-Stream verwenden (reaktiver Pfad reactive route).<\/p>\n

    \"Wie<\/p>\n

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

    Auf der Website Quarkus.io<\/a><\/noindex> es wurden mehrere gute Anleitungen zusammengestellt, die Ihnen den Einstieg in Quarkus erleichtern:<\/p>\n