Serverløse funksjoner med Spring Cloud-funksjon

1. Introduksjon

I denne veiledningen lærer vi hvordan du bruker Spring Cloud Function.

Vi bygger og kjører en enkel Spring Cloud-funksjon lokalt og deretter distribuerer den til AWS.

2. Oppsett av vårens skyfunksjon

Til å begynne med, la oss implementere fra bunnen av og teste et enkelt prosjekt med to funksjoner ved hjelp av forskjellige tilnærminger:

  • En streng reversering, ved hjelp av en vanlig metode
  • Og en hilsen som bruker en dedikert klasse

2.1. Maven avhengigheter

Det første vi trenger å gjøre er å inkludere vår-sky-start-funksjon-nett avhengighet. Dette vil fungere som vår lokale adapter og bringer inn de nødvendige avhengighetene for å kjøre vår funksjon lokalt:

 org.springframework.cloud spring-cloud-starter-function-web 1.0.1.RELEASE 

Følg med da vi vil endre dette litt når vi distribuerer til AWS.

2.2. Skriver vårskyfunksjonen

Med vårskyfunksjon, vi kan avsløre @Bønnes av typen Funksjon, Forbruker eller Leverandør som individuelle metoder:

@SpringBootApplication offentlig klasse CloudFunctionApplication {public static void main (String [] args) {SpringApplication.run (CloudFunctionApplication.class, args); } @Bean public Function reverseString () {returverdi -> ny StringBuilder (verdi). Revers (). ToString (); }}

Som i denne koden kan vi avsløre en omvendt strengfunksjon som en Funksjon, som vår målfunksjonelle plattform kan påberope seg.

2.3. Teste omvendt strengfunksjon lokalt

De vår-sky-start-funksjon-nett avslører funksjonen som et HTTP-sluttpunkt. Etter at vi har kjørt CloudFunctionApplication, kan vi krølle målet vårt for å teste det lokalt:

curl localhost: 8080 / reverseString -H "Content-Type: text / plain" -d "Baeldung User"

Merk at sluttpunktet er navnet på bønnen.

Og som forventet får vi den omvendte strengen som utgang:

resU gnudleaB

2.4. Skanner vårens skyfunksjon i pakker

Bortsett fra å avsløre metoden vår som en @Bønne, vi kunne også skrive programvaren vår som klasser som implementerer det funksjonelle grensesnittet Funksjon:

offentlig klasse Greeter implementerer funksjon {@Override public String gjelder (String s) {return "Hello" + s + ", og velkommen til Spring Cloud Function !!!"; }}

Vi kan da spesifisere pakkene vi skal skanne etter relevante bønner i application.properties:

spring.cloud.function.scan.packages = com.baeldung.spring.cloudfunction.functions

2.5. Testing av Greeter-funksjonen lokalt

Igjen kan vi starte appen og bruke krøller for å teste Greeter funksjon:

curl localhost: 8080 / greeter -H "Content-Type: text / plain" -d "World"

Merk at sluttpunktet er navnet på klassen som implementerer det funksjonelle grensesnittet.

Og ingen overraskelse, vi får den forventede hilsenen tilbake:

Hei verden, og velkommen til Spring Cloud-funksjonen !!!

3. Vårskyfunksjon på AWS

Det som gjør Spring Cloud Function så kraftig er at vi kan bygge Spring-aktiverte funksjoner som er skyagnostiske. Funksjonen i seg selv trenger ikke å vite om hvordan den ble kalt eller miljøet den er distribuert til. For eksempel, Vi kan enkelt distribuere denne hilsen til AWS, Azure eller Google Cloud-plattformen uten å endre noen av forretningslogikken.

Siden AWS Lambda er en av de populære serverløse løsningene, la oss fokusere på hvordan vi distribuerer appen vår i den.

Så la oss ikke vente lenger og distribuere funksjonen vår til skyen!

3.1. Maven avhengigheter

Husk vår-sky-start-funksjon-nett avhengighet, som vi opprinnelig la til. Nå er det på tide å endre det.

Avhengig av hvor vi skal kjøre Spring Cloud-funksjonen, må vi legge til riktig avhengighet.

For AWS bruker vi vår-sky-funksjon-adapter-aws:

 org.springframework.cloud spring-cloud-function-adapter-aws 

