streamalism.org

1. Oversikt

I denne opplæringen vil vi forstå tolvfaktors appmetodikk.

Vi vil også forstå hvordan vi kan utvikle en mikroservice ved hjelp av Spring Boot. I prosessen vil vi se hvordan vi bruker tolvfaktormetoden for å utvikle en slik mikroservice.

2. Hva er tolvfaktormetoden?

Tolvfaktormetoden er et sett med tolv beste fremgangsmåter for å utvikle applikasjoner utviklet for å kjøre som en tjeneste. Dette ble opprinnelig utarbeidet av Heroku for applikasjoner som ble distribuert som tjenester på skyplattformen, tilbake i 2011. Over tid har dette vist seg å være generisk nok til enhver software-as-a-service (SaaS) utvikling.

Så, hva mener vi med programvare-som-en-tjeneste? Tradisjonelt designer vi, utvikler, distribuerer og vedlikeholder programvareløsninger for å hente forretningsverdi av det. Men vi trenger ikke å delta i denne prosessen for å oppnå det samme resultatet nødvendigvis. For eksempel er beregning av gjeldende avgift en generisk funksjon på mange domener.

Nå kan vi bestemme oss for å bygge og administrere denne tjenesten selv eller abonnere på et kommersielt tjenestetilbud. Slik tjenestetilbud er det vi kjenner som software-as-a-service.

Mens programvare-som-en-tjeneste ikke pålegger arkitekturen den er utviklet for; Det er ganske nyttig å ta i bruk noen gode fremgangsmåter.

Hvis vi designer programvaren vår til å være modulær, bærbar og skalerbar på moderne skyplattformer, er den ganske imøtekommende for våre tjenestetilbud. Det er her tolvfaktormetoden hjelper til. Vi ser dem i aksjon senere i opplæringen.

3. Microservice med Spring Boot

Microservice er en arkitektonisk stil for å utvikle programvare som løst koblede tjenester. Det viktigste kravet her er at tjenester bør organiseres rundt forretningsgrense. Dette er ofte den vanskeligste delen å identifisere.

Videre har en tjeneste her den eneste myndighet over sine data og utsetter operasjoner for andre tjenester. Kommunikasjon mellom tjenester foregår vanligvis over lette protokoller som HTTP. Dette resulterer i uavhengige distribuerbare og skalerbare tjenester.

Nå er ikke mikrotjenestearkitektur og programvare-som-en-tjeneste avhengig av hverandre. Men det er ikke vanskelig å forstå det når å utvikle programvare-som-en-tjeneste, utnytte mikroservicearkitekturen er ganske gunstig. Det hjelper å oppnå mange mål vi diskuterte tidligere, som modularitet og skalerbarhet.

Spring Boot er et applikasjonsrammeverk basert på Spring som tar bort mye kokeplate assosiert med å utvikle en bedriftsapplikasjon. Det gir oss en svært meningsfull men fleksibel plattform for å utvikle mikrotjenester. For denne opplæringen vil vi utnytte Spring Boot til å levere en mikroservice ved hjelp av tolvfaktormetoden.

4. Bruk av tolvfaktormetodikk

La oss nå definere et enkelt program som vi vil prøve å utvikle med verktøyene og praksisene vi nettopp diskuterte. Vi elsker alle å se filmer, men det er utfordrende å holde rede på filmene vi allerede har sett.

Nå, hvem vil starte en film og deretter forlate den senere? Det vi trenger er en enkel tjeneste for å spille inn og spørre filmer som vi har sett på:

Dette er ganske enkel og standard mikroservice med datalager og REST-sluttpunkter. Vi må definere en modell som også vil tilordnes til utholdenhet:

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

Vi har definert en JPA-enhet med en id og noen få andre attributter. La oss nå se hvordan REST-kontrolleren ser ut:

