streamalism.org

1. Oversigt

I denne vejledning forstår vi tolv-faktor app-metoden.

Vi forstår også, hvordan man udvikler en mikroservice ved hjælp af Spring Boot. I processen ser vi, hvordan vi anvender tolvfaktormetoden til udvikling af en sådan mikroservice.

2. Hvad er metoden med tolv faktorer?

Tolvfaktormetoden er et sæt af tolv bedste fremgangsmåder til at udvikle applikationer udviklet til at køre som en tjeneste. Dette blev oprindeligt udarbejdet af Heroku til applikationer, der blev implementeret som tjenester på deres skyplatform, tilbage i 2011. Over tid har dette vist sig at være generisk nok til enhver software-as-a-service (SaaS) udvikling.

Så hvad mener vi med software-as-a-service? Traditionelt designer vi, udvikler, implementerer og vedligeholder softwareløsninger for at få forretningsværdi af det. Men vi behøver ikke engagere sig i denne proces for nødvendigvis at opnå det samme resultat. For eksempel er beregning af gældende skat en generisk funktion i mange domæner.

Nu kan vi beslutte at opbygge og administrere denne tjeneste selv eller abonnere på et kommercielt servicetilbud. Sådan servicetilbud er det, vi kender som software-as-a-service.

Mens software-as-a-service ikke pålægger nogen begrænsning for den arkitektur, den er udviklet på; det er ret nyttigt at anvende nogle bedste fremgangsmåder.

Hvis vi designer vores software til at være modulær, bærbar og skalerbar på moderne skyplatforme, er den ganske modtagelig for vores servicetilbud. Det er her tolvfaktormetoden hjælper med. Vi ser dem i aktion senere i vejledningen.

3. Microservice med Spring Boot

Microservice er en arkitektonisk stil til at udvikle software som løst koblede tjenester. Det vigtigste krav her er, at tjenester bør organiseres omkring grænser for forretningsdomæner. Dette er ofte den sværeste del at identificere.

Desuden har en tjeneste her den eneste autoritet over sine data og udsætter operationer for andre tjenester. Kommunikation mellem tjenester foregår typisk over lette protokoller som HTTP. Dette resulterer i uafhængigt implementerbare og skalerbare tjenester.

Nu er mikroservicearkitektur og software-as-a-service ikke afhængige af hinanden. Men det er ikke svært at forstå det, hvornår at udvikle software-as-a-service, at udnytte mikroservicearkitekturen er ret gavnligt. Det hjælper med at nå mange mål, vi har diskuteret tidligere, som modularitet og skalerbarhed.

Spring Boot er en applikationsramme baseret på Spring, der fjerner en masse kedelplade forbundet med at udvikle en virksomhedsapplikation. Det giver os en meget meningsfuld, men fleksibel platform til at udvikle mikrotjenester. Til denne tutorial udnytter vi Spring Boot til at levere en mikroservice ved hjælp af tolv-faktor-metoden.

4. Anvendelse af tolv-faktor metode

Lad os nu definere en simpel applikation, som vi forsøger at udvikle med de værktøjer og praksis, vi lige har diskuteret. Vi elsker alle at se film, men det er udfordrende at holde styr på de film, vi allerede har set.

Hvem vil nu starte en film og derefter opgive den senere? Hvad vi har brug for er en simpel tjeneste til at optage og forespørge film, som vi har set:

Dette er en ganske enkel og standard mikroservice med et datalager og REST-slutpunkter. Vi er nødt til at definere en model, der også kortlægges til vedholdenhed:

