Det har vært en lang tur for Java, et språk som begynte som lingua franca for boksen på toppen av fjernsynsapparatet i de dager da TV-er ikke kom med Roku eller Chromecast innebygd. Da skulle Java eie World Wide Web ved å animere nettleseren før JavaScript fulgte og svingte den ut av veien.
Java endte opp med å finne en nisje i serverfarmene der det en gang var nok forskjellige brikkearkitekturer og operativsystemer til å gjøre "skriv en gang kjøre hvor som helst løfte" overbevisende. Og i disse serverfarmene Java har levd på, en favoritt for IT-butikker som er avhengige av pålitelighet og utviklere som elsker kjærlighet til å skrive.
I mellomtiden har JavaScript generelt og Node.js spesielt utfordret Java på serveren ved å bruke deres høye gjennomstrømning og trådfrie hastighet til å ta over en stor del av trafikken på nettet. Node har fanget fantasien til de nyeste programmørene på serversiden ved å tilby ikke bare hastighet og ressurseffektivitet, men også enkelheten til koden som kjører på både klienten og serveren.
Til tross for økningen av konkurransen fortsetter Java ikke bare å overleve, men å utmerke seg. Mange av teamene som har til oppgave å utvikle mikrotjenestearkitekturer fortsetter å bruke Java. En viktig årsak må være fordi teknologien er kamptestet fra år på frontlinjene som analyserer HTTP-forespørsler. Sun opprettet en bunnsolid virtuell maskin, og Oracle fortsetter å pleie og støtte den.
En annen grunn må være den fortsatte utviklingen av språket. Java 8 tilbyr solid støtte for funksjonelle språk som Scala og Kotlin. JVM er nå et grunnlag for mange av de beste eksperimentene innen dataspråkutvikling. Dusinvis av nye språk kan kompilere ned til Java-byte-kode og knytte seg til hverandre for å få komplekse prosjekter til å fungere sammen. Mange av stablene som kjører problemfritt på en JVM, kan bygges av en blanding av Java og en rekke andre språk.
Den største grunnen må imidlertid være ren treghet. Mens jeg skriver, er 371 jobber for COBOL-programmerere oppført på Dice. Det er mange, mange flere jobber med ordet Java i seg. Er det noen overraskelse at smarte team ser på sine enorme stabler med aldrende Java-kode og tenker at den enkleste løsningen bare er å legge til en sidedør som spytter ut dataene som JSON-datastrukturer? Voilà. Den gamle koden fortsetter å løpe, men den fungerer som en moderne mikroservice på disse sidedørene.
Alle disse alternativene og mer sørger for at Java fortsetter å spille en sterk og viktig rolle i mikroservicesrevolusjonen. Og det er ingen overraskelse at Java open source-fellesskapet har fulgt med, og skapt mange nye alternativer for Java-programmerere som trenger å lære Java-koden sin å snakke som en mikroservice.
Her er en liste over 13 open source-alternativer som Java-utviklere bruker for å vise løsninger som danner grunnlaget for mikrotjenestearkitekturer overalt.
Vårstøvel
Java-verdenen har bygget vårapplikasjoner i lang tid. Spring Boot er en bestemt versjon av Spring som gjør prosessen mye enklere ved å håndtere mange av konfigurasjonsdetaljene for deg. Spring Boot ble opprettet for å automatisere starten på vårprosjekter av noe slag, ikke bare mikrotjenester. For å gjøre ting enda enklere, når du er ferdig med applikasjonen, blander Spring Boot inn en webserver og spytter ut en enkelt JAR-fil som er stort sett alt du trenger unntatt JVM. Tenk på det som den originale Docker-containeren.
All denne kløken er verdsatt av mange mennesker som har til oppgave å bygge mikrotjenester fordi hele konfigurasjonen blir irriterende når du må gjøre det igjen og igjen for hvert dusin eller så mikrotjenester. Hvis Spring Boot kan automatisere det, er det mye enklere å kaste ut flere dusin mikrotjenester.
Mikrotjenestene utviklet med Spring følger samme MVC-filosofi som makro-webapplikasjonene vi har bygget i mange år. Rammeverket nyter alle de dype forbindelsene som er bygget opp gjennom mange år med Java-utvikling, inkludert integrasjon med alle større og mindre datalagre, LDAP-servere og meldingsverktøy som Apache Kafka. Det er også dusinvis av små og ikke så små funksjoner for å opprettholde en løpende samling servere, funksjoner som Spring Vault, et verktøy for å opprettholde hemmeligheter, passord og legitimasjon som serverne trenger i produksjonen. Alle disse fordelene viser hvorfor Java-programmerere har sluttet seg til vognen i mange år.
Formørkelse MicroProfile
I 2016 så noen av fansen av Java Enterprise-samfunnet seg rundt og bestemte seg for å rydde ut all cruft fra Java Enterprise Edition, slik at folk kunne bygge enkle mikrotjenester med de klassiske delene. De kastet ut et overraskende antall biblioteker, men beholdt kode for behandling av REST-forespørsler, parsing av JSON og administrering av avhengighetsinjeksjon. Det de endte med, kalt Eclipse MicroProfile, var raskt og enkelt.
Siden den gang har MicroProfile-fellesskapet inngått en pakt om å gi ut nye versjoner så ofte som kvartalsvis, mens de legger til ny kode for å holde mikrotjenestene jevne og trygge. Utviklingsprosessen og kodestrukturen vil være veldig kjent for alle som har bodd i Java EE-verdenen, men de endeløse konfigurasjonsproblemene er polert bort. Det er et bevis på at du kan lære gamle hunder nye triks.
Dropwizard
Da Dropwizard dukket opp i 2011, åpnet det øynene til Java Enterprise-utviklere for hvor lite kode som virkelig var nødvendig. Dropwizard-rammeverket leverte en veldig enkel modell for utvikling med mange av de viktige beslutningene som ble tatt for deg, og den har fortsatt å følge denne veien. Du legger til litt forretningslogikk, og så er stort sett alt annet konfigurert for deg i henhold til konvensjonen. Resultatet er slanke JAR-filer som brukerne roser for å starte raskt opp.
Den største begrensningen kan være mangelen på avhengighetsinjeksjon. Hvis du vil bruke avhengighetsinjeksjon for å holde koden ren og løst koblet, må du legge til bibliotekene selv. Det er ingen Dropwizard-måte å gjøre dette på, i motsetning til i vårverdenen. De fleste av de andre luksusartiklene støttes nå, inkludert logging, helsekontroller og motstandsdyktig kode. Du trenger ikke å gjøre for mange ofre.
WildFly Thorntail
Folk på Red Hat bygget sin egen versjon av MicroProfile komplett med et glatt konfigurasjonsverktøy. Rammeverket ble opprinnelig kalt WildFly Swarm, men da ble det omdøpt til Thorntail. Thorntail-nettstedet hjelper deg med å lage din egen Maven-byggfil bare ved å spesifisere funksjonene du trenger. Maven tar seg deretter av å montere alt.
Thorntail vil også oppdage hovedkomponentene du trenger ved å skanne koden din, men du kan overstyre denne med en BOM (materialliste) -fil. Når alt er i gang, vil Thorntail fjerne de delene av Java Enterprise Edition som ikke brukes, og lage en JAR-fil som er liten og klar til å distribueres med en kommando - en glatt funksjon som gjør at Thorntail-prosjektet kan kalle det en Uber -KRUKKE. Det er en annen tilnærming til å følge tradisjonen til Java Enterprise Edition uten å beholde all den tunge bagasjen.
Helidon
Helidon har bare vært ute i noen måneder siden pressemeldingene og den første forpliktelsen til GitHub-depotet, men rammeverket tiltrekker allerede den typen oppmerksomhet som støtte fra Oracle garanterer. Mens Java-universet er stort, dreier det seg fortsatt mye om Oracle.
Helidons arkitekter fulgte mange av de samme temaene som gjentas i de andre prosjektene her. Rip ut Java Enterprise Edition-cruften og behold den lette, servletbaserte kjernen som har fortjent verdens tillit. I Helidons tilfelle startet utviklerne med Netty og la til akkurat nok kode til å gjøre noen ruting og feilhåndtering. For å gjøre ting interessante omfavnet de to grunnleggende modeller for koden, de såkalte SE- og MP-versjonene.
Helidon SE vil se veldig kjent ut for Node.js-programmerere med de lange kjedene av funksjonssamtaler som er forbundet med perioder. Helidon MP vil se mer kjent ut for Java-programmererne som bruker JAX-RS. Det er også noen nyttige og verdsatte verktøy for å kontrollere helsen til serverne eller spore datastrømmen gjennom en skog av mikrotjenester. Dette er overbevisende grunner til å utforske potensialet, selv uten Oracles støtte.
Siriss
Nok et rammeverk for rask API-utvikling er Cricket. Cricket er liten til tross for at det inkluderer flere statister som en nøkkelverdi-datalager for å redde deg fra å koble til en database og en planlegger for å kontrollere gjentatt bakgrunnsbehandling. Det er ingen andre avhengigheter som legger til komplikasjoner eller låsing, så det er ganske enkelt å legge til koden din i Cricket og starte en uavhengig mikroservice.
Jersey
En av de vanlige tilnærmingene til å utvikle en nettjeneste er Java API for RESTful Web Services (aka JAX-RS), en generell spesifikasjon som er implementert i Jersey-rammeverket. Tilnærmingen avhenger sterkt av å bruke merknadene for å spesifisere banekartlegging og returdetaljer. Alt annet fra analyse av parametrene og pakking av JSON håndteres av Jersey.
Den største fordelen med Jersey er at den implementerer JAX-RS-standarden, en funksjon som er ønskelig nok til at noen utviklere kombinerer Jersey med Spring Boot for å nyte begge sammen.
Spille
En av de beste måtene å oppleve den flerspråklige kraften til JVM er med Play-rammeverket, en haug med Scala-kode som knytter seg til Java eller et hvilket som helst av de andre JVM-språkene. Fundamentet er veldig moderne, med en asynkron, statsløs modell som ikke overbelaster serveren med endeløse tråder som prøver å holde oversikt over brukerne og deres øktdata. Det er også en rekke ekstra funksjoner som kan brukes til å utarbeide et nettsted som OpenID, validering og støtte for filopplasting.
Play-kodebasen har utviklet seg i mer enn et tiår, så du vil også finne ekko fra lenge glemte tider som støtte for XML. Lek er både moden og smidig, en kombinasjon som kan være sjelden i naturen.
Swagger
Å bygge et API kan virke så enkelt som å skrive en kode som lytter på en port og gir svar, men utviklerne av Swagger ber om å være annerledes. De har laget et helt API-spesifikasjonsspråk kalt OpenAPI som du kan bruke til å stave hva du API vil gjøre. Dette kan virke som et ekstra trinn, men Swagger-teamet har også gitt kode som gjør denne spesifikasjonen til automatiserte tester, dokumentasjon og mer.
Den enkle, nesten spartanske beskrivelsen av et API i Swagger-konfigurasjonsfilen blir spunnet inn i Java-kode for å implementere grensesnittet, dokumentere hvordan den oppfører seg, og gi et sett med verktøy for å teste koden som er bygget under den. Det er til og med en mekanisme for API-styring, slik at du kan jobbe med de uvaskede massene som snart vil banke på API-døren din og forvente svar.
Swagger er et økosystem for APIer, og det er ikke begrenset til Java. Hvis teamet ditt flytter til Node.js eller noen av flere titalls andre språk, er det en Swagger Codegen-modul som venter på å konvertere OpenAPI-spesifikasjonen til en implementering på det språket.
Restlet
En av de større forskjellene mellom de forskjellige rammene er antall forbindelser til andre tjenester og biblioteker. Restlet-prosjektet tilbyr en av de større samlingene av funksjoner og tilkoblinger. Den er allerede integrert med biblioteker som JavaMail, i tilfelle mikrotjenesten din trenger å snakke POP, IMAP eller SMTP til en eller annen e-postserver, og Lucene / Solr, hvis du vil bygge søkbare indekser med store biter av tekst og metadataene pakket den.
Mulighetene i Restlet fortsetter bare fordi denne stabelen generelt støtter flere forskjellige alternativer for hver del. Du trenger ikke å bruke JSON, for eksempel fordi koden vil håndtere XML, CSV, YAML og noen få filformater til. Du får flere forskjellige alternativer for malene for å strukturere ditt svar også. En av de finere ekstra funksjonene er Restlet-klienten, som lar deg teste API-ene dine fra Chrome-nettleseren.
Squash
Feilsøking av mikrotjenester er ofte en reell utfordring fordi delene er så løst koblet og det er vanskelig å spore datastrømmen gjennom alle lagene i systemet. Med Squash kan du sette opp brytepunkter i koden din som kjører på en Kubernetes-klynge, og deretter motta alle dataene tilbake i IDE-en din som om det var kode som kjører lokalt. Squash integreres også med Node.js og Python-driftstider i tilfelle samlingen av mikrotjenester ikke er bare Java.
Telepresence
Et annet alternativ for feilsøking er å bruke Telepresence til å opprette en lokal proxy for en mikroservice på en fjern Kubernetes-klynge. Dine samtaler for denne tjenesten blir viderekoblet til den lokale versjonen der du kan sette opp brytepunkter eller gjøre noe annet du kan forestille deg på din lokale maskin.
Zipkin
Zipkin er en mekanisme for å logge hendelser på forskjellige mikrotjenester og deretter korrelere hendelsene, slik at problemer kan isoleres og studeres når de ripper gjennom samling av maskiner. Det er en Zipkin-implementering for Java, så vel som minst seks andre språk, slik at flerspråklige systemer kan håndteres. Noen av de mest sofistikerte rammene som Spring har allerede Zipkin integrert i en eller annen form.
