Hej, Habr. I dag fortsætter jeg en række publikationer, som jeg skrev specifikt til starten på en ny strøm af kurset. .
Indledning
Valget af arkitektonisk stil er en af de grundlæggende tekniske beslutninger, når man bygger et informationssystem. I denne serie af artikler foreslår jeg at analysere de mest populære arkitektoniske stilarter til byggeapplikationer og besvare spørgsmålet om, hvornår hvilken arkitektonisk stil er mest at foretrække. I præsentationsprocessen vil jeg forsøge at tegne en logisk kæde, der forklarer udviklingen af arkitektoniske stilarter fra monolitter til mikrotjenester.
Sidste gang talte vi om de forskellige typer monolitter og brugen af komponenter til at bygge dem, både byggekomponenter og implementeringskomponenter. Vi forstår serviceorienteret arkitektur.
Nu vil vi endelig definere hovedegenskaberne for en mikroservicearkitektur.
Sammenhæng mellem arkitekturer
Det er nødvendigt at forstå, at baseret på definitionerne givet i tidligere artikler, er enhver tjeneste en komponent, men ikke enhver tjeneste er en mikrotjeneste.
Karakteristika for mikroservicearkitektur
De vigtigste egenskaber ved mikroservicearkitektur er:
- Organiseret omkring Business Capabilities
- Produkter ikke projekter
- Smarte endepunkter og dumme rør
- Decentral styring
- Decentraliseret datahåndtering
- Infrastruktur automatisering
- Design til fiasko
- Arkitektur med evolutionær udvikling (Evolutionært design)
1. punkt kommer fra serviceorienteret arkitektur, fordi mikrotjenester er et specialtilfælde af tjenester. Andre punkter fortjener særskilt overvejelse.
Organiseret omkring Business Capabilities
Nu er det nødvendigt at huske Conways lov: organisationer, der skaber systemer, organiserer sin arkitektur og kopierer interaktionsstrukturen inden for disse organisationer. Som et eksempel kan vi huske tilfældet med at oprette en compiler: et team på syv personer udviklede en syv-pass compiler, og et team på fem udviklede en fem-pass compiler.
Hvis vi taler om monolitter og mikrotjenester, så hvis udvikling er organiseret af funktionelle afdelinger (backend, frontend, databaseadministratorer), så får vi en klassisk monolit.
For at opnå mikrotjenester skal teams organiseres efter forretningskapacitet (ordrer, forsendelser, katalogteam). Denne organisation vil give teams mulighed for at fokusere på at bygge specifikke dele af applikationen.
Produkter ikke projekter
En projekttilgang, hvor et team overfører den udviklede funktionalitet til andre teams, er fuldstændig uegnet i tilfælde af en mikroservicearkitektur. Teamet skal understøtte systemet gennem hele dets livscyklus. Amazon, en af lederne inden for implementering af mikrotjenester, udtalte: "du bygger, du kører det." Produkttilgangen giver teamet mulighed for at mærke virksomhedens behov.
Smarte endepunkter og dumme rør
SOA-arkitektur lagde stor vægt på kommunikationskanaler, især Enterprise Service Bus. Hvilket ofte fører til Fejlagtig Spaghetti Box, det vil sige, at kompleksiteten af monolitten bliver til kompleksiteten af forbindelser mellem tjenester. Mikroservicearkitektur bruger kun simple kommunikationsmetoder.
Decentral styring
Nøglebeslutninger om mikrotjenester bør træffes af de mennesker, der rent faktisk udvikler mikrotjenesterne. Her betyder nøglebeslutninger valg
programmeringssprog, implementeringsmetodik, kontrakter om offentlige grænseflader osv.
Decentraliseret datahåndtering
Standardtilgangen, hvor applikationen er afhængig af en enkelt database, kan ikke tage højde for de særlige forhold ved hver specifik tjeneste. MSA involverer decentraliseret datahåndtering, herunder brug af forskellige teknologier.
Infrastruktur automatisering
MSA understøtter kontinuerlige implementerings- og leveringsprocesser. Dette kan kun opnås ved at automatisere processer. Samtidig ligner implementeringen af et stort antal tjenester ikke længere noget skræmmende. Implementeringsprocessen burde blive kedelig. Det andet aspekt er relateret til service management i et produktmiljø. Uden automatisering bliver det umuligt at administrere processer, der kører i forskellige driftsmiljøer.
Design til fiasko
Adskillige MSA-tjenester er tilbøjelige til at fejle. Samtidig er fejlhåndtering i et distribueret system ikke en triviel opgave. Applikationsarkitekturen skal være modstandsdygtig over for sådanne fejl. Rebecca Parsons synes, det er meget vigtigt, at vi ikke længere engang bruger proceskommunikation mellem tjenester; i stedet tyer vi til HTTP til kommunikation, som ikke er nær så pålidelig.
Arkitektur med evolutionær udvikling (Evolutionært design)
MSA-systemets arkitektur bør udvikle sig evolutionært. Det er tilrådeligt at begrænse de nødvendige ændringer til grænserne for en enkelt tjeneste. Påvirkningen af andre tjenester skal også tages i betragtning. Den traditionelle tilgang er at forsøge at løse dette problem med versionering, men MSA foreslår at bruge versionering i
som en sidste udvej.
Konklusion
Efter alt ovenstående kan vi formulere, hvad mikrotjenester er. Mikroservicearkitektur er en tilgang til at udvikle en enkelt applikation som en samling af små tjenester, der hver kører i sin egen proces og interagerer gennem lette mekanismer, ofte en HTTP-ressource API. Disse tjenester er bygget på forretningskapaciteter og kan implementeres uafhængigt ved hjælp af fuldt ud
automatiseret implementeringsmekanisme. Der er et minimumsniveau af centraliseret styring af disse tjenester, som kan skrives på forskellige programmeringssprog og bruge forskellige datalagringsteknologier.
Kilde: www.habr.com