@Entity offentlig klassefilm {@Id privat Lang id; privat streng titel; privat strengår; privat streng rating; // getters og setters}

Vi har defineret en JPA-enhed med en id og et par andre attributter. Lad os nu se, hvordan REST-controlleren ser ud:

@RestController offentlig klasse MovieController {@Autowired privat MovieRepository movieRepository; @GetMapping ("/ film") offentlig liste henteAllStudenter () {returnere filmRepository.findAll (); } @GetMapping ("/ film / {id}") offentlig Film retrieveStudent (@PathVariable Lang id) {returner movieRepository.findById (id) .get (); } @PostMapping ("/ film") offentlig Lang createStudent (@RequestBody filmfilm) {returner movieRepository.save (film) .getId (); }}

Dette dækker bunden af ​​vores enkle service. Vi gennemgår resten af ​​applikationen, når vi diskuterer, hvordan vi implementerer tolvfaktormetoden i de følgende underafsnit.

4.1. Kodebase

Den første bedste praksis for tolv-faktor apps er at spore det i et versionskontrolsystem. Git er det mest populære versionskontrolsystem, der bruges i dag, og er næsten allestedsnærværende. Princippet siger, at en app skal spores i et enkelt kodelager og må ikke dele dette lager med andre apps.

Spring Boot tilbyder mange praktiske måder at starte en applikation på, inklusive et kommandolinjeværktøj og en webgrænseflade. Når vi først har genereret bootstrap-applikationen, kan vi konvertere dette til et git-arkiv:

git init

Denne kommando skal køres fra roden af ​​applikationen. Applikationen på dette stadium indeholder allerede en .gitignore-fil, som effektivt begrænser genererede filer fra at være versionskontrollerede. Så vi kan straks oprette en indledende forpligtelse:

git add. git commit -m "Tilføjelse af bootstrap til applikationen."

Endelig kan vi tilføje en fjernbetjening og skubbe vores forpligtelser til fjernbetjeningen, hvis vi ønsker det (dette er ikke et strengt krav):

git remote tilføj oprindelse //github.com//12-factor-app.git git push -u origin master

4.2. Afhængigheder

Dernæst tolv-faktor app skal altid eksplicit erklære alle dens afhængigheder. Vi skal gøre dette ved hjælp af et manifest for afhængighedserklæring. Java har flere afhængighedsstyringsværktøjer som Maven og Gradle. Vi kan bruge en af ​​dem til at nå dette mål.

Så vores enkle applikation afhænger af et par eksterne biblioteker, som et bibliotek for at lette REST API'er og oprette forbindelse til en database. Lad os se, hvordan kan vi erklærende definere dem ved hjælp af Maven.

Maven kræver, at vi beskriver et projekts afhængighed i en XML-fil, typisk kendt som Project Object Model (POM):

  org.springframework.boot spring-boot-starter-web com.h2database h2 runtime 

Selvom dette ser let og simpelt ud, har disse afhængigheder normalt andre transitive afhængigheder. Dette komplicerer det til en vis grad, men hjælper os med at nå vores mål. Nu har vores ansøgning ikke en direkte afhængighed, som ikke udtrykkeligt er beskrevet.

4.3. Konfigurationer

En applikation har typisk masser af konfiguration, hvoraf nogle kan variere mellem implementeringer, mens andre forbliver de samme.

I vores eksempel har vi en vedvarende database. Vi har brug for adresse og legitimationsoplysninger til databasen for at oprette forbindelse til. Dette skifter sandsynligvis mellem implementeringer.

En app med tolv faktorer skal eksternalisere alle sådanne konfigurationer, der varierer mellem implementeringer. Anbefalingen her er at bruge miljøvariabler til sådanne konfigurationer. Dette fører til en ren adskillelse af konfiguration og kode.

Spring giver en konfigurationsfil, hvor vi kan erklære sådanne konfigurationer og vedhæfte den til miljøvariabler:

spring.datasource.url = jdbc: mysql: // $ {MYSQL_HOST}: $ {MYSQL_PORT} / film spring.datasource.username = $ {MYSQL_USER} spring.datasource.password = $ {MYSQL_PASSWORD}

Her har vi defineret database URL og legitimationsoplysninger som konfigurationer og har kortlagt de faktiske værdier, der skal vælges fra miljøvariablen.

På Windows kan vi indstille miljøvariablen, før vi starter applikationen:

sæt MYSQL_HOST = localhost sæt MYSQL_PORT = 3306 sæt MYSQL_USER = film indstil MYSQL_PASSWORD = adgangskode

Vi kan bruge et konfigurationsstyringsværktøj som Ansible eller Chef til at automatisere denne proces.

4.4. Backing-tjenester

Backing-tjenester er tjenester, som applikationen afhænger af til drift. For eksempel en database eller en meddelelsesmægler. En app med tolv faktorer skal behandle alle sådanne backingtjenester som tilknyttede ressourcer. Hvad dette effektivt betyder, er at det ikke skal kræve nogen kodeændring for at bytte en kompatibel backing-tjeneste. Den eneste ændring skal være i konfigurationer.

I vores applikation har vi brugt MySQL som backingtjeneste til at give vedholdenhed.

Spring JPA gør koden ret agnostisk for den aktuelle databaseudbyder. Vi behøver kun at definere et lager, der leverer alle standardoperationer:

@Repository offentlig grænseflade MovieRepository udvider JpaRepository {}

Som vi kan se, afhænger dette ikke direkte af MySQL. Spring registrerer MySQL-driveren på klassestien og giver en MySQL-specifik implementering af denne grænseflade dynamisk. Desuden trækker det andre detaljer direkte fra konfigurationer.

Så hvis vi skal skifte fra MySQL til Oracle, er alt, hvad vi skal gøre, at erstatte driveren i vores afhængigheder og udskifte konfigurationerne.

4.5. Byg, frigiv og kør

Tolvfaktormetoden adskiller strengt processen med at konvertere codebase til et kørende program som tre forskellige faser:

• Build Stage: Det er her, vi tager kodebasen, udfører statiske og dynamiske kontroller og derefter genererer en eksekverbar pakke som en JAR. Ved hjælp af et værktøj som Maven er dette ret trivielt:

 mvn ren kompilere testpakke

• Release Stage: Dette er det stadium, hvor vi tager den eksekverbare pakke og kombinerer dette med de rigtige konfigurationer. Her kan vi bruge Packer med en provisioner som Ansible til at oprette Docker-billeder:

 pakke build-applikation.json

• Run Stage: Endelig er dette det stadium, hvor vi kører applikationen i et måludførelsesmiljø. Hvis vi bruger Docker som container til at frigive vores applikation, kan det være enkelt at køre applikationen:

 docker-kørsel - navn -it 

Endelig behøver vi ikke nødvendigvis udføre disse faser manuelt. Dette er hvor Jenkins kommer ind som ret praktisk med deres deklarative pipeline.

4.6. Processer

En tolvfaktor-app forventes at køre i et eksekveringsmiljø som statsløse processer. Med andre ord kan de ikke gemme vedvarende tilstand lokalt mellem anmodninger. De kan generere vedvarende data, som skal lagres i en eller flere stateful backing-tjenester.

I tilfældet med vores eksempel har vi eksponeret flere slutpunkter. En anmodning om et af disse slutpunkter er fuldstændig uafhængig af enhver anmodning, der fremsættes før den. For eksempel, hvis vi holder styr på brugeranmodninger i hukommelsen og bruger disse oplysninger til at tjene fremtidige anmodninger, overtræder det en app med tolv faktorer.

Derfor indfører en tolvfaktor-app ingen sådan begrænsning som klæbrig sessioner. Dette gør en sådan app yderst bærbar og skalerbar. I et skyudførelsesmiljø, der tilbyder automatisk skalering, er det en ganske ønskelig opførsel fra applikationer.

4.7. Portbinding

En traditionel webapplikation i Java er udviklet som et WAR eller webarkiv. Dette er typisk en samling af Servlets med afhængigheder, og det forventer en konform container-runtime som Tomcat. En tolvfaktor-app tværtimod forventer ikke en sådan afhængighed af runtime. Det er helt selvstændigt og kræver kun en kørselstid som Java.

I vores tilfælde har vi udviklet en applikation ved hjælp af Spring Boot. Spring Boot giver os bortset fra mange andre fordele en standardindlejret applikationsserver. Derfor er den JAR, vi genererede tidligere ved hjælp af Maven, fuldt ud i stand til at udføre i ethvert miljø bare ved at have en kompatibel Java-runtime:

java -jar application.jar

Her udsætter vores enkle applikation sine slutpunkter over en HTTP-binding til en bestemt port som 8080. Ved start af applikationen, som vi gjorde ovenfor, skulle det være muligt at få adgang til de eksporterede tjenester som HTTP.

En applikation kan eksportere flere tjenester som FTP eller WebSocket ved at binde til flere porte.

4.8. Samtidighed

Java tilbyder Tråd som en klassisk model til håndtering af samtidighed i en applikation. Tråde er som lette processer og repræsenterer flere stier til udførelse i et program. Tråde er kraftige, men har begrænsninger med hensyn til, hvor meget det kan hjælpe en applikationsskala.

Tolvfaktormetoden foreslår, at apps er afhængige af processer til skalering. Hvad dette effektivt betyder er, at applikationer skal designes til at distribuere arbejdsbyrde på tværs af flere processer. Individuelle processer er dog fri til at udnytte en samtidighedsmodel som Tråd internt.

En Java-applikation, når den startes, får en enkelt proces, der er bundet til den underliggende JVM. Hvad vi effektivt har brug for, er en måde at starte flere forekomster af applikationen med intelligent belastningsfordeling imellem. Da vi allerede har pakket vores applikation som en Docker-container, er Kubernetes et naturligt valg til en sådan orkestrering.

4.9. Engangsbrug

Ansøgningsprocesser kan lukkes med vilje eller gennem en uventet begivenhed. I begge tilfælde, en tolvfaktor-app skal håndtere den yndefuldt. Med andre ord skal en ansøgningsproces være fuldstændig bortskaffet uden uønskede bivirkninger. Desuden skal processer starte hurtigt

For eksempel er et af slutpunkterne i vores applikation at oprette en ny databasepost til en film. Nu kan en applikation, der håndterer en sådan anmodning, gå ned uventet. Dette bør dog ikke påvirke applikationens tilstand. Når en klient sender den samme anmodning igen, bør det ikke resultere i duplikatregistreringer.

Sammenfattende skal applikationen afsløre idempotente tjenester. Dette er en anden meget ønskelig attribut for en tjeneste, der er bestemt til skyinstallationer. Dette giver fleksibiliteten til at stoppe, flytte eller spinde nye tjenester til enhver tid uden andre overvejelser.

4.10. Dev / Prod Parity

Det er typisk, at applikationer udvikles på lokale maskiner, testes i nogle andre miljøer og til sidst implementeres til produktion. Det er ofte tilfældet, hvor disse miljøer er forskellige. For eksempel arbejder udviklingsteamet på Windows-maskiner, mens produktionsinstallation sker på Linux-maskiner.

Tolvfaktormetoden foreslår at holde kløften mellem udviklings- og produktionsmiljø så minimalt som muligt. Disse huller kan skyldes lange udviklingscyklusser, forskellige involverede teams eller forskellige teknologiestak i brug.

Nu bygger teknologi som Spring Boot og Docker automatisk dette hul i høj grad. En containeriseret applikation forventes at opføre sig det samme, uanset hvor vi kører det. Vi skal også bruge de samme backingtjenester - som databasen.

Desuden skal vi have de rigtige processer som kontinuerlig integration og levering for at gøre det lettere at bygge bro over dette hul.

4.11. Logfiler

Logfiler er vigtige data, som en applikation genererer i løbet af dens levetid. De giver uvurderlig indsigt i applikationens funktion. En applikation kan typisk generere logfiler på flere niveauer med forskellige detaljer og output ii i flere forskellige formater.

En app med tolv faktorer adskiller sig dog fra loggenerering og dens behandling. For en sådan app er logfiler ikke andet end en tidsbestemt strøm af begivenheder. Det skriver kun disse begivenheder til standardoutput fra eksekveringsmiljøet. Optagelse, opbevaring, kurering og arkivering af en sådan stream skal håndteres af eksekveringsmiljøet.

Der er flere forskellige værktøjer til rådighed til dette formål. Til at begynde med kan vi bruge SLF4J til at håndtere logning abstrakt i vores applikation. Desuden kan vi bruge et værktøj som Fluentd til at indsamle strømmen af ​​logfiler fra applikationer og backingtjenester.

Dette kan vi føje til Elasticsearch til opbevaring og indeksering. Endelig kan vi generere meningsfulde dashboards til visualisering i Kibana.

4.12. Admin-processer

Ofte er vi nødt til at udføre nogle engangsopgaver eller rutineprocedurer med vores ansøgningstilstand. For eksempel at rette dårlige poster. Nu er der forskellige måder, hvorpå vi kan opnå dette. Da vi måske ikke ofte har brug for det, kan vi skrive et lille script til at køre det separat fra et andet miljø.

Nu, tolvfaktormetoden foreslår kraftigt at holde sådanne admin-scripts sammen med applikationens kodebase. Ved at gøre dette skal det følge de samme principper, som vi anvender til hovedapplikationens kodebase. Det tilrådes også at bruge et indbygget REPL-værktøj til eksekveringsmiljøet til at køre sådanne scripts på produktionsservere.

I vores eksempel, hvordan frøer vi vores ansøgning med de allerede sete film hidtil? Mens vi kan bruge vores søde lille slutpunkt, men det kan synes at være upraktisk. Hvad vi har brug for er et script til at udføre en engangsbelastning. Vi kan skrive en lille Java-funktion for at læse en liste over film fra en fil og gemme dem i batch i databasen.

Desuden kan vi bruge Groovy integreret med Java runtime til at starte sådanne processer.

5. Praktiske anvendelser

Så nu har vi set alle de faktorer, der er foreslået af tolvfaktormetoden. Udvikling af en applikation til at være en tolv-faktor app har bestemt sine fordele, især når vi ønsker at implementere dem som tjenester i skyen. Men som alle andre retningslinjer, rammer, mønstre, må vi spørge, er dette en sølvkugle?

Ærligt talt hævder ingen enkelt metode i design og udvikling af software at være en sølvkugle. Tolvfaktormetoden er ingen undtagelse. Mens nogle af disse faktorer er ret intuitive, og sandsynligvis laver vi dem allerede, andre gælder muligvis ikke for os. Det er vigtigt at evaluere disse faktorer på baggrund af vores mål og derefter vælge klogt.

Det er vigtigt at bemærke, at alle disse faktorer er der for at hjælpe os med at udvikle en applikation, der er modulær, uafhængig, bærbar, skalerbar og observerbar. Afhængigt af applikationen kan vi muligvis opnå dem bedre på andre måder. Det er heller ikke nødvendigt at vedtage alle faktorer sammen, ved at vedtage selv nogle af disse kan gøre os bedre, end vi var.

Endelig er disse faktorer ret enkle og elegante. De har større betydning i en tid, hvor vi kræver, at vores applikationer har højere kapacitet og lavere ventetid uden stort set nedetid og fiasko. Vedtagelsen af ​​disse faktorer giver os den rigtige start fra starten. Kombineret med mikroservicearkitektur og containerisering af applikationer ser de bare ud til at ramme det rigtige sted.

6. Konklusion

I denne vejledning gennemgik vi begreberne tolv-faktor metode. Vi diskuterede, hvordan man udnytter en mikroservicearkitektur med Spring Boot for at levere dem effektivt. Desuden undersøgte vi hver faktor i detaljer, og hvordan vi anvender dem til vores ansøgning. Vi undersøgte også flere værktøjer til at anvende disse individuelle faktorer på en effektiv måde med succes.