@RestController offentlig klasse MovieController {@Autowired privat MovieRepository movieRepository; @GetMapping ("/ filmer") offentlig liste henteAllStudenter () {returnere filmRepository.findAll (); } @GetMapping ("/ films / {id}") offentlig film retrieveStudent (@PathVariable lang id) {retur movieRepository.findById (id) .get (); } @PostMapping ("/ filmer") offentlig Long createStudent (@RequestBody Movie movie) {return movieRepository.save (movie) .getId (); }}

Dette dekker basen til vår enkle tjeneste. Vi vil gå gjennom resten av applikasjonen mens vi diskuterer hvordan vi implementerer tolvfaktormetoden i de følgende underavsnittene.

4.1. Kodebase

Den første beste fremgangsmåten for tolvfaktorapper er å spore den i et versjonskontrollsystem. Git er det mest populære versjonskontrollsystemet som brukes i dag, og er nesten allestedsnærværende. Prinsippet sier at en app skal spores i et enkelt kodelager og må ikke dele dette depotet med andre apper.

Spring Boot tilbyr mange praktiske måter å starte en applikasjon, inkludert et kommandolinjeverktøy og et webgrensesnitt. Når vi genererer bootstrap-applikasjonen, kan vi konvertere dette til et git-arkiv:

git init

Denne kommandoen skal kjøres fra roten til applikasjonen. Søknaden på dette stadiet inneholder allerede en .gitignore-fil som effektivt begrenser genererte filer fra å være versjonskontrollerte. Så vi kan straks opprette en første forpliktelse:

git add. git commit -m "Legge til bootstrap for applikasjonen."

Til slutt kan vi legge til en fjernkontroll og skyve våre forpliktelser til fjernkontrollen hvis vi ønsker det (dette er ikke et strengt krav):

git remote legg til opprinnelse //github.com//12-factor-app.git git push -u origin master

4.2. Avhengigheter

Neste, den tolvfaktors app skal alltid eksplisitt erklære alle avhengigheter. Vi bør gjøre dette ved hjelp av et avhengighetserklæring manifest. Java har flere avhengighetsstyringsverktøy som Maven og Gradle. Vi kan bruke en av dem for å oppnå dette målet.

Så den enkle applikasjonen vår avhenger av noen få eksterne biblioteker, som et bibliotek for å legge til rette for REST APIer og for å koble til en database. La oss se hvordan vi kan forklare dem med Maven.

Maven krever at vi beskriver prosjektets avhengigheter i en XML-fil, vanligvis kjent som Project Object Model (POM):

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

Selv om dette ser enkelt og enkelt ut, har disse avhengighetene vanligvis andre overgangsavhengigheter. Dette kompliserer det til en viss grad, men hjelper oss med å nå vårt mål. Nå har søknaden vår ikke en direkte avhengighet som ikke er eksplisitt beskrevet.

4.3. Konfigurasjoner

Et program har vanligvis mange konfigurasjoner, hvorav noen kan variere mellom distribusjoner, mens andre forblir de samme.

I vårt eksempel har vi en vedvarende database. Vi trenger adressen og legitimasjonen til databasen for å koble til. Dette vil mest sannsynlig endre mellom distribusjoner.

En tolvfaktor-app skal eksternalisere alle slike konfigurasjoner som varierer mellom distribusjonene. Anbefalingen her er å bruke miljøvariabler for slike konfigurasjoner. Dette fører til en ren separasjon av konfigurasjon og kode.

Spring gir en konfigurasjonsfil der vi kan erklære slike konfigurasjoner og knytte den til miljøvariabler:

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

Her har vi definert URL-adressen og legitimasjonen til databasen som konfigurasjoner og har kartlagt de faktiske verdiene som skal plukkes fra miljøvariabelen.

På Windows kan vi stille inn miljøvariabelen før vi starter applikasjonen:

sett MYSQL_HOST = localhost sett MYSQL_PORT = 3306 sett MYSQL_USER = filmer sett MYSQL_PASSWORD = passord

