Å bygge apper med mikrotjenester gir utviklere større hastighet og smidighet enn tradisjonelle arkitekturer. Hver kodeendring medfører imidlertid fortsatt risiko, og setter scenen for potensielle feil hvis kodekvalitetsproblemer ikke blir oppdaget og adressert. For å redusere disse risikoene, bør applikasjonsteamene implementere moderne, cloud-native rutestrategier som gjør det lettere å teste for fare og sikre at applikasjoner virkelig er klare til å distribueres i produksjonsmiljøer.
Følgende fire distribusjonsstrategier bruker ruteteknikker for å trygt introdusere nye tjenester og funksjoner, teste funksjonalitet og gjøre iterative forbedringer, identifisere og eliminere sårbarheter og mer. Til sammen er disse tilnærmingene en virtuell verktøykasse som applikasjonsteam kan nå inn for å redusere risikoen under utvikling og distribusjon av applikasjoner som drives av mikrotjenester. Å forstå deres forskjeller og likheter vil være nøkkelen til å vite hvordan du kan utnytte dem best i ditt eget miljø.
Kanariutplasseringer
Oppkalt etter den historiske praksisen med å sende faktiske fugler til kullgruver for å se om luftkvaliteten var trygg for mennesker, er kanariforbruk en måte å teste faktiske produksjonsutplasseringer med minimal innvirkning eller risiko. Den såkalte kanarifuglen er en kandidatversjon av en tjeneste som fanger en delmengdeprosent av innkommende forespørsler (si 1%) for å prøve ut nye funksjoner eller bygg. Team kan deretter undersøke resultatene, og hvis ting går greit, kan du gradvis øke distribusjonen til 100% av servere eller noder. Og hvis ikke? Trafikk kan raskt omdirigeres fra kanariforpliktelsene mens den krenkende koden blir gjennomgått og feilsøkt.
Kanariske distribusjoner kan implementeres via integrasjoner med edge routing-komponenter som er ansvarlige for behandling av innkommende brukertrafikk. For eksempel, i et Kubernetes-miljø, kan en kanaridistribusjon trykke på inngangskontrollerkonfigurasjonen for å tildele angitte prosentandeler av trafikkforespørsler til stabile og kanariske distribusjoner. Å rute trafikk på denne måten sikrer at nye tjenester har en sjanse til å bevise seg før de mottar en full utrulling. Hvis de ikke gjør det, sendes de tilbake for å få utbedret problemer og deretter gjennomgå en ny runde med testing av kanaridistribusjon når de er klare.
A / B-testing
A / B-testing ligner på kanariforbruk, med en viktig forskjell. Mens kanariforbruk har en tendens til å fokusere på å identifisere feil og ytelsesflaskehalser, fokuserer A / B-testing på måling brukeraksept av nye applikasjonsfunksjoner. For eksempel vil utviklere kanskje vite om nye funksjoner er populære blant brukere, om de er enkle å oppdage, eller om brukergrensesnittet fungerer som det skal.
Dette mønsteret bruker ruting av programvare for å aktivere og teste spesifikke funksjoner med forskjellige trafikksegmenter, og utsette nye funksjoner for en spesifisert prosentandel av trafikken, eller for begrensede grupper. Rutesegmentene A og B kan sende trafikk til forskjellige versjoner av programvaren, eller tjenesteforekomstene kan til og med bruke den samme programvarebyggingen, men med forskjellige konfigurasjonsattributter (som spesifisert i orkestratoren eller andre steder).
Blågrønne distribusjoner
Det blågrønne distribusjonsmønsteret innebærer å operere to produksjonsmiljøer parallelt: ett for den nåværende stabile utgivelsen (blå) og et for å iscenesette og utføre testing på neste utgivelse (grønt). Denne strategien gjør at oppdaterte programvareversjoner kan slippes på en lett repeterbar måte. Devops-team kan bruke denne teknikken til å automatisere utrulling av ny versjon ved hjelp av en CI / CD-rørledning.
Med den blågrønne strategien distribuerer utviklere en ny tjenesteversjon ved siden av den eksisterende forekomsten som for tiden håndterer produksjonstrafikk. CI / CD-rørledningen bør settes til å utføre automatiserte røykprøver for å verifisere at den nye versjonen lykkes med nøkkelfunksjonaliteten. Når den nye tjenesten har bestått de siste testene, kan trafikken omdirigeres trygt og automatisk til den ved hjelp av ruting av programvare for å sømløst administrere trafikkavskjæringen fra blått til grønt. Like viktig er det at når det gjelder kritiske problemer i siste øyeblikk, er det enkelt å rulle tilbake distribusjonen til den blå versjonen hvis det oppstår kritiske problemer.
Trafikkskygging
Trafikkskygging ligner på blågrønne distribusjoner, men i stedet for å bruke syntetiske tester for å validere det "grønne" miljøet, dupliserer ruteteknologien all innkommende produksjonstrafikk og speiler den til en egen testdistribusjon som ennå ikke er offentlig. Dermed skaper trafikkskygging et nøyaktig bilde av hva som ville skje hvis den nye versjonen ble distribuert, basert på ekte trafikk. Samtidig sørger trafikkskygging for at tester ikke har noen innvirkning på faktisk produksjon. I praksis kan utviklere velge å duplisere en angitt prosentandel av forespørsler til en testtjeneste, der de deretter kan utføre integrasjonstesting og ytelses benchmarking (enten manuelt eller innenfor rammen av en automatisk CI / CD-rørledning).
Bedriftsutviklere bruker allerede en rekke testteknikker som er designet for å sikre at ny applikasjonskode oppfyller visse krav. Enhets- og funksjonstester forblir for eksempel viktige tiltak som koden må fjerne. Imidlertid gjør arten av mikrotjenestebaserte arkitekturer end-to-end-integrasjonstesting mer avgjørende enn noen gang. Gitt mengden av gjensidig avhengighet og risikoen for langsiktig grensesnittdrift som er iboende for mikrotjenestearkitekturer, har syntetiske tester fortsatt verdi, men vil til slutt ikke være nøyaktig som representerer alle interaksjoner mellom tjenester i produksjonsmiljøer.
Fire strategier, ett mål
Disse ruteteknikkene tilbyr alle forskjellige, men likevel relaterte metoder for å hjelpe til med å oppdage, redusere og teste mangler i mikrotjenestebaserte applikasjoner. De er potente verktøy for å løse feil, ytelsesproblemer og sikkerhetsproblemer, spesielt når de distribueres som en del av en end-to-end kontinuerlig integrasjon og levering (CI / CD) -rørledning.
Hvilken av disse metodene som passer best for din egen sak, vil i stor grad avhenge av hvilke bekymringer som er mest avgjørende. For eksempel kan en større UI-revisjon ha stor nytte av A / B-testing, mens en blågrønn distribusjon kan være uvurderlig for å se hvordan en ny funksjon kan påvirke ytelsen til en eksisterende datalager.
Ofte kan en kombinasjon av disse teknikkene tilby best dekning. Det er imidlertid viktig å vurdere hvor godt hver enkelt vil integrere med din eksisterende utviklingsmodell. Kanariske distribusjoner av individuelle funksjoner kan være bedre egnet for smidige utviklingsmetoder enn for eksempel blågrønne distribusjoner av fullversjoner. Og mens trafikkskygge kan gi god oversikt over applikasjonsytelsen før distribusjon, kan det være vanskelig og tidkrevende å implementere og kostbart når det gjelder databehandlingsressurser.
Uansett hvordan du bruker dem, kan ruteteknikker som disse være en uvurderlig del av programvareutviklingsprosessen, spesielt når industrien beveger seg vekk fra tradisjonelle, monolitiske applikasjoner mot sky-native systemer basert på mikrotjenester. Ved å bruke en, noen eller alle disse teknikkene mens de holder seg oppmerksom på deres spesifikke fordeler, kan applikasjonsteam bedre sikre integriteten og suksessen til sine prosjekter og bevege seg mer trygt inn i produksjonen.
Manuel Zapf er leder for produktet OSS hos Containous, et skyinnfødt nettverksselskap bak open source-prosjektene Traefik og Maesh.
—
New Tech Forum er et sted for å utforske og diskutere ny teknologi i enestående dybde og bredde. Valget er subjektivt, basert på vårt valg av teknologiene vi mener er viktige og av størst interesse for leserne. godtar ikke markedsføringssikkerhet for publisering og forbeholder seg retten til å redigere alt bidratt innhold. Send alle henvendelser til [email protected].
