Jeg ville længe skrive en artikel om emnet mikroservicearkitektur, men to ting blev ved med at stoppe mig - jo længere jeg kastede mig ind i emnet, jo mere forekom det mig, at det jeg ved er indlysende, og hvad jeg gør' t vide skal studeres og studeres. På den anden side synes jeg, at der allerede er noget at diskutere blandt et bredt publikum. Så alternative meninger er velkomne.
Conways lov og forholdet mellem forretning, organisation og informationssystem
Endnu en gang vil jeg tillade mig at citere:
"Enhver organisation, der designer et system (i bred forstand), vil modtage et design, hvis struktur replikerer strukturen af teams i den organisation."
— Melvyn Conway, 1967
Efter min mening er denne lov mere tilbøjelig til at relatere til gennemførligheden af at organisere en virksomhed, snarere end direkte til informationssystemet. Lad mig forklare med et eksempel. Lad os sige, at vi har en ret stabil forretningsmulighed med en livscyklus af en sådan længde, at det giver mening at organisere en virksomhed (dette er ikke en tastefejl, men jeg kan virkelig godt lide dette udtryk, som jeg stjal). Naturligvis understøtter denne virksomheds system. vil organisatorisk og procesmæssigt svare til denne forretning .
Forretningsorientering af informationssystemer
Lad mig forklare med et eksempel. Lad os sige, at der er en forretningsmulighed for at organisere en virksomhed, der sælger pizza. I V1-versionen (lad os kalde det pre-information) var virksomheden et pizzeria, et kasseapparat og en leveringstjeneste. Denne version var langlivet under forhold med lav miljøvariabilitet. Så kom version 2 til at erstatte det - mere avanceret og i stand til at bruge et informationssystem i sin kerne til forretning med en monolitisk arkitektur. Og her er der efter min mening simpelthen en frygtelig uretfærdighed i forhold til monolitterne - angiveligt monolitisk arkitektur svarer ikke til domænets forretningsmodel. Ja, hvis det var sådan, ville systemet slet ikke kunne fungere – i modstrid med samme Conways lov og sunde fornuft. Nej, monolitisk arkitektur er fuldt ud i overensstemmelse med forretningsmodellen på dette stadie af forretningsudviklingen – jeg mener selvfølgelig stadiet, hvor systemet allerede er skabt og sat i drift. Det er et helt vidunderligt faktum, at uanset den arkitektoniske tilgang vil både den serviceorienterede arkitektur version 3 og mikroservices arkitektur version N fungere lige godt. Hvad er fangsten?
Alt flyder, alt ændrer sig, eller er mikrotjenester et middel til at bekæmpe kompleksitet?
Før vi fortsætter, lad os se på nogle misforståelser om mikroservicearkitektur.
Tilhængere af at bruge en mikroservicetilgang hævder ofte, at at bryde en monolit i mikrotjenester forenkler udviklingstilgangen ved at reducere kodebasen for individuelle tjenester. Efter min mening er denne udtalelse fuldstændig nonsens. Seriøst, den åbenlyse interaktion inden for en monolit og homogen kode virker kompliceret? Hvis dette virkelig var tilfældet, ville alle projekter i første omgang være bygget som mikrotjenester, mens praksis viser, at migrering fra en monolit til mikrotjenester er meget mere almindelig. Kompleksiteten forsvinder ikke; den bevæger sig blot fra individuelle moduler til grænseflader (det være sig databusser, RPC, API'er og andre protokoller) og orkestreringssystemer. Og det er svært!
Fordelen ved at bruge en heterogen stak er også tvivlsom. Jeg vil ikke argumentere for, at dette også er muligt, men i virkeligheden forekommer det sjældent (Ser vi fremad - det burde ske - men snarere som en konsekvens end en fordel).
Produktets livscyklus og servicelivscyklus
Se igen på diagrammet ovenfor. Det er ikke tilfældigt, at jeg bemærkede den faldende livscyklus for en separat version af en virksomhed - under moderne forhold er det accelerationen af en virksomheds overgang mellem versioner, der er afgørende for dens succes. Et produkts succes bestemmes af hastigheden af test af forretningshypoteser i det. Og her ligger efter min mening den vigtigste fordel ved mikroservicearkitektur. Men lad os gå i rækkefølge.
Lad os gå videre til næste trin i udviklingen af informationssystemer - til SOAs serviceorienterede arkitektur. Så på et bestemt tidspunkt fremhævede vi i vores produkt langvarige tjenester - lang levetid i den forstand, at når man flytter mellem versioner af et produkt, er der en chance for, at tjenestens livscyklus bliver længere end livscyklussen for den næste version af produktet. Det ville være logisk slet ikke at ændre dem – vi Det afgørende er hastigheden af overgangen til den næste version. Men ak, vi er tvunget til at foretage konstante ændringer af tjenester - og her fungerer alt for os, DevOps-praksis, containerisering og så videre - alt, hvad der falder dig ind. Men disse er stadig ikke mikrotjenester!
Mikrotjenester som et middel til at bekæmpe kompleksitet... konfigurationsstyring
Og her kan vi endelig gå videre til mikroservices definerende rolle - dette er en tilgang, der forenkler produktkonfigurationsstyring. Mere detaljeret beskriver hver mikroservices funktion præcis forretningsfunktionen inde i produktet i henhold til domænemodellen – og det er ting, der ikke lever i en kortvarig version, men i en langvarig forretningsmulighed. Og overgangen til den næste version af produktet sker bogstaveligt talt ubemærket - du ændrer/tilføjer én mikroservice, og måske bare skemaet for deres interaktion, og pludselig befinder du dig i fremtiden og efterlader grædende konkurrenter, der fortsætter med at hoppe mellem versioner af deres monolitter. Forestil dig nu, at der er en ret stor mængde mikrotjenester med foruddefinerede grænseflader og forretningsmuligheder. Og du kommer og bygger dit produkts struktur af færdige mikrotjenester – blot ved at tegne et diagram, for eksempel. Tillykke - du har en platform - og nu kan du tiltrække forretning til dig selv. Drømme Drømme.
Fund
- Systemets arkitektur bør bestemmes af dets komponenters livscyklus. Hvis en komponent findes i en produktversion, nytter det ikke noget at øge systemets kompleksitet ved at bruge en mikroservicetilgang.
- Mikroservicearkitektur bør være baseret på domænemodellen - fordi forretningsmuligheden er det længstlevende domæne
- Leveringspraksis (DevOps-praksis) og orkestrering er en af de vigtigste for mikroservicearkitektur - af den grund, at stigningen i ændringshastigheden af komponenter stiller øgede krav til leveringshastigheden og -kvaliteten
Kilde: www.habr.com