Valg av arkitekturstil (del 3)

Hei, Habr. I dag fortsetter jeg serien av publikasjoner som jeg har skrevet spesielt for å starte det nye kurset. «Software Architect».

Innledning

Valg av arkitektonisk stil er en av de grunnleggende tekniske avgjørelsene når man bygger et informasjonssystem. I denne artikkelserien ønsker jeg å gå gjennom de mest populære arkitektoniske stilene for applikasjonsbygging og svare på spørsmålet om når en arkitektonisk stil er mest foretrukket. I løpet av forklaringen vil jeg prøve å trekke en logisk følge som forklarer utviklingen av arkitektoniske stiler fra monolitter til mikrotjenester.

Sist tid snakket vi om forskjellige typer monolitter og bruken av komponenter for å bygge dem, både sammensettingskomponenter og distribusjonskomponenter. Vi gikk gjennom tjenesteorientert arkitektur.

Nå skal vi endelig definere hovedkarakteristikkene ved mikrotjenestearkitektur.

Forholdet mellom arkitekturer

Det er viktig å forstå at, basert på dataene i de foregående artiklene, er enhver tjeneste en komponent, men ikke enhver tjeneste er en mikrotjeneste.

Karakteristikker ved mikrotjenestearkitektur

De viktigste karakteristikkene ved mikrotjenestearkitektur er:

• Organisert rundt forretningsmuligheter (Organized around Business Capabilities)
• Produkter, ikke prosjekter (Products not Projects)
• Smarte innganger og dumme kanaler (Smart endpoints and dumb pipes)
• Desentralisert styring (Decentralized Governance)
• Desentralisert datastyring (Decentralized Data Management)
• Automatisering av infrastruktur (Infrastructure Automation)
• Designet for feil (Design for failure)
• Arkitektur med evolusjonær utvikling (Evolutionary Design)

Det første punktet kommer fra tjenesteorientert arkitektur, fordi mikrotjenester er et spesialtilfelle av tjenester. De andre punktene fortjener egen omtale.

Organisert rundt forretningsmuligheter (Organized around Business Capabilities)

Det er nå nødvendig å huske Conway's lov: organisasjoner som lager systemer, organiserer sin arkitektur for å speile interaksjonsstrukturen innen disse organisasjonene. Som et eksempel kan vi nevne tilfelle av å lage en kompilator: et team på syv personer utviklet en syvgjennomgangs kompilator, mens et team på fem laget en femgjennomgangs.

Når vi snakker om monolitter og mikrotjenester, hvis utviklingen er organisert etter funksjonelle avdelinger (backend, frontend, databaseadministratorer), får vi en klassisk monolitt.

For å oppnå mikrotjenester, må teamene organiseres rundt forretningsmuligheter (bestillingsteam, fraktteam, katalogteam). En slik organisering gir teamene mulighet til å fokusere på å lage spesifikke deler av applikasjonen.

Produkter, ikke prosjekter (Products not Projects)

Den prosjektbaserte tilnærmingen der teamet overfører utviklet funksjonalitet til andre team i tilfelle av mikrotjenestearkitektur passer rett og slett ikke. Teamet må støtte systemet gjennom hele livssyklusen. Selskapet Amazon, en av forkjemperne for implementering av mikrotjenester, har uttalt: «du bygger produktet, og du kjører det» («you build, you run it»). Den produktbaserte tilnærmingen lar teamet forstå forretningsbehovene.

Smarte innganger og dumme kanaler (Smart endpoints and dumb pipes)

SOA-arkitekturen la stor vekt på kommunikasjonskanaler, spesielt Enterprise Service Bus (tjenestebuss for bedrifter). Dette fører ofte til Erroneous Spaghetti Box, det vil si at kompleksiteten fra monolitten overføres til kompleksiteten av forbindelsene mellom tjenestene. I mikrotjenestearkitektur brukes kun enkle metoder for interaksjon.

Desentralisert styring (Decentralized Governance)

Nøkkelbeslutninger om mikrotjenester må tas av de som faktisk utvikler mikrotjenestene. Her forstås nøkkelbeslutningene som valg
av programmeringsspråk, distribusjonsmetodologier, kontrakter for offentlige grensesnitt, osv.

Desentralisert datastyring (Decentralized Data Management)

Den standard tilnærmingen der applikasjonen er avhengig av én database kan ikke ta hensyn til spesifikasjonene for hver enkelt tjeneste. MSA forutsetter desentralisert datastyring, inkludert bruk av ulike teknologier.

Automatisering av infrastruktur (Infrastructure Automation)

MSA støtter prosessene for kontinuerlig distribusjon og levering. Dette kan kun oppnås gjennom automatisering av prosessene. Utrullingen av et stort antall tjenester virker derfor ikke lenger skremmende. Distribusjonsprosessen bør bli monoton. Det andre aspektet knytter seg til forvaltningen av tjenester i et produktiv miljø. Uten automatisering blir det umulig å administrere prosesser som kjøres i ulike driftsmiljøer.

Designet for feil (Design for failure)

Numerøse tjenester i MSA er utsatt for feil. Behandling av feil i et distribuert system er en ganske ikke-triviell oppgave. Applikasjonsarkitekturen må være motstandsdyktig mot slike feil. Rebecca Parsons mener det er svært viktig at vi ikke lenger bruker selv mellomprosesskommunikasjon mellom tjenestene; i stedet bruker vi HTTP for kommunikasjon, som ikke engang nærmer seg den samme påliteligheten.

Arkitektur med evolusjonær utvikling (Evolutionary Design)

MSA-systemens arkitektur må utvikles evolusjonært. Det er ønskelig å begrense nødvendige endringer til grensene for én tjeneste. Det er også viktig å ta hensyn til innflytelsen på andre tjenester. Den tradisjonelle tilnærmingen er å prøve å løse dette problemet ved hjelp av versjonskontroll, men MSA forutsetter at versjonskontroll brukes
som en siste utvei.

Konklusjon

Etter alt det ovennevnte kan vi formulere hva mikrotjenester er. Mikrotjenestearkitektur er en tilnærming til utvikling av en separat applikasjon som et sett av små tjenester, der hver av dem kjører i sin egen prosess og samhandler via lette mekanismer, ofte gjennom API-grensesnitt av HTTP-ressurser. Disse tjenestene er bygget rundt forretningsmuligheter og kan implementeres uavhengig ved hjelp av fullt
automatiserte distribusjonsmekanismer. Det finnes et minimum av sentralisert kontroll over disse tjenestene, som kan være skrevet på forskjellige programmeringsspråk og bruke forskjellige datalagringsteknologier.

Les del 2

Kilde: habr.com