Vi kan bruke et konfigurasjonsadministrasjonsverktøy som Ansible eller Chef for å automatisere denne prosessen.

4.4. Støttetjenester

Backing-tjenester er tjenester som applikasjonen er avhengig av for drift. For eksempel en database eller en meldingsmegler. En tolvfaktor-app skal behandle alle slike støttetjenester som tilknyttede ressurser. Hva dette effektivt betyr er at det ikke burde kreve noen kodeendring for å bytte en kompatibel backingtjeneste. Den eneste endringen skal være i konfigurasjoner.

I applikasjonen vår har vi brukt MySQL som backing-tjeneste for å gi utholdenhet.

Spring JPA gjør koden ganske agnostisk for den faktiske databaseleverandøren. Vi trenger bare å definere et depot som gir alle standardoperasjoner:

@Repository offentlig grensesnitt MovieRepository utvider JpaRepository {}

Som vi kan se, er dette ikke avhengig av MySQL direkte. Spring oppdager MySQL-driveren på klassestien og gir en MySQL-spesifikk implementering av dette grensesnittet dynamisk. Videre trekker den andre detaljer fra konfigurasjoner direkte.

Så hvis vi må bytte fra MySQL til Oracle, er alt vi trenger å erstatte driveren i våre avhengigheter og erstatte konfigurasjonene.

4.5. Bygg, slipp og kjør

Tolvfaktormetoden skiller strengt prosessen med å konvertere kodebase til et applikasjon som kjører som tre forskjellige stadier:

• Build Stage: Dette er hvor vi tar kodebasen, utfører statiske og dynamiske kontroller, og deretter genererer en kjørbar pakke som en JAR. Ved hjelp av et verktøy som Maven er dette ganske trivielt:

 mvn ren kompilere testpakke

• Release Stage: Dette er scenen der vi tar den kjørbare pakken og kombinerer dette med de riktige konfigurasjonene. Her kan vi bruke Packer med en provisioner som Ansible for å lage Docker-bilder:

 pakkerbygg applikasjon.json

• Run Stage: Endelig er dette stadiet der vi kjører applikasjonen i et målutførelsesmiljø. Hvis vi bruker Docker som beholder for å frigjøre applikasjonen vår, kan det være enkelt å kjøre programmet:

 docker run --name -it 

Til slutt trenger vi ikke nødvendigvis å utføre disse trinnene manuelt. Det er her Jenkins kommer ganske praktisk med sin deklarative pipeline.

4.6. Prosesser

En tolvfaktor-app forventes å kjøre i et utførelsesmiljø som statsløse prosesser. Med andre ord kan de ikke lagre vedvarende tilstand lokalt mellom forespørsler. De kan generere vedvarende data som kreves lagret i en eller flere stateful backing-tjenester.

Når det gjelder eksemplet vårt, har vi flere endepunkter eksponert. En forespørsel om et av disse endepunktene er helt uavhengig av enhver forespørsel som er gjort før den. Hvis vi for eksempel holder oversikt over brukerforespørsler i minnet og bruker denne informasjonen til å betjene fremtidige forespørsler, bryter den en tolvfaktors app.

Derfor pålegger en tolvfaktorapp ingen slike begrensninger som klebrig økter. Dette gjør en slik app svært bærbar og skalerbar. I et skyutførelsesmiljø som tilbyr automatisk skalering, er det ganske ønskelig oppførsel fra applikasjoner.

4.7. Portbinding

En tradisjonell webapplikasjon i Java er utviklet som et WAR eller webarkiv. Dette er vanligvis en samling Servlets med avhengigheter, og den forventer en samsvarende container-kjøretid som Tomcat. En tolvfaktor-app, tvert imot, forventer ingen slik kjøretidsavhengighet. Det er helt selvstendig og krever bare en kjøringstid som Java.

