Introduktion til Micronaut Framework

1. Hvad er Micronaut

Micronaut er en JVM-baseret ramme til opbygning af lette, modulære applikationer. Udviklet af OCI, det samme firma, der skabte Grails, Micronaut er den nyeste ramme designet til at gøre oprettelse af mikrotjenester hurtigt og nemt.

Mens Micronaut indeholder nogle funktioner, der ligner eksisterende rammer som Spring, har den også nogle nye funktioner, der adskiller den. Og med support til Java, Groovy og Kotlin tilbyder det en række forskellige måder at oprette applikationer på.

2. Vigtigste funktioner

En af de mest spændende funktioner i Micronaut er dens kompilering af tidsafhængighedsinjektionsmekanisme. De fleste rammer bruger refleksion og fuldmagter til at udføre afhængighedsinjektion ved kørsel. Micronaut bygger imidlertid sine data om afhængighedsinjektion på kompileringstidspunktet. Resultatet er hurtigere opstart af applikationer og mindre hukommelsesfodspor.

En anden funktion er dens første klasses support til reaktiv programmering til både klienter og servere. Valget af en specifik reaktiv implementering overlades til udvikleren, da både RxJava og Project Reactor understøttes.

Micronaut har også flere funktioner, der gør det til en fremragende ramme til udvikling af cloud-native applikationer. Det understøtter flere serviceopdagelsesværktøjer som Eureka og Consul og fungerer også med forskellige distribuerede sporingssystemer som Zipkin og Jaeger.

Det giver også support til oprettelse af AWS lambda-funktioner, hvilket gør det nemt at oprette serverløse applikationer.

3. Kom godt i gang

Den nemmeste måde at komme i gang er at bruge SDKMAN:

> sdk installere micronaut 1.0.0.RC2

Dette installerer alle de binære filer, vi har brug for til at opbygge, teste og implementere Micronaut-applikationer. Det leverer også Micronaut CLI-værktøjet, som gør det let for os at starte nye projekter.

De binære artefakter er også tilgængelige på Sonatype og GitHub.

I de følgende afsnit vil vi se på nogle af rammens funktioner.

4. Afhængighedsinjektion

Som tidligere nævnt håndterer Micronaut afhængighedsinjektion ved kompileringstid, hvilket er anderledes end de fleste IoC-containere.

Men det stadig understøtter fuldt ud JSR-330-kommentarer så det at arbejde med bønner ligner andre IoC-rammer.

For at autofire en bønne i vores kode bruger vi @Indsprøjte:

@Inject privat EmployeeService service;

Det @Indsprøjte kommentar fungerer ligesom @Autowired og kan bruges på felter, metoder, konstruktører og parametre.

Som standard er alle bønner anvendt som en prototype. Vi kan hurtigt oprette singletonbønner ved hjælp af @Singleton. Hvis flere klasser implementerer den samme bønne-grænseflade, @Primær kan bruges til at afkonflictere dem:

@Primary @Singleton offentlig klasse BlueCar implementerer bil {}

Det @Kræver annotering kan bruges, når bønner er valgfri, eller kun til at udføre autokabler, når visse betingelser er opfyldt.

I denne henseende opfører det sig meget som Spring Boot @Betinget kommentarer:

@Singleton @Requires (beans = DataSource.class) @Requires (property = "enabled") @Requires (missingBeans = EmployeeService) @Requires (sdk = Sdk.JAVA, value = "1.8") offentlig klasse JdbcEmployeeService implementerer EmployeeService {}

5. Opbygning af en HTTP-server

Lad os nu se på at oprette en simpel HTTP-serverapplikation. For at starte bruger vi SDKMAN til at oprette et projekt:

> mn create-app hej-verden-server-build maven

Dette opretter et nyt Java-projekt ved hjælp af Maven i en navngivet mappe hej-verdens-server. Inde i denne mappe finder vi vores vigtigste applikationskildekode, Maven POM-fil og andre supportfiler til projektet.

Standardapplikationen, der er meget enkel:

offentlig klasse ServerApplication {public static void main (String [] args) {Micronaut.run (ServerApplication.class); }}

5.1. Blokerer HTTP

I sig selv gør denne applikation ikke meget. Lad os tilføje en controller, der har to slutpunkter. Begge returnerer en hilsen, men den ene bruger HTTP verb, og den anden vil bruge STOLPE:

@Controller ("/ greet") offentlig klasse GreetController {@Inject private GreetingService greetingService; @Get ("/ {name}") offentlig strenghilsen (strengnavn) {return greetingService.getGreeting () + navn; } @Post (værdi = "/ {name}", forbruger = MediaType.TEXT_PLAIN) offentlig streng sætGreeting (@Body streng navn) {return greetingService.getGreeting () + navn; }}

5.2. Reaktiv IO

Som standard implementerer Micronaut disse slutpunkter ved hjælp af traditionel blokerende I / O. Imidlertid, Vi kan hurtigt implementere ikke-blokerende slutpunkter ved blot at ændre returtypen til enhver reaktiv ikke-blokerende type.

For eksempel kan vi bruge RxJava Observerbar. Ligeledes, når vi bruger Reactor, kan vi vende tilbage Mono eller Strøm datatyper:

@Get ("/ {name}") offentlig monohilsen (strengnavn) {returner Mono.just (greetingService.getGreeting () + navn); }

For både blokerende og ikke-blokerende slutpunkter er Netty den underliggende server, der bruges til at håndtere HTTP-anmodninger.

