Implementering av mikrotjenester i produksjonsmiljøer

Informatec Digital » Ressurser » Implementering av mikrotjenester i produksjonsmiljøer

Å ta i bruk en mikrotjenestearkitektur i et virkelighetsnært miljø handler ikke bare om å dele opp en monolitt i mindre biter; det innebærer å tenke nytt om infrastruktur, team, prosesser, data, sikkerhet og drift . Når systemet går fra teori til en produksjonsklynge, oppstår det problemer angående tjenesteoppdagelse, kontrakter mellom team, CI/CD, observerbarhet, robusthet og skalerbarhet. Hvis disse problemene ikke håndteres riktig, kan de gjøre mikrotjenester til distribuert kaos.

Den gode nyheten er at vi i dag har en mengde akkumulert erfaring fra organisasjoner som Netflix, Amazon, Google og andre store selskaper som driver hundrevis av mikrotjenester i produksjon . Ved å bygge på disse lærdommene, sammen med beste praksis i bedriftsmiljøer som bruker Kubernetes og OpenShift, kan vi utvikle en svært robust tilnærming til design, distribusjon og drift av mikrotjenester i stor skala uten å miste kontrollen.

Hvorfor distribuere mikrotjenester til produksjon (og når det ikke er verdt det)

En godt utformet mikrotjenestearkitektur lar deg jobbe med små, autonome og tverrfaglige team som tar eierskap til en komplett tjeneste. Hvert team opererer innenfor en veldefinert kontekst, kan distribuere ofte og ta fullt ansvar for tjenesten sin, noe som reduserer utviklingssyklustiden og akselererer leveringen av nye funksjoner.

En annen viktig fordel er uavhengig skalering per tjeneste . Du trenger ikke å overdimensjonere hele applikasjonen hvis bare katalogen, utsjekkingen eller det offentlige API-et opplever trafikktopper. Du kan justere hver mikrotjeneste horisontalt eller vertikalt i henhold til belastningsmønsteret, måle kostnaden for hver funksjon nøyaktig og opprettholde tilgjengeligheten selv om et bestemt område opplever en økning i forbruket.

Måten disse tjenestene pakkes og distribueres på, legger til rette for kontinuerlig implementering med lav risiko . Å gi ut hver mikrotjeneste uavhengig gjør det mye enklere å teste nye ideer og reversere problematiske versjoner: canary-distribusjoner, blå/grønne tilbakerullinger og automatiserte tilbakerullinger reduserer kostnadene ved feil og gir rom for eksperimentering.

Fra et teknologisk synspunkt fremmer mikrotjenester friheten til å velge språk, rammeverk og databaser for hver tjeneste. Ikke alle behov passer inn i den samme teknologistakken: du kan ha forretningstjenester i .NET eller Java, databehandling i Scala/Spark, spesialiserte tjenester i Python eller F#, eller AI-mikrotjenester i R. Dette kontrollerte mangfoldet lar deg bruke riktig verktøy for hvert tilfelle, uten å tvinge hele applikasjonen inn i et globalt teknologisk skifte.

Videre forenkler det å dele opp systemet i små, veldefinerte deler gjenbruk av funksjonaliteter som byggeklosser . En mikrotjeneste som opprinnelig ble opprettet som en del av en større funksjonalitet, kan senere gjenbrukes som en avhengighet av andre deler av systemet uten å omskrive logikken. Og fordi tjenestene er isolerte, resulterer en feil i en av dem vanligvis i delvis systemdegradering, ikke et fullstendig systembrudd, forutsatt at robusthet ble designet inn fra starten av.

Arkitektonisk og tjenestedesign

For at mikrotjenester skal fungere bra i produksjon, er det viktig å starte med en nøye utforming av tjenestegrenser og ansvar . I praksis begynner dette vanligvis med å identifisere grovkornede tjenester innenfor den eksisterende monolitten: store funksjonelle områder eller forretningsdomener (f.eks. bestillinger, katalog, brukere, fakturering) som allerede har en viss logisk separasjon.