La oss deretter legge til de nødvendige AWS-avhengighetene for å håndtere Lambda-hendelser:

 com.amazonaws aws-lambda-java-events 2.0.2 gitt com.amazonaws aws-lambda-java-core 1.1.0 gitt 

Til slutt, fordi vi skal laste opp artefakten generert av maven build til AWS Lambda, må vi bygge en gjenstand som er skyggelagt, det vil si at den har alle avhengigheter eksplodert som individuelle klassefiler i stedet for krukker.

De vår-støvel-tynn-layout avhengighet hjelper oss med å redusere størrelsen på gjenstanden ved å ekskludere noen avhengigheter som ikke er nødvendige:

   org.apache.maven.plugins maven-deploy-plugin true org.springframework.boot spring-boot-maven-plugin org.springframework.boot.experimental spring-boot-thin-layout 1.0.10.RELEASE org.apache.maven. plugins maven-shade-plugin falske sanne aws 

3.2. AWS Handlers

Hvis vi vil avsløre strengreverseren vår igjen via en HTTP-forespørsel, sendes Spring Cloud Function AWS med SpringBootRequestHandler. Den implementerer AWS RequestHandler og har ansvaret for å sende AWS-forespørselen til vår funksjon.

offentlig klasse MyStringHandlers utvider SpringBootRequestHandler {}

Spring Cloud Function AWS leveres også med SpringBootStreamHandler og FunctionInvokingS3EventHandler som andre eksempler

Nå kan det virke litt rart at MyStringHandlers er bare en tom klasse, men den spiller en viktig rolle både fungerer som inngangspunkt for Lambda-funksjonen og definerer også inngangs- og utgangstyper.

Som vi får se på skjermbildet nedenfor, vil vi oppgi det fullstendige navnet på denne klassen i Handler-inndatafeltet på AWS Lambda-konfigurasjonssiden.

3.3. Hvordan vet AWS hvilken skyfunksjon som skal påkalles?

Som det viser seg, selv om vi har mer enn en Spring Cloud-funksjon i applikasjonen vår, AWS kan bare påberope seg en av dem.

I neste avsnitt spesifiserer vi skyfunksjonens navn i en miljøvariabel som heter FUNCTION_NAME på AWS-konsollen.

4. Last opp funksjonen til AWS og Test

Til slutt, la oss bygge glasset vårt med maven, og deretter laste det opp via AWS Console UI.

4.1. Lag en Lambda-funksjon på AWS-konsollen og konfigurer den

På AWS Lambda-konsollsiden, i delen Funksjonskode, kan vi velge en Java 8 kjøretid og bare klikk Laste opp.

Etter det må vi indikere i Behandler felt det fullt kvalifiserte navnet på klassen som implementeres SpringBootRequestHandler, eller com.baeldung.spring.cloudfunction.MyStringHandlers i vårt tilfelle:

Og så i miljøvariabler indikerer vi hvilken vårfunksjonsbønne som skal påberopes via FUNCTION_NAME miljøvariabel:

Og etter å ha gjort det, er det på tide for oss å teste Lambda-funksjonen ved å lage en testhendelse og levere en prøvestreng:

4.2. Testing av funksjonen på AWS

Nå vi Lagre vår test, og klikk deretter på Test knapp.

Og som forventet får vi samme utgang som det vi fikk da vi testet funksjonen lokalt:

4.3. Testing av en annen funksjon

Husk at vi har en funksjon til i søknaden vår: hilsen. La oss sørge for at det også fungerer.

Vi endrer FUNCTION_NAME miljøvariabel til hilsen:

Klikk på Lagre og til slutt, Test knappen igjen:

5. Konklusjon

Oppsummert, men i en tidlig fase, Spring Cloud Function er et kraftig verktøy for å koble fra forretningslogikken fra et bestemt mål for kjøretid.

Med den kan den samme koden kjøre som et nettendepunkt, på en skyplattform eller som en del av en strøm. Den trekker bort alle transportdetaljene og infrastrukturen, slik at utvikleren kan beholde alle de kjente verktøyene og prosessene, og fokusere fast på forretningslogikken.

Som alltid, sjekk kildekoden for denne opplæringen på GitHub.


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