Bygning af apps med mikrotjenester giver udviklere større hastighed og smidighed end traditionelle arkitekturer. Hver kodeændring medfører dog stadig risici, hvilket sætter scenen for potentielle fejl, hvis problemer med kodekvaliteten ikke opdages og løses. For at mindske disse risici bør applikationsteams implementere moderne, cloud-native routingstrategier, der gør det lettere at teste for fare og sikre, at applikationer virkelig er klar til at blive implementeret i produktionsmiljøer.
De følgende fire implementeringsstrategier bruger ruteteknikker til sikkert at introducere nye tjenester og funktioner, teste funktionalitet og foretage iterative forbedringer, identificere og eliminere sårbarheder og mere. Tilsammen er disse tilgange en virtuel værktøjskasse, som applikationsteam kan nå ud til for at reducere risikoen under udvikling og implementering af applikationer, der drives af mikrotjenester. At forstå deres forskelle og ligheder vil være nøglen til at vide, hvordan man udnytter dem bedst muligt i dit eget miljø.
Kanariske implementeringer
Opkaldt efter den historiske praksis med at sende faktiske fugle i kulminer for at se, om luftkvaliteten var sikker for mennesker, er kanarieforbrug en måde at teste faktiske produktionsanvendelser med minimal indvirkning eller risiko på. Den såkaldte kanariefugl er en kandidatversion af en tjeneste, der fanger en delmængde af indkommende anmodninger (f.eks. 1%) for at afprøve nye funktioner eller builds. Hold kan derefter undersøge resultaterne, og hvis tingene går glat, øges implementeringen gradvist til 100% af servere eller noder. Og hvis ikke? Trafik kan hurtigt omdirigeres fra de kanariske implementeringer, mens den krænkende kode gennemgås og debugges.
Kanariske implementeringer kan implementeres via integrationer med edge routing-komponenter, der er ansvarlige for behandling af indgående brugertrafik. For eksempel i et Kubernetes-miljø kan en kanariefremstilling trykke på indgangskontrolkonfigurationen for at tildele specificerede procentsatser af trafikanmodninger til den stabile og kanariefremstillede implementering. Routing af trafik på denne måde sikrer, at nye tjenester har en chance for at bevise sig, inden de modtager en fuld implementering. Hvis de ikke gør det, sendes de tilbage for at få afhjulpet problemer og derefter gennemgå en ny runde test af kanariefremstilling, når de er klar.
A / B-test
A / B-test svarer til implementering af kanariefugl, med en vigtig forskel. Mens implementering af kanariefugle har tendens til at fokusere på at identificere fejl og ydeevne flaskehalse, fokuserer A / B-test på måling brugeraccept af nye applikationsfunktioner. F.eks. Vil udviklere måske vide, om nye funktioner er populære hos brugerne, om de er lette at finde, eller om brugergrænsefladen fungerer korrekt.
Dette mønster bruger software-routing til at aktivere og teste specifikke funktioner med forskellige trafiksegmenter og udsætte nye funktioner for en bestemt procentdel af trafikken eller for begrænsede grupper. A- og B-routing-segmenterne kan sende trafik til forskellige builds af softwaren, eller serviceinstanserne bruger endda den samme softwarebyggelse, men med forskellige konfigurationsattributter (som angivet i orchestratoren eller andre steder).
Blågrøn implementering
Det blågrønne implementeringsmønster involverer drift af to produktionsmiljøer parallelt: et til den nuværende stabile frigivelse (blå) og et til at iscenesætte og udføre test på den næste udgivelse (grøn). Denne strategi gør det muligt at frigive opdaterede softwareversioner på en let gentagelig måde. Devops-teams kan bruge denne teknik til at automatisere udrulning af nye versioner ved hjælp af en CI / CD-pipeline.
Med den blågrønne strategi implementerer udviklere en ny serviceversion sammen med den eksisterende forekomst, der i øjeblikket håndterer produktionstrafik. CI / CD-rørledningen bør indstilles til at udføre automatiserede røgtest for at kontrollere, at den nye version lykkes med dens nøglefunktionalitet. Når den nye tjeneste har bestået de sidste tests, kan trafikken derefter omdirigeres sikkert og automatisk til den ved hjælp af software-routing til problemfrit at styre trafikoverskæringen fra blå til grøn. Lige så vigtigt er det, at det i tilfælde af kritiske problemer i sidste øjeblik er simpelt at rulle implementeringen tilbage til den blå version, hvis der opstår kritiske problemer.
Trafikskygge
Trafikskygge svarer til blågrøn implementeringer, men i stedet for at bruge syntetiske test til at validere det "grønne" miljø duplikerer routingsteknologi al indgående produktionstrafik og spejler den til en separat testinstallation, der endnu ikke er offentlig. Således skaber trafikskygge et nøjagtigt billede af, hvad der ville ske, hvis den nye version blev implementeret, baseret på ægte trafik. Samtidig sikrer trafikskygge, at test ikke har nogen indflydelse på den faktiske produktion. I praksis kan udviklere vælge at duplikere en bestemt procentdel af anmodninger til en testtjeneste, hvor de derefter kan udføre integrationstest og performance-benchmarking (enten manuelt eller inden for rammerne af en automatiseret CI / CD-pipeline).
Virksomhedsudviklere udnytter allerede en række testteknikker designet til at sikre, at ny applikationskode opfylder visse krav. Enheds- og funktionstest forbliver for eksempel vigtige foranstaltninger, som koden skal ryddes. Imidlertid gør arten af mikrotjenestebaserede arkitekturer end-to-end integrationstest mere afgørende end nogensinde. I betragtning af omfanget af indbyrdes afhængigheder og risikoen for langsigtet interface-drift, der er forbundet med mikrotjenestearkitekturer, har syntetiske tests stadig værdi, men vil i sidste ende ikke nøjagtigt repræsentere alle interaktionerne mellem tjenester i produktionsmiljøer.
Fire strategier, et mål
Disse routingsteknikker tilbyder alle forskellige, men alligevel relaterede metoder til at hjælpe med at opdage, afbøde og teste af defekter i mikrotjenester-baserede applikationer. De er potente værktøjer til at tackle fejl, ydeevneproblemer og sikkerhedssårbarheder, især når de implementeres som en del af en ende-til-ende kontinuerlig integration og levering (CI / CD) pipeline.
Hvilken af disse metoder, der er bedst egnet til din egen sag, vil i høj grad afhænge af, hvilke bekymringer der er mest afgørende. For eksempel kan en større UI-eftersyn have stor gavn af A / B-test, mens en blågrøn implementering kan være uvurderlig for at se, hvordan en ny funktion kan påvirke ydeevnen for et eksisterende datalager.
Ofte kan en kombination af disse teknikker tilbyde den bedste dækning. Det er dog vigtigt at overveje, hvor godt hver enkelt kan integreres med din eksisterende udviklingsmodel. Kanariske implementeringer af individuelle funktioner kan være bedre egnet til agile udviklingsmetoder end f.eks. Blågrønne implementeringer af fulde versioner. Og mens trafikskygge kan give enestående synlighed af applikationsydeevne før implementering, kan det være vanskeligt og tidskrævende at implementere og dyrt med hensyn til databehandlingsressourcer.
Uanset hvordan du bruger dem, kan routingsteknikker som disse være en uvurderlig del af softwareudviklingsprocessen, især da industrien bevæger sig væk fra traditionelle, monolitiske applikationer mod cloud-native systemer baseret på mikrotjenester. Ved at anvende en, nogle eller alle disse teknikker, mens de forbliver opmærksomme på deres specifikke fordele, kan applikationsteam bedre sikre integriteten og succesen af deres projekter og bevæge sig mere trygt i produktionen.
Manuel Zapf er leder af produkt OSS hos Containous, et cloud-native netværksfirma bag open source-projekterne Traefik og Maesh.
—
New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle forespørgsler til [email protected].