I vårt tilfelle har vi utviklet en applikasjon ved hjelp av Spring Boot. Spring Boot, bortsett fra mange andre fordeler, gir oss en standard innebygd applikasjonsserver. Derfor er JAR vi genererte tidligere med Maven fullt i stand til å utføre i ethvert miljø bare ved å ha en kompatibel Java-kjøretid:

java -jar application.jar

Her avslører vårt enkle program endepunktene sine over en HTTP-binding til en bestemt port som 8080. Ved å starte applikasjonen som vi gjorde ovenfor, burde det være mulig å få tilgang til de eksporterte tjenestene som HTTP.

Et program kan eksportere flere tjenester som FTP eller WebSocket ved å binde til flere porter.

4.8. Samtidighet

Java tilbyr Tråd som en klassisk modell for å håndtere samtidighet i en applikasjon. Tråder er som lette prosesser og representerer flere kjøringsveier i et program. Trådene er kraftige, men har begrensninger når det gjelder hvor mye det kan hjelpe en applikasjonsskala.

Tolvfaktormetoden foreslår at apper kan stole på prosesser for skalering. Hva dette effektivt betyr er at applikasjoner skal utformes for å distribuere arbeidsmengde over flere prosesser. Individuelle prosesser er imidlertid fritt til å utnytte en samtidighetsmodell som Tråd internt.

En Java-applikasjon, når den lanseres, får en enkelt prosess som er bundet til den underliggende JVM. Det vi faktisk trenger er en måte å starte flere forekomster av applikasjonen med intelligent belastningsfordeling mellom dem. Siden vi allerede har pakket applikasjonen vår som en Docker-container, er Kubernetes et naturlig valg for slik orkestrering.

4.9. Engangsbruk

Søknadsprosesser kan stenges med vilje eller gjennom en uventet hendelse. I begge tilfeller, en tolvfaktor-app skal håndtere den elegant. Med andre ord, en søknadsprosess skal være fullstendig disponibel uten uønskede bivirkninger. Videre bør prosesser starte raskt

For eksempel, i søknaden vår, er et av endepunktene å lage en ny databaseoppføring for en film. Nå kan en applikasjon som håndterer en slik forespørsel krasje uventet. Dette bør imidlertid ikke påvirke tilstanden til applikasjonen. Når en klient sender den samme forespørselen igjen, bør det ikke resultere i duplikatposter.

Oppsummert bør søknaden avsløre idempotente tjenester. Dette er et annet veldig ønskelig attributt for en tjeneste som er bestemt for skyutplasseringer. Dette gir fleksibilitet til å stoppe, flytte eller spinne nye tjenester når som helst uten andre hensyn.

4.10. Dev / Prod Parity

Det er typisk for applikasjoner som skal utvikles på lokale maskiner, testes i andre miljøer og til slutt distribueres til produksjon. Det er ofte tilfelle der disse miljøene er forskjellige. For eksempel jobber utviklingsteamet på Windows-maskiner, mens produksjonsutrulling skjer på Linux-maskiner.

Tolvfaktormetoden antyder å holde gapet mellom utviklings- og produksjonsmiljø så minimalt som mulig. Disse hullene kan være resultatet av lange utviklingssykluser, forskjellige involverte team eller annen teknologibakk i bruk.

Nå bygger teknologi som Spring Boot og Docker automatisk dette gapet i stor grad. En containerisert applikasjon forventes å oppføre seg likt, uansett hvor vi kjører den. Vi må bruke de samme støttetjenestene - som databasen - også.

Videre bør vi ha de riktige prosessene som kontinuerlig integrering og levering for å gjøre det lettere å bygge bro over dette gapet.

4.11. Tømmerstokker

Logger er viktige data som et program genererer i løpet av dets levetid. De gir uvurderlig innsikt i applikasjonen. Vanligvis kan et program generere logger på flere nivåer med varierende detaljer og utdata ii i flere forskjellige formater.