Prosessen starter med disse store byggesteinene og innebærer å forbedre designet for å oppnå fint granulære mikrotjenester som opererer på et sammenhengende datasett , eier sin egen modell og vet nøyaktig hva de trenger å lese fra eller skrive til andre tjenester. Denne prosessen er vanligvis avhengig av domenedrevne designkonsepter (DDD) og avgrensede kontekster, noe som forhindrer at en mikrotjeneste blir en "mini-monolitt".

API-ene som eksponerer disse tjenestene må ha veldefinerte og stabile kontrakter . Dette innebærer grundig dokumentasjon (REST med OpenAPI, gRPC med .proto-filer osv.), eksplisitt versjonering, opprettholdelse av bakoverkompatibilitet der det er mulig, og automatisering av kontraktsvalidering for å oppdage endringer som ikke fungerer før de når produksjonsstadiet.

I miljøer med dusinvis eller hundrevis av tjenester er det avgjørende å innlemme robusthetsmønstre fra designfasen, slik at systemet er forberedt på delvise feil . Mønstre som effektbrytere, nye forsøk med backoff, veldefinerte tidsavbrudd, skott og mottrykk bidrar til å forhindre at feil på én tjeneste ødelegger resten. Kaostekniske verktøy som ChaosMonkey eller Gremlin er nyttige for praktisk testing av hvordan plattformen oppfører seg under simulerte avbrudd.

Mange komplekse systemer kombinerer relativt enkle CRUD-tjenester med mer sofistikerte tjenester som håndterer utviklende forretningsregler. Ikke alle mikrotjenester krever en kompleks intern arkitektur : noen kan være enkle HTTP-kontrollere med grunnleggende datatilgang, mens andre, for eksempel ordre- eller faktureringstjenester, kan utnytte mer avanserte mønstre (DDD, CQRS, domenehendelser osv.).

Produksjonsinfrastruktur: sky, containere og Kubernetes/OpenShift

Erfaring fra den virkelige verden viser at mikrotjenester yter mye bedre når de distribueres på skyinfrastruktur med containere og orkestrering enn på isolerte virtuelle maskiner. Plattformer som Kubernetes og OpenShift gir de nødvendige primitivene for å pakke tjenester som containere, skalere, oppdatere, lastebalansere og administrere høy tilgjengelighet.

Vanligvis pakkes hver mikrotjeneste i et containerbilde basert på et basisbilde for bedriften (for eksempel OpenJDK 21 for Java-tjenester) som administreres av infrastrukturteamet. Dette basisbildet holdes oppdatert med sikkerhetsoppdateringer, og når en ny versjon slippes, er utviklingsteamene ansvarlige for å gjenoppbygge og distribuere tjenestene sine i de tilsvarende miljøene.

I Kubernetes/OpenShift er den grunnleggende distribusjonsenheten poden, som innkapsler en eller flere containere . Vanligvis tilsvarer en mikrotjeneste en pod-type og distribueres ved hjelp av ressurser som Deployments (for tilstandsløse tjenester) eller StatefulSets (når det er en tilhørende tilstand). Fra starten av defineres et minimum antall replikaer per miljø, slik at test-, preproduksjons- og produksjonsmiljøer har tilgjengelighetsnivåer som er passende for deres kritiske karakter.

Automatisk skalering implementeres ved hjelp av HorizontalPodAutoscaler (HPA) , som justerer antall replikaer basert på målinger som CPU, minne eller andre tilpassede målinger. Plattformen må også konfigurere pod-anti-affinitetsregler for å distribuere replikaer av samme tjeneste på tvers av forskjellige noder, og dermed forhindre at en enkelt nodefeil tar ned alle forekomster.

Når det gjelder vertikal størrelsesendringer, brukes resources.requests og resources.limits til å definere CPU- og minneområdet en pod kan forbruke. For eksempel, å reservere minimum 100 MB CPU og 256 MB minne, og å tillate opptil henholdsvis 500 MB og 2 GB for en Java-tjeneste, og justere JVM-en (Xms, Xmx, Xss) for å utnytte containerens ressurser på en god måte.

