Ik wilde al heel lang een artikel schrijven over het onderwerp microservice-architectuur, maar twee dingen hielden me tegen: hoe verder ik me in het onderwerp verdiepte, hoe meer het mij leek dat wat ik weet duidelijk is, en wat ik niet weet. Ik weet dat het bestudeerd en bestudeerd moet worden. Aan de andere kant denk ik dat er al iets te bespreken valt onder een breed publiek. Alternatieve meningen zijn dus welkom.
Conway's Law en de relatie tussen bedrijf, organisatie en informatiesysteem
Ik sta mezelf nogmaals toe te citeren:
“Elke organisatie die een systeem ontwerpt (in brede zin) krijgt een ontwerp waarvan de structuur de structuur van de teams in die organisatie repliceert.”
—Melvyn Conway, 1967
Naar mijn mening heeft deze wet eerder betrekking op de haalbaarheid van het organiseren van een bedrijf dan rechtstreeks op het informatiesysteem. Laat het me uitleggen met een voorbeeld. Laten we zeggen dat we een redelijk stabiele zakelijke kans hebben met een levenscyclus die zo lang duurt dat het zinvol is om een onderneming te organiseren (dit is geen typefout, maar ik vind deze term die ik heb gestolen erg leuk). zal organisatorisch en procesmatig aansluiten bij deze business.
Bedrijfsoriëntatie van informatiesystemen
Laat het me uitleggen met een voorbeeld. Laten we zeggen dat er een zakelijke mogelijkheid is om een bedrijf te organiseren dat pizza verkoopt. In de V1-versie (laten we het pre-informatie noemen) was het bedrijf een pizzeria, een kassa en een bezorgservice. Deze versie had een lange levensduur in omstandigheden met een lage omgevingsvariabiliteit. Toen kwam versie 2 ter vervanging - geavanceerder en in staat om een informatiesysteem als kern voor het bedrijfsleven te gebruiken met een monolithische architectuur. En hier is er naar mijn mening gewoon een vreselijke onrechtvaardigheid met betrekking tot de monolieten - zogenaamd monolithische architectuur komt niet overeen met het domeinbedrijfsmodel. Ja, als dit zo zou zijn, zou het systeem helemaal niet kunnen werken – in tegenspraak met dezelfde wet van Conway en het gezonde verstand. Nee, monolithische architectuur is volledig consistent met het bedrijfsmodel in deze fase van bedrijfsontwikkeling - ik bedoel natuurlijk de fase waarin het systeem al is gecreëerd en in gebruik is genomen. Het is een absoluut wonderbaarlijk feit dat, ongeacht de architecturale benadering, zowel de servicegeoriënteerde architectuurversie 3 als de microservicesarchitectuurversie N even goed zullen werken. Wat is het addertje onder het gras?
Alles stroomt, alles verandert, of zijn microservices een middel om complexiteit te bestrijden?
Laten we, voordat we verder gaan, eens kijken naar enkele misvattingen over de microservice-architectuur.
Voorstanders van het gebruik van een microservicebenadering beweren vaak dat het opsplitsen van een monoliet in microservices de ontwikkelingsaanpak vereenvoudigt door de codebasis van individuele services te verkleinen. Naar mijn mening is deze stelling complete onzin. Serieus, de voor de hand liggende interactie binnen een monoliet en homogene code lijkt ingewikkeld? Als dit werkelijk het geval zou zijn, zouden alle projecten in eerste instantie als microservices worden gebouwd, terwijl de praktijk leert dat migratie van een monoliet naar microservices veel vaker voorkomt. Complexiteit verdwijnt niet; het gaat eenvoudigweg van individuele modules naar interfaces (of het nu databussen, RPC, API's en andere protocollen zijn) en orkestrerende systemen. En dit is moeilijk!
Het voordeel van het gebruik van een heterogene stapel is ook twijfelachtig. Ik zal niet beweren dat dit ook mogelijk is, maar in werkelijkheid komt het zelden voor (vooruitkijkend zou dit moeten gebeuren, maar eerder als gevolg dan als voordeel).
Productlevenscyclus en servicelevenscyclus
Kijk nog eens naar het bovenstaande diagram. Het is geen toeval dat ik de afnemende levenscyclus van een afzonderlijke versie van een bedrijf opmerkte - in moderne omstandigheden is het de versnelling van de overgang van een bedrijf tussen versies die bepalend is voor het succes ervan. Het succes van een product wordt bepaald door de snelheid waarmee bedrijfshypothesen erin worden getest. En hier ligt naar mijn mening het belangrijkste voordeel van microservice-architectuur. Maar laten we in volgorde gaan.
Laten we verder gaan naar de volgende fase in de evolutie van informatiesystemen: naar de servicegerichte architectuur van SOA. Dus op een bepaald punt hebben we dit in ons product benadrukt diensten met een lange levensduur - langlevend in de zin dat bij het wisselen tussen versies van een product de kans bestaat dat de levenscyclus van de dienst langer zal zijn dan de levenscyclus van de volgende versie van het product. Het zou logisch zijn om ze helemaal niet te veranderen - wij Waar het om gaat is de snelheid van de overgang naar de volgende versie. Maar helaas worden we gedwongen om voortdurend wijzigingen aan te brengen in de services - en hier werkt alles voor ons, DevOps-praktijken, containerisatie, enzovoort - alles wat in ons opkomt. Maar dit zijn nog steeds geen microservices!
Microservices als middel om complexiteit tegen te gaan... configuratiemanagement
En hier kunnen we eindelijk overgaan tot de bepalende rol van microservices: dit is een aanpak die het beheer van de productconfiguratie vereenvoudigt. Meer gedetailleerd beschrijft de functie van elke microservice precies de bedrijfsfunctie binnen het product volgens het domeinmodel - en dit zijn dingen die niet in een kortstondige versie leven, maar in een langlevende zakelijke kans. En de overgang naar de volgende versie van het product gebeurt letterlijk onopgemerkt: je verandert/voegt één microservice toe, en misschien alleen het schema van hun interactie, en plotseling bevind je je in de toekomst, terwijl je huilende concurrenten achterlaat die blijven springen tussen versies van hun monolieten. Stel je nu voor dat er een vrij groot volume aan microservices is met vooraf gedefinieerde interfaces en zakelijke mogelijkheden. En jij komt de structuur van je product opbouwen vanuit kant-en-klare microservices – simpelweg door bijvoorbeeld een diagram te tekenen. Gefeliciteerd - u heeft een platform - en nu kunt u zelf zaken aantrekken. Dromen Dromen.
Bevindingen
- De architectuur van het systeem moet worden bepaald door de levenscyclus van de componenten. Als een component binnen een productversie leeft, heeft het geen zin om de complexiteit van het systeem te vergroten door gebruik te maken van een microservice-aanpak.
- Microservice-architectuur moet gebaseerd zijn op het domeinmodel, omdat de zakelijke kansen het langstlevende domein zijn
- Leveringspraktijken (DevOps-praktijken) en orkestratie zijn een van de belangrijkste voor microservice-architectuur - om de reden dat de toename van de snelheid waarmee componenten veranderen hogere eisen stelt aan de snelheid en kwaliteit van levering
Bron: www.habr.com