Hej, Habr. I dag fortsætter jeg min række af indlæg, som jeg har skrevet specielt til lanceringen af det nye kursusforløb. .
Introduktion
Valget af arkitektonisk stil er en af de grundlæggende tekniske beslutninger, når man bygger et informationssystem. I denne række artikler vil jeg undersøge de mest populære arkitektoniske stilarter for applikationsopbygning og besvare spørgsmålet om, hvornår hvilken arkitektonisk stil er mest foretrukken. Undervejs vil jeg forsøge at føre en logisk tråd, der forklarer udviklingen af arkitektoniske stilarter fra monolitter til mikroservices.
Sidste gang talte vi om de forskellige typer af monolitter og brugen af komponenter til deres opbygning, både samlingskomponenter og distributionskomponenter. Vi kiggede på serviceorienteret arkitektur.
Nu vil vi endelig definere de grundlæggende karakteristika for mikrotjenestearkitektur.
Forhold mellem arkitekturer
Det er vigtigt at forstå, at ud fra oplysningerne i de tidligere artikler, er enhver service en komponent, men ikke enhver service er en mikrotjeneste.
Karakteristika for mikrotjenestearkitektur
De grundlæggende karakteristika ved mikrotjenestearkitektur er:
- Organiseret omkring forretningsmuligheder (Organized around Business Capabilities)
- Produkter, ikke projekter (Products not Projects)
- Smarte indgange og dumme kanaler (Smart endpoints and dumb pipes)
- Decentraliseret styring (Decentralized Governance)
- Decentraliseret datastyring (Decentralized Data Management)
- Automatisering af infrastruktur (Infrastructure Automation)
- Design for fejl (Design for failure)
- Arkitektur med evolutionært design (Evolutionary Design)
Den første punkt stammer fra serviceorienteret arkitektur, fordi mikrotjenester er en særlig form for services. De andre punkter fortjener en særskilt behandling.
Organiseret omkring forretningsmuligheder (Organized around Business Capabilities)
Det er nu vigtigt at huske på Conway's lov: organisationer, der skaber systemer, organiserer deres arkitektur, der afspejler interaktionsstrukturen inden for disse organisationer. Et eksempel er skabelsen af en compiler: et team på syv mennesker udviklede en syv-pass compiler, mens et team på fem mennesker udviklede en fem-pass.
Når vi taler om monolitter og mikrotjenester, så hvis udviklingen er organiseret efter funktionelle afdelinger (backend, frontend, databasedministratorer), så bliver det en klassisk monolit.
For at opnå mikrotjenester skal teams organiseres efter forretningsmuligheder (ordreredesign, forsendelse, katalog). En sådan organisation vil give teams mulighed for at fokusere på at skabe specifikke dele af applikationen.
Produkter, ikke projekter (Products not Projects)
Den projektorienterede tilgang, hvor et team overdrager den udviklede funktionalitet til andre teams i tilfælde af mikrotjenestearkitektur, er slet ikke passende. Teamet skal understøtte systemet gennem hele dets livscyklus. Amazon, en af frontløberne inden for implementering af mikrotjenester, har udtalt: «du skaber produktet, og du lancerer det» («you build, you run it»). Den produktorienterede tilgang giver teamet mulighed for at forstå forretningsbehovene.
Smarte indgange og dumme kanaler (Smart endpoints and dumb pipes)
SOA-arkitekturen lagde stor vægt på kommunikationskanaler, især Enterprise Service Bus (servicebus for virksomheder). Dette fører ofte til Erroneous Spaghetti Box, hvilket betyder, at kompleksiteten i monolitten overgår i kompleksiteten af forbindelserne mellem tjenester. I mikrotjenestearkitekturen anvendes kun enkle metoder til interaktion.
Decentraliseret styring (Decentralized Governance)
Nøglebeslutninger om mikrotjenester skal træffes af de personer, der faktisk udvikler mikrotjenesterne. Her forstås nøglebeslutninger som valg
af programmeringssprog, implementeringsmetodologier, kontrakter for offentlige grænseflader osv.
Decentraliseret datastyring (Decentralized Data Management)
Den standardmæssige tilgang, hvor applikationen er afhængig af en enkelt database, kan ikke tage hensyn til de specifikke krav i hver enkelt tjeneste. MSA antager decentraliseret datastyring, op til brugen af forskellige teknologier.
Automatisering af infrastruktur (Infrastructure Automation)
MSA understøtter processer for kontinuerlig udrulning og levering. Dette kan kun opnås gennem automatisering af processerne. Tilsvarende virker udrulningen af et stort antal tjenester ikke mere skræmmende. Udrulningsprocessen skal blive kedelig. Den anden aspekt relaterer til håndtering af tjenester i produktionsmiljøet. Uden automatisering bliver styringen af processer, der kører i forskellige driftsmiljøer, umulig.
Design for fejl (Design for failure)
De mange MSA-tjenester er udsat for fejl. Behandling af fejl i et distribueret system er en ret kompleks opgave. Applikationsarkitekturen skal være modstandsdygtig over for sådanne fejl. Rebecca Parsons anser det for meget vigtigt, at vi ikke længere bruger endda intern procesinteraktion mellem tjenesterne; i stedet bruger vi HTTP til kommunikation, som sjældent er lige så pålideligt.
Arkitektur med evolutionært design (Evolutionary Design)
Arkitektur MSA-systemet skal udvikles evolutionært. Det er ønskeligt at begrænse nødvendige ændringer til grænserne for én tjeneste. Det er også vigtigt at tage hensyn til indflydelsen på andre tjenester. Den traditionelle tilgang er at forsøge at løse dette problem ved hjælp af versionsstyring, men MSA forudsætter, at versionsstyring bruges som
en sidste udvej.
Konklusion
Efter alt det ovenstående kan vi formulere, hvad mikrotjenester er. Mikrotjenestearkitektur er en tilgang til udvikling af en enkelt ansøgning som et sæt små tjenester, hvor hver især kører i sin egen proces og interagerer gennem lettede mekanismer, ofte API-grænsefladen for HTTP-ressourcer. Disse tjenester er bygget på forretningsmuligheder og kan implementeres uafhængigt ved hjælp af en fuldt
automatiseret implementeringsmekanisme. Der er et minimumsniveau for centraliseret styring af disse tjenester, som kan være skrevet på forskellige programmeringssprog og bruge forskellige datalagringsteknologier.
Kilde: habr.com