Tilstandsadministrasjon: statsløse og tilstandsfulle mikrotjenester

De fleste mikrotjenester for bedrifter er utformet som tilstandsløse tjenester . Dette betyr at poden ikke lagrer informasjon som må overleve omstarter; tilstanden lagres i eksterne databaser, meldingskøer eller annen lagring. Denne tilnærmingen muliggjør dynamisk horisontal skalering og friksjonsfri distribusjon, ettersom enhver replika kan håndtere enhver forespørsel.

Det finnes imidlertid scenarier der det ikke finnes noe annet alternativ enn å ha tilstandsfulle mikrotjenester støttet av vedvarende volumer . Dette er tilfelle for noen databaser, distribuerte filsystemer eller komponenter som krever vedlikehold av lokale data. Disse podene distribueres vanligvis med StatefulSets, kobles til PersistentVolumes ved hjelp av PersistentVolumeClaims, og skaleres vertikalt i stedet for horisontalt.

Når en mikrotjeneste trenger permanent lagring, forespørres en PersistentVolumeClaim (PVC) med størrelse, tilgangsmodus og tiltenkt bruk , og driftsteamet klargjør den i henhold til plattformpolicyene. Denne PVC-en refereres til i distribusjonsmanifestet og monteres på poden slik at tjenesten kan lese og skrive data permanent.

Selv om tilstandsfulle modeller kan være nødvendige i spesifikke tilfeller, er den generelle anbefalingen å holde så mange tjenester som mulig tilstandsløse . Dette forenkler utrulling, skalering, robusthet og katastrofegjenoppretting, og reduserer driftskompleksitet i miljøer med mange mikrotjenester.

Datadesentralisering og tjenestesuverenitet

I tradisjonelle infrastrukturer er det vanlig å sentralisere databaser og lagring for å maksimere effektiviteten. Med mikrotjenester er denne tilnærmingen i konflikt med teamautonomi og avkobling . Hvis mange tjenester deler samme relasjonsskjema, kan enhver strukturell endring blokkere flere team og utilsiktet bryte kompatibiliteten.

Derfor anbefales det at hver mikrotjeneste eier sin egen datamodell og database , men i et utviklingsmiljø kjører databasen som en container i klyngen for å forenkle distribusjonen. I produksjon brukes vanligvis skystyrte instanser eller andre databaseservere med høy tilgjengelighet, samtidig som det alltid opprettholdes en klar eierskapsgrense.

Dette betyr ikke at det ikke finnes dataintegrasjon; det betyr at konsistens mellom tjenester håndteres med hendelser og asynkron meldingsbehandling , og at eventuell konsistens aksepteres når det er rimelig. Det er vanlig å bruke hendelsesbusser (RabbitMQ, Azure Service Bus, Kafka, osv.) for å forplante tilstandsendringer mellom mikrotjenester, noe som reduserer sterke avhengigheter av en enkelt database.

Skyplattformen gjør det enkelt for team å velge den optimale databasetypen for hver tjeneste (relasjonell, dokument, nøkkelverdi, tidsserie osv.), uten å pålegge en enkelt teknologi. Nøkkelen er at designet vurderer muligheten for å migrere skjemaer og strukturer uten å bryte kontrakter med andre tjenester, og at databeslutninger tas i samsvar med domenegrensene til hver mikrotjeneste.

Distribuert styring, team og organisering

Å gå over til mikrotjenester uten å endre organisasjonen er å be om trøbbel. I stedet for de klassiske funksjonelle siloene av nettverk, systemer, databaser, utvikling og drift , oppfordres en struktur basert på produktteam, som samler profiler fra utvikling, QA, DevOps og, der det er aktuelt, forretnings- eller dataanalytikere.

Hvert team er ansvarlig for én eller flere mikrotjenester innenfor samme funksjonelle domene, og håndterer både utvikling og drift (du bygger det, du kjører det) . Dette betyr at teamet administrerer sine CI/CD-pipelines, samarbeider med infrastruktur for spesifikke behov og deltar i overvåking og hendelsesrespons. Infrastrukturen og skyplattformen fokuserer på å tilby felles og standardiserte tjenester.