Normalt håndteres anmodningerne i hoved-I / O-trådpuljen, der oprettes ved opstart, hvilket får dem til at blokere.

Når en ikke-blokerende datatype returneres fra et controller-slutpunkt, bruger Micronaut imidlertid Netty-hændelsestråden, hvilket gør hele anmodningen ikke-blokerende.

6. Opbygning af en HTTP-klient

Lad os nu opbygge en klient til at forbruge de slutpunkter, vi lige har oprettet. Micronaut tilbyder to måder at oprette HTTP-klienter på:

  • En erklærende HTTP-klient
  • En programmatisk HTTP-klient

6.1 Deklarativ HTTP-klient

Den første og hurtigste måde at oprette er ved hjælp af en deklarativ tilgang:

@Client ("/ greet") offentlig grænseflade GreetingClient {@Get ("/ {name}") String greet (String name); }

Læg mærke til hvordan vi implementerer ikke nogen kode for at ringe til vores service. I stedet for forstår Micronaut, hvordan man ringer til tjenesten ud fra den metodesignatur og de kommentarer, vi har leveret.

For at teste denne klient kan vi oprette en JUnit-test, der bruger den integrerede server API til at køre en indlejret forekomst af vores server:

offentlig klasse GreetingClientTest {privat EmbeddedServer-server; privat GreetingClient-klient; @Før offentlig ugyldig opsætning () {server = ApplicationContext.run (EmbeddedServer.class); klient = server.getApplicationContext (). getBean (GreetingClient.class); } @ Efter offentlig ugyldig oprydning () {server.stop (); } @Test offentlig ugyldig testGreeting () {assertEquals (client.greet ("Mike"), "Hello Mike"); }}

6.2. Programmatisk HTTP-klient

Vi har også muligheden for at skrive en mere traditionel klient, hvis vi har brug for mere kontrol over dens adfærd og implementering:

@Singleton offentlig klasse ConcreteGreetingClient {privat RxHttpClient httpClient; offentlig ConcreteGreetingClient (@Client ("/") RxHttpClient httpClient) {this.httpClient = httpClient; } offentlig strenghilsen (strengnavn) {HttpRequest req = HttpRequest.GET ("/ greet /" + name); returner httpClient.retrieve (req) .blockingFirst (); } offentlig Single greetAsync (strengnavn) {HttpRequest req = HttpRequest.GET ("/ async / greet /" + name); returner httpClient.retrieve (req) .first ("En fejl som opstod"); }}

Standard HTTP-klienten bruger RxJava, så det kan nemt arbejde med blokerende eller ikke-blokerende opkald.

7. Micronaut CLI

Vi har allerede set Micronaut CLI-værktøjet i aktion ovenfor, da vi brugte det til at oprette vores prøveprojekt.

I vores tilfælde oprettede vi en enkeltstående applikation, men den har også flere andre muligheder.

7.1. Federation-projekter

I Micronaut er en føderation kun en gruppe af enkeltstående applikationer, der lever under samme bibliotek. Ved at bruge føderationer kan vi nemt administrere dem sammen og sikre, at de får de samme standardindstillinger og indstillinger.

Når vi bruger CLI-værktøjet til at generere en føderation, tager det alle de samme argumenter som Opret-app kommando. Det opretter en projektstruktur på øverste niveau, og hver enkeltstående app oprettes derfra i sin underkatalog.

7.2. Funktioner

Når vi opretter en enkeltstående applikation eller sammenslutning, kan vi beslutte, hvilke funktioner vores app har brug for. Dette hjælper med at sikre, at det minimale sæt afhængigheder er inkluderet i projektet.

Vi specificerer funktioner ved hjælp af -funktioner argument og leverer en komma-adskilt liste over funktionsnavne.

Vi kan finde en liste over tilgængelige funktioner ved at køre følgende kommando:

> mn profilinfotjeneste Leverede funktioner: -------------------- * annotation-api - Tilføjer Java-annotations-API * config-konsul - Tilføjer support til Distribueret konfiguration med konsul * discovery-consul - Tilføjer support til Service Discovery med Consul * discovery-eureka - Tilføjer support til Service Discovery med Eureka * groovy - Opretter en Groovy-applikation [...] Flere tilgængelige funktioner

7.3. Eksisterende projekter

Vi kan også bruge CLI-værktøjet til at ændre eksisterende projekter. Gør det muligt for os at oprette bønner, klienter, controllere og mere. Når vi kører mn kommando inde i et eksisterende projekt, har vi et nyt sæt kommandoer til rådighed:

> min hjælp | Kommandonavn Kommando Beskrivelse ---------------------------------------------- - create-bean Opretter en singleton bean create-client Opretter en client interface create-controller Opretter en controller og tilhørende test create-job Opretter et job med planlagt metode

8. Konklusion

I denne korte introduktion til Micronaut har vi set, hvor let det er at opbygge både blokerende og ikke-blokerende HTTP-servere og klienter. Vi undersøgte også nogle af funktionerne i dens CLI.

Men dette er bare en lille smag af de funktioner, den tilbyder. Der er også fuld support til serverløse funktioner, opdagelse af tjenester, distribueret sporing, overvågning og metrics, en distribueret konfiguration og meget mere.

Og mens mange af dens funktioner stammer fra eksisterende rammer som Grails og Spring, har den også masser af unikke funktioner, der hjælper det med at skille sig ud alene.

Som altid kan vi finde eksemplerne ovenfor i vores GitHub repo.


$config[zx-auto] not found$config[zx-overlay] not found