Oppdeling av monolitter

En monolittisk applikasjon er bygget som én samlet enhet. Alle komponentene – brukergrensesnittet, forretningslogikken og datatilgangslaget – er tett koblet sammen og kjører i én enkelt prosess.

Tenk på det som en stor bygning som inneholder alt. Slike applikasjoner er enklere å utvikle i starten, men kan bli vanskelige å administrere og skalere etter hvert som de vokser.

En mikrotjenestearkitektur deler derimot opp en applikasjon i en samling små, uavhengige tjenester. Hver tjeneste kjører i sin egen prosess og kommuniserer med de andre, vanligvis gjennom lette mekanismer som et API.

• Uavhengige: Tjenestene kan utvikles, distribueres og skaleres hver for seg.
• Spesialiserte: Hver tjeneste fokuserer på én enkelt forretningsfunksjon.
• Robuste: En feil i én tjeneste trenger ikke å føre til at hele systemet stopper.

Å dele opp en monolitt i mikrotjenester gir flere viktige fordeler, særlig når applikasjonen vokser:

• Skalerbarhet: Skaler individuelle tjenester basert på belastningen, i stedet for hele applikasjonen.
• Fleksibilitet: Bruk ulike teknologier (språk og databaser) for ulike tjenester.
• Raskere utvikling: Mindre kodebaser er enklere for team å administrere og distribuere uavhengig av hverandre.
• Bedre robusthet: En feil i én tjeneste får ikke hele systemet til å krasje.

«Strangler Fig Pattern» er en populær strategi for gradvis å dele opp en monolitt. Den innebærer å bygge nye mikrotjenester rundt den eksisterende monolitten og gradvis omdirigere trafikken til dem.

Etter hvert «kveler» de nye tjenestene den gamle funksjonaliteten, helt til den monolittiske delen kan fjernes. Dette reduserer risikoen ved å muliggjøre trinnvise endringer.

Et viktig trinn i oppdelingen er å identifisere avgrensede kontekster. Dette konseptet fra Domain-Driven Design (DDD) hjelper deg med å definere de naturlige grensene for de nye mikrotjenestene.

• Hva det er: En logisk grense der en bestemt domenemodell og det tilhørende språket er definert og gjelder.
• Hvorfor det er nyttig: Det bidrar til å sikre at hver tjeneste har et tydelig, uavhengig ansvar og sin egen spesialiserte forståelse av dataene.
• Eksempel: En «User Management»-kontekst håndterer brukerprofiler, mens en «Order Processing»-kontekst administrerer bestillinger.

En av de vanskeligste delene ved å dele opp en monolitt er å dele opp databasen. Hver mikrotjeneste bør ideelt sett eie sitt eget dataskjema, noe som betyr at den har sin egen dedikerte database eller et dedikert skjema i en delt database.

• Hvorfor: Kobler tjenestene fra hverandre og muliggjør uavhengig videreutvikling av dataene.
• Utfordringer: Opprettholde datakonsistens på tvers av tjenester og håndtere komplekse transaksjoner.
• Strategi: Trekk gradvis ut tabeller som er relevante for en ny tjeneste, og flytt dem til tjenestens egen database.

La oss se på en monolittisk applikasjon med brukeradministrasjon. Slik trekker du ut en UserService:

1. Identifiser all kode i monolitten som er knyttet til brukere (registrering, innlogging og profiloppdateringer).
2. Opprett en ny, separat mikrotjeneste kalt UserService.
3. Flytt brukerdataene (f.eks. users-tabellen) til en egen database som eies av den nye tjenesten.
4. Endre monolitten slik at den kaller API-et til UserService i stedet for å få direkte tilgang til brukerdataene.

Dette er en gradvis prosess som ofte bruker Strangler Fig-mønsteret.

Når du har flere mikrotjenester, må de kommunisere med hverandre. Ved en første oppdeling er direkte API-kall (f.eks. REST over HTTP) vanlig. En brukertjeneste kan eksponere endepunkter som andre tjenester kan bruke til å hente brukeropplysninger.

Etter hvert som systemene vokser, blir mer avanserte mønstre som meldingskøer avgjørende for asynkron kommunikasjon. Vi utforsker disse i neste leksjon!

I dag har vi utforsket hvordan monolittiske applikasjoner kan deles opp i mindre, håndterbare mikrotjenester. Vi har lært om:

• De viktigste forskjellene mellom monolitter og mikrotjenester.
• Fordeler som bedre skalerbarhet, fleksibilitet og robusthet.
• Strategier som Strangler Fig-mønsteret og identifisering av avgrensede kontekster.
• Utfordringene ved databaseoppdeling og innledende tjenestekommunikasjon.

Deretter skal vi gå dypere inn i hvordan disse tjenestene kommuniserer effektivt!