Ĉi-jare ni planas serioze disvolvi ujajn temojn, и . Logika daŭrigo de ĉi tiuj temoj estos rakonto pri la Quarkus-kadro, jam sur Habré. La hodiaŭa artikolo temas malpli pri la dezajno de "subatoma superrapida Java" kaj pli pri la promeso, kiun Quarkus alportas al Enterprise.
Java kaj JVM daŭre estas ege popularaj, sed kiam ili laboras kun senservilaj teknologioj kaj nubo-denaskaj mikroservoj, Java kaj aliaj JVM-lingvoj estas uzataj malpli kaj malpli ĉar ili okupas tro da memorspaco kaj estas tro malrapidaj por ŝarĝi, igante ilin. malbone taŭga por uzo kun mallongdaŭraj ujoj. Feliĉe, ĉi tiu situacio nun komencas ŝanĝiĝi danke al Quarkus.
Superrapida subatoma Java atingis novan nivelon!
42 eldonoj, 8 monatoj da komunuma laboro kaj 177 mirindaj programistoj - la rezulto de ĉio estis la eldono en novembro 2019 , eldono kiu markas gravan mejloŝtonon en la evoluo de la projekto kaj ofertas multajn bonegajn funkciojn kaj kapablojn (vi povas legi pli pri ili en ).
Hodiaŭ ni montros al vi kiel Quarkus kombinas imperativajn kaj reaktivajn programajn modelojn en ununuran reaktivan kernon. Ni komencos kun mallonga historio kaj poste eniros en detalojn pri kio estas la reaktiva kerna dualismo de Quarkus kaj kiel -Programistoj povas utiligi ĉi tiujn avantaĝojn.
, и -funkcioj – ĉio ĉi, kiel oni diras, pligrandiĝas hodiaŭ. Lastatempe, la kreado de nubo-centraj arkitekturoj fariĝis multe pli facila kaj pli alirebla, sed problemoj restas - precipe por Java-programistoj. Ekzemple, en la kazo de senservilaj funkcioj kaj mikroservoj, estas urĝa bezono redukti ektempon, redukti memorkonsumon, kaj ankoraŭ fari ilian disvolviĝon pli oportuna kaj ĝuebla. Java faris plurajn plibonigojn en la lastaj jaroj, kiel plibonigita ergonomia funkcieco por ujoj ktp. Tamen, ke Java funkciu ĝuste en ujo ankoraŭ estas malfacila. Do ni komencos rigardante kelkajn el la enecaj kompleksecoj de Java, kiuj estas precipe akraj dum disvolvado de uj-orientitaj Java-aplikoj.
Unue, ni rigardu historion.
Rovoj kaj ujoj
Komencante kun versio 8u131, Java komencis pli-malpli subteni ujojn pro plibonigoj en ergonomia funkcieco. Aparte, la JVM nun scias kiom da procesoraj kernoj ĝi funkcias kaj povas agordi fadenajn naĝejojn—tipe forki/kunigi naĝejojn—konforme. Kompreneble, ĉi tio estas bonega, sed ni diru, ke ni havas tradician TTT-aplikaĵon kiu uzas HTTP-servletojn kaj funkcias en Tomcat, Jetty, ktp. Kiel rezulto, ĉi tiu aplikaĵo donos al ĉiu peto apartan fadenon kaj permesos al ĝi bloki ĉi tiun fadenon dum atendado de I/O-operacioj, ekzemple, kiam vi aliras la datumbazon, dosierojn aŭ aliajn servojn. Tio estas, la grandeco de tia aplikaĵo ne dependas de la nombro da disponeblaj kernoj, sed de la nombro de samtempaj petoj. Krome, ĉi tio signifas, ke kvotoj aŭ limoj en Kubernetes pri la nombro da kernoj ne multe helpos ĉi tie, kaj la afero finfine finiĝos per strekado.
Memorelĉerpiĝo
Fadenoj estas memoro. Kaj limigoj de memoro en la ujo tute ne estas panaceo. Nur komencu pliigi la nombron da aplikoj kaj fadenoj, kaj baldaŭ aŭ malfrue vi renkontos kritikan pliiĝon en ŝanĝfrekvenco kaj, kiel rezulto, rendimento-malboniĝo. Ankaŭ, se via aplikaĵo uzas tradiciajn mikroservajn kadrojn, aŭ konektas al datumbazo, aŭ uzas kaŝmemoron, aŭ alie uzas memoron, vi evidente bezonas ilon, kiu ebligas al vi rigardi en la JVM kaj vidi kiel ĝi administras memoron sen mortigi ĝin. JVM mem (ekzemple XX:+UseCGroupMemoryLimitForHeap). Kaj kvankam, ekde Java 9, la JVM lernis akcepti cgrupojn kaj adaptiĝi laŭe, rezervi kaj administri memoron restas sufiĉe kompleksa afero.
Kvotoj kaj limoj
Java 11 lanĉis subtenon por CPU-kvotoj (kiel PreferContainerQuotaForCPUCount). Kubernetes ankaŭ ofertas subtenon por limoj kaj kvotoj. Jes, ĉi tio ĉio havas sencon, sed se la aplikaĵo denove superas la asignitan kvoton, ni denove finiĝas kun la grandeco - kiel estas la kazo kun tradiciaj Java-aplikoj - determinita de la nombro da kernoj kaj kun la asigno de aparta fadeno por ĉiu. peto, tiam estas malmulte da senco en ĉio ĉi.
Krome, se vi uzas kvotojn kaj limojn aŭ la skalo-eksterigajn funkciojn de la platformo sub Kubernetes, la problemo ankaŭ ne solvas sin. Ni simple elspezas pli da rimedoj por solvi la originan problemon aŭ finas tro elspezi. Kaj se ĝi estas alta ŝarĝa sistemo en publika publika nubo, ni preskaŭ certe finas uzi pli da rimedoj ol ni vere bezonas.
Kaj kion fari kun ĉio ĉi?
Por diri simple, uzu nesinkronajn kaj ne-blokantajn I/O-bibliotekojn kaj kadrojn kiel Netty, aŭ Akka. Ili multe pli taŭgas por labori en ujoj pro sia reaktiva naturo. Danke al ne-bloka I/O, la sama fadeno povas prilabori plurajn samtempajn petojn. Dum unu peto atendas I/O-rezultojn, la fadena prilaborado ĝi estas liberigita kaj transprenita de alia peto. Kaj kiam la I/O-rezultoj finfine alvenas, la prilaborado de la unua peto daŭras. Per interplektita prilaborado de petoj ene de la sama fadeno, vi povas redukti la totalan nombron da fadenoj kaj redukti la konsumon de rimedoj por prilaborado de petoj.
Kun ne-bloka I/O, la nombro da kernoj iĝas ŝlosila parametro ĉar ĝi determinas la nombron da I/O-fadenoj kiuj povas esti efektivigitaj paralele. Se uzata ĝuste, ĉi tio ebligas al vi efike distribui la ŝarĝon inter kernoj kaj trakti pli altajn laborŝarĝojn kun malpli da rimedoj.
Kiel, tio estas ĉio?
Ne, estas io alia. Reaktiva programado helpas pli bone uzi rimedojn, sed ankaŭ havas prezon. Precipe, la kodo devos esti reverkita laŭ la principoj de ne-blokado kaj eviti blokadon de I/O-fadenoj. Kaj ĉi tio estas tute malsama modelo de evoluo kaj ekzekuto. Kaj kvankam ĉi tie estas multaj utilaj bibliotekoj, tamen ĝi estas radikala ŝanĝo en la kutima pensmaniero.
Unue, vi devas lerni kiel skribi kodon, kiu funkcias nesinkrone. Post kiam vi komencas uzi ne-blokan I/O, vi devas eksplicite specifi kio devus okazi kiam respondo al peto estas ricevita. Simple blokado kaj atendado ne plu funkcios. Anstataŭe, vi povas pasi revokojn, uzi reaktivan programadon aŭ daŭrigon. Sed tio ne estas ĉio: por uzi ne-blokan I/O, oni bezonas kaj ne-blokantajn servilojn kaj klientojn, prefere ĉie. En la kazo de HTTP, ĉio estas simpla, sed ekzistas ankaŭ datumbazoj, dosiersistemoj, kaj multe pli.
Kaj kvankam totala fin-al-fina reagemo maksimumigas efikecon, tia ŝanĝo povas esti malfacile stomako en praktiko. Tial, la kapablo kombini reaktivan kaj imperativan kodon iĝas antaŭkondiĉo por:
- Efike uzu rimedojn en la plej ŝarĝitaj areoj de la programara sistemo;
- Uzu pli simplan stilkodon en ĝiaj ceteraj partoj.
Prezentante Quarkus
Efektive, ĉi tio estas la esenco de Quarkus - kombini reaktivajn kaj imperativajn modelojn ene de ununura rultempa medio.
Quarkus baziĝas sur Vert.x kaj Netty, kun gamo da reaktivaj kadroj kaj etendaĵoj supre por helpi la programiston. Quarkus estas desegnita por konstrui ne nur HTTP-mikroservojn, sed ankaŭ arkitekturojn gvidatajn de eventoj. Pro sia reaktiva naturo, ĝi funkcias tre efike kun mesaĝsistemoj (Apache Kafka, AMQP, ktp.).
La lertaĵo estas kiel uzi la saman reaktivan motoron por kaj imperativa kaj reaktiva kodo.
Quarkus faras tion brile. La elekto inter imperativo kaj reaktiva estas evidenta - uzu reaktivan kernon por ambaŭ. Kion ĝi vere helpas estas rapida, ne-bloka kodo, kiu pritraktas preskaŭ ĉion, kio pasas tra la evento-buklofadeno, alinome IO-fadeno. Sed se vi havas klasikajn REST aŭ klient-flankajn aplikaĵojn, Quarkus havas nepre pretan programan modelon. Ekzemple, HTTP-subteno en Quarkus baziĝas sur la uzo de ne-bloka kaj reaktiva motoro (Eclipse Vert.x kaj Netty). Ĉiuj HTTP-petoj ricevitaj de via aplikaĵo unue estas trapasitaj tra eventa buklo (IO-Fadeno) kaj poste senditaj al la parto de la kodo, kiu administras la petojn. Depende de la celloko, la peto-administradkodo povas esti vokita ene de aparta fadeno (la tielnomita laborista fadeno, uzita en la kazo de servletoj kaj Jax-RS) aŭ uzi la fontan I/O-fadenon (reaktiva vojo).
Mesaĝaj sistemoj-konektiloj uzas ne-blokajn klientojn kurantajn sur la Vert.x-motoro. Sekve, vi povas efike sendi, ricevi kaj prilabori mesaĝojn de mesaĝaj mezvaraj sistemoj.
En la retejo Jen kelkaj bonaj lerniloj por helpi vin komenci kun Quarkus:
Ni ankaŭ kreis interretajn praktikajn lernilojn por instrui al vi diversajn aspektojn de reaktiva programado en nur retumilo, neniu IDE bezonata, kaj neniu komputilo bezonata. Vi povas trovi ĉi tiujn lecionojn .
Utilaj Rimedoj
- Retejo de la projekto Quarkus -
- Quarkus-projekto en GitHub -
- Quarkus-projekto Twitter -
- babilejo de la projekto Quarkus -
- Quarkus Project Forumoj - !forum/quarkus-dev
10 videolecionoj pri Quarkus por konatiĝi kun la temo
Kiel oni diras en la retejo , - ĉi tio -orientita Java stako, tajlorita por GraalVM kaj OpenJDK HotSpot kaj kunmetita de la plej bonaj Java bibliotekoj kaj normoj.
Por helpi vin kompreni la temon, ni elektis 10 videolernilojn, kiuj kovras diversajn aspektojn de Quarkus kaj ekzemplojn de ĝia uzo:
1. Enkonduko de Quarkus: La Nova Generacia Java Kadro por Kubernetes
De Thomas Qvarnstrom kaj Jason Greene
La celo de la Quarkus-projekto estas krei Java-platformon por Kubernetes kaj senservilaj medioj, kaj kombini reaktivajn kaj devigajn programajn modelojn en ununuran rultempan medion por ke programistoj povu flekseble variigi sian aliron kiam ili laboras kun larĝa gamo de distribuitaj aplikaĵarkitekturoj. Lernu pli en la suba enkonduka prelego.
2. Quarkus: Superrapida Subatoma Java
De: Burr Sutter
Ĉi tiu videolernilo de DevNation Live montras kiel uzi Quarkus por optimumigi entreprenajn Java-aplikaĵojn, APIojn, mikroservojn kaj senservilajn funkciojn en medio Kubernetes/OpenShift, igante ilin multe pli malgrandaj, pli rapidaj kaj pli skaleblaj.
3. Quarkus kaj GraalVM: akcelante Hibernaton al superrapidecoj kaj ŝrumpas ĝin al subatomaj grandecoj
Aŭtoro: Sanne Grinovero
De la prezento vi lernos kiel Quarkus estiĝis, kiel ĝi funkcias, kaj kiel ĝi ebligas al vi fari kompleksajn bibliotekojn, kiel Hibernate ORM, kongruajn kun denaskaj GraalVM-bildoj.
4. Lernu evoluigi senservilajn aplikaĵojn
Aŭtoro: Martin Luther
La suba video montras kiel krei simplan Java-aplikaĵon uzante Quarkus kaj disfaldi ĝin kiel senservila aplikaĵo sur Knative.
5. Quarkus: Amuziĝu pri kodado
Aŭtoro: Edson Yanaga
Videogvidilo por krei vian unuan Quarkus-projekton, permesante vin kompreni kial Quarkus gajnas la korojn de programistoj.
6. Java kaj ujoj - kia estos ilia estonteco kune
Afiŝita de Mark Little
Ĉi tiu prezento prezentas la historion de Java kaj klarigas kial Quarkus estas la estonteco de Java.
7. Quarkus: Superrapida Subatoma Java
Aŭtoro: Dimitris Andreadis
Superrigardo de la avantaĝoj de Quarkus, kiuj ricevis rekonon de programistoj: simpleco, ultra-altaj rapidecoj, la plej bonaj bibliotekoj kaj normoj.
8. Quarkus kaj subatomaj raketoj
Aŭtoro: Clement Escoffier
Per integriĝo kun GraalVM, Quarkus disponigas ultrarapidan evoluan sperton kaj subatoman rultempan medion. La aŭtoro parolas pri la reaktiva flanko de Quarkus kaj kiel uzi ĝin por konstrui reaktivajn kaj fluajn aplikojn.
9. Quarkus kaj rapida aplikaĵa disvolviĝo en Eclipse MicroProfile
Aŭtoro: John Clingan
Kombinante Eclipse MicroProfile kaj Quarkus, programistoj povas krei plenefikajn kontenerigitajn MicroProfile-aplikaĵojn, kiuj lanĉas en dekoj da milisekundoj. La video eniras en detalojn pri kiel kodi kontenerigitan MicroProfile-aplikaĵon por deplojo sur la platformo Kubernetes.
10. Java, "Turbo" versio
Aŭtoro: Marcus Biel
La aŭtoro montras kiel uzi Quarkus por krei super-malgrandajn, superrapidajn Java-ujojn, kiuj ebligas verajn sukcesojn, precipe en senservilaj medioj.
fonto: www.habr.com