For å forhindre at denne distribuerte styringen ender opp i anarki, er det avgjørende å definere lette standarder og delte kataloger : godkjente basisbilder, distribusjonsmønstre, navnekonvensjoner for navnerom og tjenester, API-retningslinjer, Dockerfile- og Kustomize-maler, osv. Disse retningslinjene fungerer som "rekkverk" som orienterer team uten å blokkere deres evne til å ta beslutninger.

I mange bedriftsmiljøer brukes separate navnerom for hvert prosjekt eller domene , med minst ett per miljø (utvikling, forproduksjon, produksjon). Et stort prosjekt kan distribuere mikrotjenestene sine på tvers av flere navnerom, forutsatt at intern kommunikasjon er riktig konfigurert og sikkerhetsregler respekteres.

CI/CD, automatisering og GitOps-modellen

Når en arkitektur består av dusinvis eller hundrevis av mikrotjenester, er den eneste måten å holde dem operative på å investere tungt i ende-til-ende-automatisering . Dette inkluderer konsistente CI/CD-pipelines, deklarative distribusjonsdefinisjoner, automatisert testing og automatiske tilbakerullingsmekanismer.

En typisk kontinuerlig integrasjons- og leveringspipeline håndterer kompilering av kode, kjøring av tester, analyse av kvalitet med verktøy som SonarQube , bygging av containeravbildningen fra bedriftens Dockerfile og oppdatering av distribusjonsmanifester. Derfra bruker et system som ArgoCD eller lignende endringene i klyngen ved hjelp av en GitOps-tilnærming.

Hvert mikrotjenestelager inneholder vanligvis en standardisert Dockerfile, en pipeline-konfigurasjonsfil (f.eks. ci.json) , egenskaper for kvalitetsanalyse og en distribusjonskatalog med Kubernetes-definisjoner (Kustomize eller Helm) atskilt etter miljø. Lagerets webhooks utløser pipelinen når hendelser som tag-pushes eller merge-forespørsler oppstår.

GitOps-mønsteret etablerer Git-repositoriet som sannhetskilden for infrastruktur og distribusjon . Manifester for distribusjoner, tjenester, ConfigMaps, PVC-er, SealedSecrets og andre ressurser versjoneres der, og spesifikke verktøy håndterer synkronisering av klyngetilstanden med det som er definert i Git. Dette gir sporbarhet, gjennomgang av pull-forespørsler og enkle tilbakerullingsmuligheter.

Innstillinger, hemmeligheter og sikkerhet

I en moden mikrotjenesteplattform er konfigurasjonsadministrasjon avhengig av ConfigMaps for ikke-sensitive parametere og Secrets for konfidensiell informasjon . Hver mikrotjeneste har vanligvis sin egen miljøspesifikke ConfigMap, som lagrer egenskaper som URL-er til avhengige tjenester, funksjonalitetsflagg og justeringsparametere.

Hemmeligheter (legitimasjon, nøkler, tokener, sertifikater) håndteres med strenge sikkerhetsregler . I mindre kritiske miljøer kan det være akseptabelt å oppbevare dem i ren tekst som administreres av utviklingsteamet, men i preproduksjons- og produksjonsmiljøer anbefales det å kryptere dem ved hjelp av verktøy som Sealed Secrets eller spesifikke skybaserte eksterne administratorer.

Når en hemmelighet må deles mellom flere tjenester (for eksempel OTEL Collector-legitimasjon eller et felles nøkkellager ), kan den sentraliseres i et konfigurasjonslager per navneområde. Prosjekter som deler dette navneområdet koordinerer for å oppdatere det etter behov, og opprettholder kontroll over hvem som kan lese eller endre disse ressursene.

