Hej, Habr. Idag fortsätter jag en serie publikationer som jag skrivit specifikt för starten av en ny ström av kursen. .
Inledning
Valet av arkitektonisk stil är ett av de grundläggande tekniska besluten när man bygger ett informationssystem. I den här artikelserien föreslår jag att analysera de mest populära arkitektoniska stilarna för byggnadsapplikationer och svara på frågan om när vilken arkitektonisk stil är mest att föredra. I presentationsprocessen kommer jag att försöka rita en logisk kedja som förklarar utvecklingen av arkitektoniska stilar från monoliter till mikrotjänster.
Förra gången pratade vi om de olika typerna av monoliter och användningen av komponenter för att bygga dem, både byggkomponenter och distributionskomponenter. Vi förstår serviceorienterad arkitektur.
Nu kommer vi äntligen att definiera de viktigaste egenskaperna hos en mikrotjänstarkitektur.
Förhållandet mellan arkitekturer
Det är nödvändigt att förstå att baserat på definitionerna i tidigare artiklar är vilken tjänst som helst en komponent, men inte varje tjänst är en mikrotjänst.
Egenskaper hos Microservice Architecture
De viktigaste egenskaperna hos mikrotjänstarkitektur är:
- Organiserad kring affärskapacitet
- Produkter inte projekt
- Smarta ändpunkter och dumma rör
- Decentraliserad styrning
- Decentraliserad datahantering
- Infrastrukturautomation
- Design för misslyckande
- Arkitektur med evolutionär utveckling (Evolutionary Design)
Den första punkten kommer från tjänsteorienterad arkitektur eftersom mikrotjänster är ett specialfall av tjänster. Andra punkter förtjänar separat övervägande.
Organiserad kring affärskapacitet
Nu är det nödvändigt att komma ihåg Conways lag: organisationer som skapar system organiserar sin arkitektur och kopierar strukturen för interaktion inom dessa organisationer. Som ett exempel kan vi komma ihåg fallet med att skapa en kompilator: ett team på sju personer utvecklade en sju-pass kompilator och ett team på fem utvecklade en fem-pass kompilator.
Om vi pratar om monoliter och mikrotjänster, då om utvecklingen organiseras av funktionella avdelningar (backend, frontend, databasadministratörer), så får vi en klassisk monolit.
För att få mikrotjänster måste teamen organiseras efter affärskapacitet (beställningar, leveranser, katalogteam). Denna organisation kommer att tillåta team att fokusera på att bygga specifika delar av applikationen.
Produkter inte projekt
En projektansats där ett team överför den utvecklade funktionaliteten till andra team är helt olämpligt i fallet med en mikrotjänstarkitektur. Teamet måste stödja systemet under hela dess livscykel. Amazon, en av ledarna inom implementeringen av mikrotjänster, sa: "du bygger, du kör det." Produktupplägget gör att teamet känner av verksamhetens behov.
Smarta ändpunkter och dumma rör
SOA-arkitekturen ägnade stor uppmärksamhet åt kommunikationskanaler, särskilt Enterprise Service Bus. Vilket ofta leder till Erroneous Spaghetti Box, det vill säga monolitens komplexitet förvandlas till komplexiteten av kopplingar mellan tjänster. Mikrotjänstarkitektur använder endast enkla kommunikationsmetoder.
Decentraliserad styrning
Viktiga beslut om mikrotjänster bör fattas av de personer som faktiskt utvecklar mikrotjänsterna. Här betyder nyckelbeslut val
programmeringsspråk, implementeringsmetodik, kontrakt för offentliga gränssnitt, etc.
Decentraliserad datahantering
Standardmetoden, där applikationen bygger på en enda databas, kan inte ta hänsyn till specifikationerna för varje specifik tjänst. MSA innebär decentraliserad datahantering, inklusive användning av olika teknologier.
Infrastrukturautomation
MSA stöder kontinuerlig driftsättning och leveransprocesser. Detta kan endast uppnås genom att automatisera processer. Samtidigt ser det inte längre ut som något skrämmande att distribuera ett stort antal tjänster. Installationsprocessen borde bli tråkig. Den andra aspekten är relaterad till service management i en produktmiljö. Utan automatisering blir det omöjligt att hantera processer som körs i olika driftsmiljöer.
Design för misslyckande
Många MSA-tjänster är benägna att misslyckas. Samtidigt är felhantering i ett distribuerat system inte en trivial uppgift. Applikationsarkitekturen måste vara motståndskraftig mot sådana fel. Rebecca Parsons tycker att det är mycket viktigt att vi inte längre ens använder processkommunikation mellan tjänster, utan istället tar vi till HTTP för kommunikation, vilket inte är alls lika tillförlitligt.
Arkitektur med evolutionär utveckling (Evolutionary Design)
MSA-systemets arkitektur bör utvecklas evolutionärt. Det är tillrådligt att begränsa de nödvändiga ändringarna till gränserna för en enda tjänst. Inverkan på andra tjänster måste också beaktas. Det traditionella tillvägagångssättet är att försöka lösa detta problem med versionshantering, men MSA föreslår att man använder versionshantering i
som en sista utväg.
Slutsats
Efter allt ovanstående kan vi formulera vad mikrotjänster är. Mikrotjänstarkitektur är ett tillvägagångssätt för att utveckla en enda applikation som en samling av små tjänster, som var och en körs i sin egen process och interagerar genom lättviktsmekanismer, ofta ett HTTP-resurs-API. Dessa tjänster är byggda på affärsmöjligheter och kan distribueras oberoende med fullt utnyttjande
automatiserad distributionsmekanism. Det finns en miniminivå av centraliserad hantering av dessa tjänster, som kan skrivas på olika programmeringsspråk och använda olika datalagringstekniker.
Källa: will.com