Hallo, Habr. Vandag gaan ek voort met 'n reeks publikasies wat ek spesifiek geskryf het vir die begin van 'n nuwe stroom van die kursus. .
Inleiding
Die keuse van argitektoniese styl is een van die fundamentele tegniese besluite wanneer 'n inligtingstelsel gebou word. In hierdie reeks artikels stel ek voor om die gewildste argitektoniese style vir boutoepassings te ontleed en die vraag te beantwoord wanneer watter argitektoniese styl die meeste verkieslik is. In die proses van aanbieding sal ek probeer om 'n logiese ketting te teken wat die ontwikkeling van argitektoniese style van monoliete tot mikrodienste verduidelik.
Verlede keer het ons gepraat oor die verskillende tipes monoliete en die gebruik van komponente om hulle te bou, beide boukomponente en ontplooiingskomponente. Ons verstaan diensgerigte argitektuur.
Nou sal ons uiteindelik die hoofkenmerke van 'n mikrodiensargitektuur definieer.
Verwantskap van argitekture
Dit is nodig om te verstaan dat, gebaseer op die definisies wat in vorige artikels gegee is, enige diens 'n komponent is, maar nie elke diens is 'n mikrodiens nie.
Eienskappe van mikrodiensargitektuur
Die hoofkenmerke van mikrodiensargitektuur is:
- Georganiseer rondom besigheidsvermoëns
- Produkte nie projekte nie
- Slim eindpunte en stom pype
- Gedesentraliseerde Bestuur
- Gedesentraliseerde databestuur
- Infrastruktuur-outomatisering
- Ontwerp vir mislukking
- Argitektuur met evolusionêre ontwikkeling (Evolusionêre Ontwerp)
Die 1ste punt kom van diensgeoriënteerde argitektuur omdat mikrodienste 'n spesiale geval van dienste is. Ander punte verdien afsonderlike oorweging.
Georganiseer rondom besigheidsvermoëns
Nou is dit nodig om Conway se wet te onthou: organisasies wat stelsels skep, organiseer sy argitektuur en kopieer die struktuur van interaksie binne hierdie organisasies. As 'n voorbeeld kan ons die geval van die skep van 'n samesteller onthou: 'n span van sewe mense het 'n sewegangsamesteller ontwikkel, en 'n span van vyf het 'n vyfgangsamesteller ontwikkel.
As ons praat van monoliete en mikrodienste, dan as ontwikkeling deur funksionele departemente (backend, frontend, databasisadministrateurs) georganiseer word, kry ons 'n klassieke monoliet.
Om mikrodienste te bekom, moet spanne volgens besigheidsvermoë (bestellings, verskepings, katalogusspan) georganiseer word. Hierdie organisasie sal spanne toelaat om te fokus op die bou van spesifieke dele van die toepassing.
Produkte nie projekte nie
'n Projekbenadering waarin 'n span die ontwikkelde funksionaliteit na ander spanne oordra, is heeltemal ongeskik in die geval van 'n mikrodiensargitektuur. Die span moet die stelsel dwarsdeur sy lewensiklus ondersteun. Amazon, een van die leiers in die implementering van mikrodienste, het gesê: "jy bou, jy bestuur dit." Die produkbenadering laat die span toe om die behoeftes van die besigheid te voel.
Slim eindpunte en stom pype
SOA-argitektuur het groot aandag aan kommunikasiekanale gegee, veral die Enterprise Service Bus. Wat dikwels lei tot Foutiewe Spaghetti Box, dit wil sê, die kompleksiteit van die monoliet verander in die kompleksiteit van verbindings tussen dienste. Mikrodiensargitektuur gebruik slegs eenvoudige kommunikasiemetodes.
Gedesentraliseerde Bestuur
Sleutelbesluite oor mikrodienste moet geneem word deur die mense wat werklik die mikrodienste ontwikkel. Hier beteken sleutelbesluite keuses
programmeertale, implementeringsmetodologie, openbare koppelvlakkontrakte, ens.
Gedesentraliseerde databestuur
Die standaardbenadering, waarin die toepassing op 'n enkele databasis staatmaak, kan nie die besonderhede van elke spesifieke diens in ag neem nie. MSA behels gedesentraliseerde databestuur, insluitend die gebruik van verskeie tegnologieë.
Infrastruktuur-outomatisering
MSA ondersteun deurlopende ontplooiing en afleweringsprosesse. Dit kan slegs bereik word deur prosesse te outomatiseer. Terselfdertyd lyk die implementering van 'n groot aantal dienste nie meer na iets skrikwekkend nie. Die ontplooiingsproses behoort vervelig te word. Die tweede aspek hou verband met diensbestuur in 'n produkomgewing. Sonder outomatisering word die bestuur van prosesse wat in verskillende bedryfsomgewings uitgevoer word, onmoontlik.
Ontwerp vir mislukking
Talle MSA-dienste is geneig tot mislukking. Terselfdertyd is fouthantering in 'n verspreide stelsel nie 'n onbenullige taak nie. Toepassingsargitektuur moet bestand wees teen sulke mislukkings. Rebecca Parsons dink dit is baie belangrik dat ons nie eens meer in-proses kommunikasie tussen dienste gebruik nie, maar eerder gebruik maak van HTTP vir kommunikasie, wat nie naastenby so betroubaar is nie.
Argitektuur met evolusionêre ontwikkeling (Evolusionêre Ontwerp)
Die argitektuur van die MSA-stelsel behoort evolusionêr te ontwikkel. Dit is raadsaam om die nodige veranderinge tot die grense van 'n enkele diens te beperk. Die impak op ander dienste moet ook in ag geneem word. Die tradisionele benadering is om hierdie probleem met weergawebeheer te probeer oplos, maar MSA stel voor om weergawebeheer in te gebruik
as 'n laaste uitweg.
Gevolgtrekking
Na al die bogenoemde kan ons formuleer wat mikrodienste is. Mikrodiens-argitektuur is 'n benadering tot die ontwikkeling van 'n enkele toepassing as 'n versameling van klein dienste, wat elkeen in sy eie proses loop en deur liggewigmeganismes in wisselwerking tree, dikwels 'n HTTP-hulpbron-API. Hierdie dienste is gebou op besigheidsvermoëns en kan onafhanklik ontplooi word deur ten volle te gebruik
outomatiese ontplooiingsmeganisme. Daar is 'n minimum vlak van gesentraliseerde bestuur van hierdie dienste, wat in verskillende programmeertale geskryf kan word en verskillende databergingstegnologieë gebruik.
Bron: will.com