Når det gjelder kommunikasjonssikkerhet, er det dominerende mønsteret null tillit : ingenting tas for gitt bare fordi trafikken er «intern». Alle anrop mellom tjenester, både interne og eksterne, må autentiseres og autoriseres, ideelt sett med mTLS, JWT-tokens eller andre tilsvarende mekanismer. Mikrotjenester delegerer ikke blindt sikkerhet til API Manager eller nettverket; de utfører også sine egne kontroller.

Kommunikasjon mellom mikrotjenester, API-er og meldinger

I en moden mikrotjenestearkitektur er kommunikasjonslaget delt inn i flere tilfeller. For trafikk fra klienter (nettlesere, mobilapper, tredjeparter) til backend brukes publiserte API-er styrt av en API Manager . Disse API-ene er vanligvis RESTful (ofte ved bruk av OpenAPI) eller, i noen tilfeller, gRPC eksponert gjennom en gateway.

Kall mellom mikrotjenester som befinner seg i samme navneområde, eller til og med på tvers av flere navneområder innenfor samme prosjekt, håndteres vanligvis av interne Kubernetes-tjenester med intern DNS . Disse kallene omgår den offentlige API Manager, men overholder sikkerhets-, autentiserings- og autorisasjonspolicyer. For disse scenariene kan et tjenestenett eller interne gatewayer som håndhever felles policyer brukes.

Når mikrotjenester tilhører forskjellige funksjonelle domener eller prosjekter , regnes kommunikasjon som «offentlig» på organisasjonsnivå. I disse tilfellene er det vanlig praksis å bruke en API Manager eller en interoperabilitetsbuss, der kontrakter, kvoter, sikkerhet, versjonering og revisjon administreres, noe som forhindrer direkte kobling mellom uavhengige klynger eller navnerom.

Når det gjelder integrasjon med eldre eller eksterne systemer, som ikke alltid eksponerer moderne API-er, er det vanlig å stole på spesifikke koblinger over en interoperabilitetsbuss . På denne måten snakker mikrotjenester et felles språk (for eksempel hendelser eller interne REST API-er), og koblingen håndterer oversettelsen til og fra det eldre systemet, alltid med forbedret sikkerhet.

I tillegg til synkron kommunikasjon spiller asynkron meldingstjeneste en nøkkelrolle . Den brukes til å koble fra prosesser, absorbere topper, spre forretningshendelser mellom tjenester og forbedre robusthet. Hver hendelse har vanligvis et veldefinert og versjonert skjema, med sporingsmekanismer for å forhindre sammenbrudd mellom produsenter og forbrukere etter hvert som de utvikler seg.

Observerbarhet, OTEL-samler og drift

I et system som består av mange mikrotjenester er det nesten umulig å diagnostisere et problem uten god observerbarhet. Derfor integreres målinger, sentralisert logging og distribuerte spor fra designfasen , noe som gir en forståelse av hva som skjer på både tjeneste- og plattformnivå.

En sentral komponent i denne ordningen er OpenTelemetry Collector (OTEL Collector) , som distribueres i navnerommet eller sentralt for å samle inn målinger, logger og spor fra alle komponenter. Mikrotjenester trenger bare å vite at de skal sende telemetrien sin til Collector; Collector videresender den deretter til observasjonssystemene (Prometheus, Grafana, Jaeger, Elastic, osv.) uten at tjenesten trenger å vite detaljene.

For infrastrukturlaget brukes nodenivåsamlere og -eksportører til å samle inn CPU-, minne-, disk-, nettverks- og loggmålinger fra podene, og sende dem til henholdsvis Prometheus og Elasticsearch. Verktøy som Grafana og Kibana brukes til å visualisere denne informasjonen, bygge dashbord og definere varsler med smarte terskler og tilhørende runbooks.

Når et prosjekt trenger svært spesifikk behandling av sine målinger eller spor, kan det distribuere sin egen instans av OTEL Collector i navneområdet sitt, forutsatt at det har driftsgodkjenning og produksjonsvedlikeholdsmodellen er tydelig.

Teststrategi, kontrakter og erfaring med lokal utvikling

