Jeg ønsket å skrive en artikkel om temaet mikrotjenestearkitektur i lang tid, men to ting stoppet meg stadig - jo lenger jeg stupte inn i emnet, jo mer virket det for meg at det jeg vet er åpenbart, og hva jeg gjør' t vite må studeres og studeres. På den annen side tror jeg at det allerede er noe å diskutere blant et bredt publikum. Så alternative meninger er velkomne.
Conways lov og forholdet mellom virksomhet, organisasjon og informasjonssystem
Nok en gang vil jeg tillate meg å sitere:
"Enhver organisasjon som designer et system (i vid forstand) vil motta et design hvis struktur gjenskaper strukturen til teamene i den organisasjonen."
— Melvyn Conway, 1967
Etter min mening er denne loven mer sannsynlig å forholde seg til muligheten for å organisere en virksomhet, snarere enn direkte til informasjonssystemet. La meg forklare med et eksempel. La oss si at vi har en ganske stabil forretningsmulighet med en livssyklus av en slik lengde at det er fornuftig å organisere en bedrift (dette er ikke en skrivefeil, men jeg liker veldig godt dette begrepet som jeg stjal). Naturligvis, støttesystemet til denne virksomheten vil organisatorisk og prosessmessig tilsvare denne virksomheten .
Bedriftsorientering av informasjonssystemer
La meg forklare med et eksempel. La oss si at det er en forretningsmulighet til å organisere en virksomhet som selger pizza. I V1-versjonen (la oss kalle det forhåndsinformasjon) var selskapet en pizzeria, et kasseapparat og en leveringstjeneste. Denne versjonen var langvarig under forhold med lav miljøvariasjon. Så kom versjon 2 for å erstatte den - mer avansert og i stand til å bruke et informasjonssystem i kjernen for virksomhet med en monolitisk arkitektur. Og her er det etter min mening rett og slett en forferdelig urettferdighet i forhold til monolittene - angivelig monolittisk arkitektur samsvarer ikke med domenets forretningsmodell. Ja, hvis dette var slik, ville ikke systemet kunne fungere i det hele tatt – i strid med samme Conways lov og sunn fornuft. Nei, monolittisk arkitektur er helt konsistent med forretningsmodellen på dette stadiet av forretningsutviklingen – jeg mener selvfølgelig stadiet da systemet allerede er opprettet og satt i drift. Det er et helt fantastisk faktum at uansett arkitekturtilnærming vil både den tjenesteorienterte arkitekturversjon 3 og mikrotjenestearkitekturversjon N fungere like bra. Hva er fangsten?
Alt flyter, alt endres, eller er mikrotjenester et middel for å bekjempe kompleksitet?
Før vi fortsetter, la oss se på noen misoppfatninger om mikrotjenestearkitektur.
Tilhengere av å bruke en mikrotjenestetilnærming hevder ofte at å bryte en monolitt i mikrotjenester forenkler utviklingstilnærmingen ved å redusere kodebasen til individuelle tjenester. Etter min mening er denne uttalelsen fullstendig tull. Seriøst, den åpenbare interaksjonen innenfor en monolitt og homogen kode virker komplisert? Hvis dette virkelig var tilfelle, ville alle prosjekter i utgangspunktet vært bygget som mikrotjenester, mens praksis viser at migrering fra en monolitt til mikrotjenester er mye mer vanlig. Kompleksiteten forsvinner ikke, den beveger seg ganske enkelt fra individuelle moduler til grensesnitt (det være seg databusser, RPC, APIer og andre protokoller) og orkestreringssystemer. Og dette er vanskelig!
Fordelen med å bruke en heterogen stabel er også tvilsom. Jeg skal ikke argumentere for at dette også er mulig, men i realiteten forekommer det sjelden (Ser vi fremover – dette bør skje – men heller som en konsekvens snarere enn en fordel).
Produktets livssyklus og tjenestelivssyklus
Ta en ny titt på diagrammet ovenfor. Det er ingen tilfeldighet at jeg la merke til den avtagende livssyklusen til en egen versjon av en virksomhet - i moderne forhold er det akselerasjonen av overgangen til en virksomhet mellom versjoner som er avgjørende for suksessen. Suksessen til et produkt bestemmes av hastigheten på testing av forretningshypoteser i det. Og her, etter min mening, ligger den viktigste fordelen med mikrotjenestearkitektur. Men la oss gå i rekkefølge.
La oss gå videre til neste trinn i utviklingen av informasjonssystemer - til den tjenesteorienterte arkitekturen til SOA. Så på et bestemt tidspunkt har vi fremhevet i produktet vårt langvarige tjenester - lang levetid i den forstand at når man flytter mellom versjoner av et produkt, er det en sjanse for at livssyklusen til tjenesten vil være lengre enn livssyklusen til neste versjon av produktet. Det ville være logisk å ikke endre dem i det hele tatt - vi Det som betyr noe er hastigheten på overgangen til neste versjon. Men dessverre, vi er tvunget til å gjøre konstante endringer i tjenester - og her fungerer alt for oss, DevOps-praksis, containerisering og så videre - alt som kommer til tankene. Men disse er fortsatt ikke mikrotjenester!
Mikrotjenester som et middel for å bekjempe kompleksitet... konfigurasjonsadministrasjon
Og her kan vi endelig gå videre til den definerende rollen til mikrotjenester – dette er en tilnærming som forenkler produktkonfigurasjonsadministrasjonen. Mer detaljert beskriver funksjonen til hver mikrotjeneste nøyaktig forretningsfunksjonen inne i produktet i henhold til domenemodellen – og dette er ting som ikke lever i en kortvarig versjon, men i en langvarig forretningsmulighet. Og overgangen til neste versjon av produktet skjer bokstavelig talt ubemerket - du endrer/legger til én mikrotjeneste, og kanskje bare skjemaet for deres interaksjon, og plutselig befinner du deg i fremtiden, og etterlater gråtende konkurrenter som fortsetter å hoppe mellom versjoner av deres monolitter. Tenk deg nå at det er et ganske stort volum av mikrotjenester med forhåndsdefinerte grensesnitt og forretningsmuligheter. Og du kommer og bygger opp strukturen til produktet ditt fra ferdige mikrotjenester – ganske enkelt ved å tegne et diagram, for eksempel. Gratulerer - du har en plattform - og nå kan du tiltrekke deg bedrifter for deg selv. Drømmer Drømmer.
Funn
- Systemets arkitektur bør bestemmes av livssyklusen til komponentene. Hvis en komponent lever i en produktversjon, er det ingen vits i å øke kompleksiteten til systemet ved å bruke en mikroservicetilnærming.
- Mikrotjenestearkitektur bør være basert på domenemodellen - fordi forretningsmuligheten er det lengstlevende domenet
- Leveringspraksis (DevOps-praksis) og orkestrering er noe av det viktigste for mikrotjenestearkitektur – av den grunn at økningen i endringshastigheten av komponenter stiller økte krav til leveringshastighet og kvalitet.
Kilde: www.habr.com