En tolvfaktor-app skiller seg imidlertid fra loggenerering og behandlingen. For en slik app er logger ikke annet enn en tidsbestilt strøm av hendelser. Den skriver bare disse hendelsene til standardutdata fra utførelsesmiljøet. Fangst, lagring, kurering og arkivering av en slik strøm skal håndteres av kjøringsmiljøet.

Det er ganske mange verktøy tilgjengelig for oss for dette formålet. Til å begynne med kan vi bruke SLF4J til å håndtere logging abstrakt i applikasjonen vår. Videre kan vi bruke et verktøy som Fluentd til å samle strømmen av logger fra applikasjoner og støttetjenester.

Dette kan vi mate inn i Elasticsearch for lagring og indeksering. Til slutt kan vi generere meningsfulle dashboards for visualisering i Kibana.

4.12. Administratorprosesser

Ofte må vi utføre noen engangsoppgaver eller rutineprosedyrer med søknadstilstanden. For eksempel å fikse dårlige poster. Nå er det forskjellige måter vi kan oppnå dette på. Siden vi ikke ofte trenger det, kan vi skrive et lite skript for å kjøre det separat fra et annet miljø.

Nå, tolvfaktormetoden foreslår sterkt å beholde slike admin-skript sammen med applikasjonskodebasen. Ved å gjøre dette, bør det følge de samme prinsippene som vi bruker på hovedprogramkodebasen. Det anbefales også å bruke et innebygd REPL-verktøy i kjøringsmiljøet for å kjøre slike skript på produksjonsservere.

I vårt eksempel, hvordan sår vi applikasjonen vår med de filmene som allerede er sett så langt? Mens vi kan bruke det lille søte endepunktet vårt, men det kan synes å være upraktisk. Det vi trenger er et skript for å utføre en engangsbelastning. Vi kan skrive en liten Java-funksjon for å lese en liste over filmer fra en fil og lagre dem i batch i databasen.

Videre kan vi bruke Groovy integrert med Java-kjøretid for å starte slike prosesser.

5. Praktiske applikasjoner

Så, nå har vi sett alle faktorene som er foreslått av tolvfaktormetoden. Å utvikle et program for å være en tolvfaktor-app har absolutt fordelene, spesielt når vi ønsker å distribuere dem som tjenester på skyen. Men som alle andre retningslinjer, rammeverk, mønstre, må vi spørre, er dette en sølvkule?

Ærlig talt, ingen enkelt metode i programvaredesign og utvikling hevder å være en sølvkule. Tolvfaktormetoden er ikke noe unntak. Samtidig som noen av disse faktorene er ganske intuitive, og mest sannsynlig gjør vi dem allerede, andre gjelder kanskje ikke for oss. Det er viktig å evaluere disse faktorene på bakgrunn av våre mål og deretter velge med omhu.

Det er viktig å merke seg at alle disse faktorene er der for å hjelpe oss med å utvikle et program som er modulært, uavhengig, bærbart, skalerbart og observerbart. Avhengig av applikasjonen, kan vi kanskje oppnå dem på andre måter bedre. Det er heller ikke nødvendig å vedta alle faktorene sammen, å vedta til og med noen av disse kan gjøre oss bedre enn vi var.

Til slutt er disse faktorene ganske enkle og elegante. De har større betydning i en tid der vi krever at applikasjonene våre har høyere gjennomstrømning og lavere ventetid uten praktisk talt nedetid og svikt. Å vedta disse faktorene gir oss den rette starten fra begynnelsen. Kombinert med mikroservicearkitektur og containerisering av applikasjoner, ser de bare ut til å treffe riktig sted.

6. Konklusjon

I denne opplæringen gikk vi gjennom begrepene tolvfaktormetodikk. Vi diskuterte hvordan vi kan utnytte en mikroservicearkitektur med Spring Boot for å levere dem effektivt. Videre undersøkte vi hver faktor i detalj og hvordan vi kan bruke dem på søknaden vår. Vi utforsket også flere verktøy for å anvende disse individuelle faktorene på en effektiv måte med hell.