Testing av en distribuert mikrotjenestearkitektur krever en mer sofistikert teststrategi enn testing av en monolitt. Enhetstester er fortsatt viktige, men kontraktstester (for API-er og hendelser), integrasjonstester mellom tjenester og ende-til-ende-tester som krysser komplette flyter blir stadig viktigere.

For å forhindre kompatibilitetsproblemer brukes teknikker som forbrukerorientert kontraktstesting , der klienter definerer API-forventninger og tjenesteleverandører oppfyller dem. Hver kontraktsendring gjennomgår automatisert testing i CI-pipelinene, noe som forhindrer distribusjoner som ødelegger kjente forbrukere.

Når antallet tjenester vokser til over hundre, blir det upraktisk å replikere hele systemet lokalt. Derfor er utvikling avhengig av simuleringer av avhengige tjenester eller tunnelering til eksterne miljøer . Utviklere lanserer vanligvis bare et delsett av mikrotjenester og stopper resten med simuleringer, forfalskninger eller simulatorer, eller omdirigerer visse kall til et delt integrasjonsmiljø.

End-to-end-testing er i økende grad avhengig av flyktige miljøer eller «forhåndsvisninger» laget fra funksjonsgrener , som etablerer et isolert miljø med tjenestene som er relevante for den funksjonaliteten. Dette minimerer friksjon mellom team, reduserer «det fungerer på min maskin»-effekten og oppdager integrasjonsproblemer før det når dyrere miljøer som preproduksjon.

Mikrotjenesters distribusjonsmønstre i produksjon

Utover Kubernetes finnes det flere distribusjonsmønstre for mikrotjenester i produksjon som er verdt å kjenne til fordi de adresserer ulike scenarier for isolasjon, kostnader og modenhet . Et av de eldste mønstrene er flere tjenesteinstanser per vert, der en enkelt fysisk eller virtuell vert kjører flere instanser av forskjellige tjenester, vanligvis på en delt applikasjonsserver.

I mønsteret for tjenesteinstanser per virtuell maskin pakkes hver tjeneste som et virtuell maskin-avbildning (for eksempel en EC2 AMI) og kjører på sin egen instans. Dette gir sterk isolasjon på bekostning av høyere ressursforbruk og langsommere oppstartstider. Verktøy som Packer eller skyleverandørspesifikke løsninger gjør det enkelt å generere produksjonsklare virtuelle maskin-avbildninger.

Det mest utbredte mønsteret i dag er tjenesteinstansen per container , der hver mikrotjeneste bygges som et containerbilde og distribueres på en orkestrator (Kubernetes, OpenShift, osv.). Containere er lettere enn virtuelle maskiner, starter opp veldig raskt og lar deg pakke alt som trengs for tjenesten, noe som forenkler distribusjoner og muliggjør automatisk skalering.

Til slutt har serverløse tilnærminger, som AWS Lambda , blitt populære. Disse pakker funksjoner som svarer på HTTP-forespørsler eller hendelser fra andre tjenester (S3, DynamoDB, køer osv.), der brukerne bare betaler for det de bruker. Dette mønsteret er spesielt godt egnet for svært små mikrotjenester eller kortvarige hendelsesdrevne oppgaver, selv om det introduserer ytterligere hensyn angående observerbarhet, kaldstart og utførelsesgrenser.

I praksis ender mange organisasjoner opp med et hybrid økosystem: kjernedelen av systemet kjører på containere og orkestratorer, mens visse hjelpekomponenter implementeres som serverløse funksjoner eller som spesialiserte virtuelle maskiner, alltid med klare grensesnitt og veldefinerte protokoller for å integrere dem i helheten.

Når det gjelder å bringe alt dette til produksjon, er det ikke bare den valgte teknologien som utgjør forskjellen, men også å ha bygget en arkitektur som tolererer feil, skalerer der det er nødvendig, distribueres automatisk og er observerbar . Med produkttilpassede team, godt administrerte kontrakter, desentraliserte data og en robust skyplattform går mikrotjenester fra å være et løfte til å bli en effektiv og bærekraftig måte å utvikle komplekse applikasjoner på i årevis.