Hej, Habr. I dag fortsätter jag serien av inlägg som jag skrivit speciellt för starten av den nya kursomgången. .
Introduktion
Valet av arkitekturtyp är en av de grundläggande tekniska besluten vid uppbyggnaden av ett informationssystem. I denna artikelserie föreslår jag att vi går igenom de mest populära arkitekturstilarna för applikationsutveckling och besvarar frågan om när vilken arkitekturtyp är mest föredragen. Under redogörelsen kommer jag att försöka dra en logisk kedja som förklarar utvecklingen av arkitekturstilar från monoliter till mikrotjänster.
Förra gången pratade vi om olika typer av monoliter och hur man använder komponenter för att bygga dem, både byggkomponenter och distribueringskomponenter. Vi förstod oss på serviceorienterad arkitektur.
Nu ska vi äntligen definiera de grundläggande egenskaperna hos mikrotjänstarkitektur.
Relationen mellan arkitekturer
Det är viktigt att förstå att baserat på uppgifterna i de tidigare artiklarna är varje tjänst en komponent, men inte varje tjänst är en mikrotjänst.
Egenskaper hos mikrotjänstarkitektur
De huvudsakliga egenskaperna hos mikrotjänstarkitektur är:
- Organiserad kring affärsmöjligheter (Organized around Business Capabilities)
- Produkter, inte projekt (Products not Projects)
- Smart ingångspunkter och dumma kanaler (Smart endpoints and dumb pipes)
- Decentraliserad styrning (Decentralized Governance)
- Decentraliserad datastyrning (Decentralized Data Management)
- Automatisering av infrastruktur (Infrastructure Automation)
- Design för fel (Design for failure)
- Arkitektur med evolutiv utveckling (Evolutionary Design)
Den första punkten kommer från serviceorienterad arkitektur, eftersom mikrotjänster är ett speciellt fall av tjänster. De andra punkterna förtjänar att behandlas separat.
Organiserad kring affärsmöjligheter (Organized around Business Capabilities)
Det är nu viktigt att påminna sig om Conway's lag: organisationer som skapar system organiserar dess arkitektur i enlighet med strukturen för interaktionen inom dessa organisationer. Ett exempel är skapandet av en kompilator: ett team av sju personer utvecklade en sju-pass-compiler, och ett team av fem personer skapade en fem-pass-compiler.
När vi pratar om monoliter och mikrotjänster, om utvecklingen organiseras efter funktionella avdelningar (backend, frontend, databasadministratörer), så får vi en klassisk monolit.
För att få mikrotjänster måste teamen organiseras kring affärsmöjligheter (beställningsteam, fraktteam, katalogteam). En sådan organisation ger teamen möjlighet att fokusera på att skapa specifika delar av applikationen.
Produkter, inte projekt (Products not Projects)
Den projektmetod där teamet överlämnar den utvecklade funktionaliteten till andra team vid användning av mikrotjänstarkitektur är helt olämplig. Teamet måste stödja systemet under hela dess livscykel. Amazon, en av pionjärerna inom mikrotjänster, har uttalat: "du bygger produkten, och du kör den" ("you build, you run it"). Produktmetoden gör att teamet kan känna av affärens behov.
Smart ingångspunkter och dumma kanaler (Smart endpoints and dumb pipes)
SOA-arkitekturen lade stor vikt vid kommunikationskanaler, särskilt Enterprise Service Bus (tjänstebuss för företag). Detta leder ofta till Erroneous Spaghetti Box, vilket innebär att monolittens komplexitet övergår till komplexitet i relationerna mellan tjänster. Mikrotjänstarkitektur använder endast enkla interaktionssätt.
Decentraliserad styrning (Decentralized Governance)
Nyckellösningar för mikrotjänster bör fattas av de personer som faktiskt utvecklar mikrotjänster. Här avses med nyckellösningar valet
av programmeringsspråk, distribueringsmetoder, kontrakt för offentliga gränssnitt osv.
Decentraliserad datastyrning (Decentralized Data Management)
Den standardmetod där en applikation är beroende av en enda databas kan inte ta hänsyn till de specifika behoven hos varje tjänst. MSA innebär ett decentraliserat datastyrning, inklusive användning av olika teknologier.
Automatisering av infrastruktur (Infrastructure Automation)
MSA stödjer processer för kontinuerlig distribution och leverans. Detta är bara möjligt genom automatisering av processerna. Samtidigt verkar distribution av ett stort antal tjänster inte längre skrämmande. Distribueringsprocessen bör bli tråkig. Den andra aspekten rör hanteringen av tjänster i en produktionsmiljö. Utan automatisering blir det omöjligt att hantera processer som körs i olika driftsmiljöer.
Design för fel (Design for failure)
Många tjänster inom MSA är benägna att misslyckas. Återkoppling av fel i ett distribuerat system är en ganska komplex uppgift. Applikationsarkitekturen måste vara motståndskraftig mot sådana fel. Rebecca Parsons anser att det är oerhört viktigt att vi inte längre använder ens intraprocess-interaktion mellan tjänster, utan istället använder vi HTTP för kommunikation, vilket sällan är lika tillförlitligt.
Arkitektur med evolutiv utveckling (Evolutionary Design)
MSA-systemens arkitektur måste utvecklas evolutionärt. Det är önskvärt att begränsa nödvändiga ändringar till gränserna för en tjänst. Det är också nödvändigt att ta hänsyn till påverkan på andra tjänster. Den traditionella metoden är att försöka lösa detta problem genom versionshantering, men MSA föreslår att använda versionshantering i
som en sista utväg.
Slutsats
Efter allt som har sagts kan vi formulera vad mikrotjänster är. Mikrotjänstarkitektur är en metod för att utveckla enskilda applikationer som ett set av små tjänster, var och en som fungerar i sin egen process och interagerar via lätta mekanismer, ofta genom HTTP-resursens API-gränssnitt. Dessa tjänster är uppbyggda kring affärsmöjligheter och kan distribueras oberoende med hjälp av en helt
automatiserad distributionsmekanism. Det finns en minimal nivå av centraliserad styrning av dessa tjänster, som kan vara skrivna i olika programmeringsspråk och använda olika datalagringsteknologier.
Källa: habr.com
