Hei, Habr. I dag fortsetter jeg en serie publikasjoner som jeg skrev spesielt for starten av en ny strøm av kurset. .
Innledning
Valget av arkitektonisk stil er en av de grunnleggende tekniske avgjørelsene når man bygger et informasjonssystem. I denne artikkelserien foreslår jeg å analysere de mest populære arkitektoniske stilene for byggeapplikasjoner og svare på spørsmålet om når hvilken arkitektonisk stil er mest å foretrekke. I prosessen med presentasjonen vil jeg prøve å tegne en logisk kjede som forklarer utviklingen av arkitektoniske stiler fra monolitter til mikrotjenester.
Forrige gang snakket vi om de forskjellige typene monolitter og bruken av komponenter for å bygge dem, både byggekomponenter og distribusjonskomponenter. Vi forstår serviceorientert arkitektur.
Nå skal vi endelig definere hovedkarakteristikkene til en mikrotjenestearkitektur.
Forholdet mellom arkitekturer
Det er nødvendig å forstå at basert på definisjonene gitt i tidligere artikler, er enhver tjeneste en komponent, men ikke hver tjeneste er en mikrotjeneste.
Kjennetegn ved mikroservicearkitektur
Hovedkarakteristikkene til mikrotjenestearkitektur er:
- Organisert rundt Business Capabilities
- Produkter ikke prosjekter
- Smarte endepunkter og dumme rør
- Desentralisert styring
- Desentralisert databehandling
- Infrastrukturautomatisering
- Design for feil
- Arkitektur med evolusjonær utvikling (Evolutionary Design)
1. punkt kommer fra tjenesteorientert arkitektur fordi mikrotjenester er et spesialtilfelle av tjenester. Andre punkter fortjener separat vurdering.
Organisert rundt Business Capabilities
Nå er det nødvendig å huske Conways lov: organisasjoner som lager systemer organiserer sin arkitektur, kopierer strukturen for samhandling i disse organisasjonene. Som et eksempel kan vi huske tilfellet med å lage en kompilator: et team på syv personer utviklet en syv-pass kompilator, og et team på fem utviklet en fem-pass kompilator.
Hvis vi snakker om monolitter og mikrotjenester, så hvis utviklingen er organisert av funksjonelle avdelinger (backend, frontend, databaseadministratorer), får vi en klassisk monolitt.
For å få mikrotjenester må team organiseres etter forretningskapasitet (ordrer, forsendelser, katalogteam). Denne organisasjonen vil tillate team å fokusere på å bygge spesifikke deler av applikasjonen.
Produkter ikke prosjekter
En prosjekttilnærming der et team overfører den utviklede funksjonaliteten til andre team er fullstendig uegnet i tilfellet med en mikrotjenestearkitektur. Teamet må støtte systemet gjennom hele livssyklusen. Amazon, en av lederne innen implementering av mikrotjenester, uttalte: "du bygger, du driver det." Produkttilnærmingen lar teamet føle bedriftens behov.
Smarte endepunkter og dumme rør
SOA-arkitektur ga stor oppmerksomhet til kommunikasjonskanaler, spesielt Enterprise Service Bus. Noe som ofte fører til feilaktig spaghettiboks, det vil si at kompleksiteten til monolitten blir til kompleksiteten av forbindelser mellom tjenester. Mikrotjenestearkitektur bruker bare enkle kommunikasjonsmetoder.
Desentralisert styring
Nøkkelavgjørelser om mikrotjenester bør tas av personene som faktisk utvikler mikrotjenestene. Her betyr nøkkelbeslutninger valg
programmeringsspråk, distribusjonsmetodikk, offentlige grensesnittkontrakter, etc.
Desentralisert databehandling
Standardtilnærmingen, der applikasjonen er avhengig av en enkelt database, kan ikke ta hensyn til spesifikasjonene til hver spesifikk tjeneste. MSA innebærer desentralisert datahåndtering, inkludert bruk av ulike teknologier.
Infrastrukturautomatisering
MSA støtter kontinuerlig distribusjon og leveringsprosesser. Dette kan kun oppnås ved å automatisere prosesser. Samtidig ser det ikke lenger ut som noe skummelt å distribuere et stort antall tjenester. Utrullingsprosessen bør bli kjedelig. Det andre aspektet er knyttet til service management i et produktmiljø. Uten automatisering blir det umulig å administrere prosesser som kjører i forskjellige driftsmiljøer.
Design for feil
Tallrike MSA-tjenester er utsatt for feil. Samtidig er ikke feilhåndtering i et distribuert system en triviell oppgave. Applikasjonsarkitekturen må være motstandsdyktig mot slike feil. Rebecca Parsons synes det er veldig viktig at vi ikke lenger bruker prosesskommunikasjon mellom tjenester, i stedet tyr vi til HTTP for kommunikasjon, som ikke er på langt nær like pålitelig.
Arkitektur med evolusjonær utvikling (Evolutionary Design)
Arkitekturen til MSA-systemet bør utvikles evolusjonært. Det er tilrådelig å begrense de nødvendige endringene til grensene for en enkelt tjeneste. Påvirkningen på andre tjenester må også tas i betraktning. Den tradisjonelle tilnærmingen er å prøve å løse dette problemet med versjonering, men MSA foreslår å bruke versjonering i
som en siste utvei.
Konklusjon
Etter alt det ovennevnte kan vi formulere hva mikrotjenester er. Mikrotjenestearkitektur er en tilnærming til å utvikle en enkelt applikasjon som en samling av små tjenester, som hver kjører i sin egen prosess og samhandler gjennom lette mekanismer, ofte HTTP-ressurs-APIer. Disse tjenestene er bygd på forretningsevner og kan distribueres uavhengig ved bruk av fullt ut
automatisert distribusjonsmekanisme. Det er et minimumsnivå for sentralisert styring av disse tjenestene, som kan skrives på forskjellige programmeringsspråk og bruke forskjellige datalagringsteknologier.
Kilde: www.habr.com