Hallo, Habr. Hjoed gean ik troch mei in searje publikaasjes dy't ik spesjaal skreau foar it begjin fan in nije stream fan 'e kursus. .
Ynlieding
De kar fan arsjitektoanyske styl is ien fan 'e fûnemintele technyske besluten by it bouwen fan in ynformaasjesysteem. Yn dizze searje artikels stel ik foar om de populêrste arsjitektoanyske stilen te analysearjen foar bouwapplikaasjes en beantwurdzje de fraach wannear hokker arsjitektoanyske styl it meast de foarkar is. Yn it proses fan presintaasje sil ik besykje in logyske keatling te tekenjen dy't de ûntwikkeling fan arsjitektoanyske stilen ferklearret fan monoliten oant mikrotsjinsten.
De lêste kear hawwe wy it oer de ferskate soarten monoliten en it gebrûk fan komponinten om se te bouwen, sawol bouwkomponinten as ynsetkomponinten. Wy begripe service-rjochte arsjitektuer.
No sille wy úteinlik de wichtichste skaaimerken fan in mikroservice-arsjitektuer definiearje.
Relaasje fan arsjitektuer
It is needsaaklik om te begripen dat basearre op 'e definysjes jûn yn eardere artikels, elke tsjinst in komponint is, mar net elke tsjinst is in mikrotsjinst.
Skaaimerken fan Microservice Architecture
De wichtichste skaaimerken fan mikroservicearsjitektuer binne:
- Organisearre om Business Capabilities
- Produkten net Projekten
- Slimme einpunten en stomme pipen
- Desintralisearre bestjoer
- Desintralisearre gegevensbehear
- Ynfrastruktuer automatisearring
- Untwerp foar mislearring
- Arsjitektuer mei evolúsjonêre ûntwikkeling (Evolúsjonêr ûntwerp)
It 1e punt komt fan tsjinstrjochte arsjitektuer om't mikrotsjinsten in spesjaal gefal fan tsjinsten binne. Oare punten fertsjinje aparte beskôging.
Organisearre om Business Capabilities
No is it needsaaklik om de wet fan Conway te ûnthâlden: organisaasjes dy't systemen meitsje, organisearje har arsjitektuer, kopiearje de struktuer fan ynteraksje binnen dizze organisaasjes. As foarbyld kinne wy it gefal ûnthâlde fan it meitsjen fan in kompilator: in team fan sân minsken ûntwikkele in sân-pass kompilator, en in team fan fiif ûntwikkele in fiif-pass kompilator.
As wy it hawwe oer monoliten en mikrotsjinsten, dan as ûntwikkeling wurdt organisearre troch funksjonele ôfdielingen (backend, frontend, database administrators), dan krije wy in klassike monolith.
Om mikrotsjinsten te krijen, moatte teams wurde organisearre troch saaklike kapasiteiten (oarders, ferstjoeringen, katalogusteam). Dizze organisaasje sil teams tastean om te fokusjen op it bouwen fan spesifike dielen fan 'e applikaasje.
Produkten net Projekten
In projektoanpak wêryn in team de ûntwikkele funksjonaliteit oerdraacht oan oare teams is folslein net geskikt yn it gefal fan in mikroservicearsjitektuer. It team moat it systeem yn syn libbenssyklus stypje. Amazon, ien fan 'e lieders yn' e ymplemintaasje fan mikrotsjinsten, sei: "jo bouwe, jo rinne it." De produktoanpak lit it team de behoeften fan it bedriuw fiele.
Slimme einpunten en stomme pipen
SOA-arsjitektuer joech grutte oandacht oan kommunikaasjekanalen, benammen de Enterprise Service Bus. Wat faaks liedt ta Erroneous Spaghetti Box, dat is, de kompleksiteit fan 'e monolith feroaret yn' e kompleksiteit fan ferbiningen tusken tsjinsten. Microservice-arsjitektuer brûkt allinich ienfâldige kommunikaasjemetoaden.
Desintralisearre bestjoer
Wichtige besluten oer mikrotsjinsten moatte wurde makke troch de minsken dy't de mikrotsjinsten eins ûntwikkelje. Hjir betsjutte wichtige besluten karren
programmeartalen, ynsetmetodology, kontrakten foar iepenbiere ynterface, ensfh.
Desintralisearre gegevensbehear
De standert oanpak, wêryn de applikaasje fertrout op ien databank, kin net rekken hâlde mei de spesifiken fan elke spesifike tsjinst. MSA omfettet desintralisearre gegevensbehear, ynklusyf it brûken fan ferskate technologyen.
Ynfrastruktuer automatisearring
MSA stipet trochgeande ynset- en leveringsprosessen. Dit kin allinich berikt wurde troch automatisearjen fan prosessen. Tagelyk liket it ynsetten fan in grut tal tsjinsten net mear wat skrikliks mear. It ynsetproses moat saai wurde. It twadde aspekt is relatearre oan tsjinstbehear yn in produktomjouwing. Sûnder automatisearring wurdt it behearen fan prosessen dy't rinne yn ferskate bedriuwsomjouwings ûnmooglik.
Untwerp foar mislearring
Tal fan MSA-tsjinsten binne gefoelich foar mislearring. Tagelyk is flaterôfhanneling yn in ferspraat systeem gjin triviale taak. Applikaasje-arsjitektuer moat resistint wêze foar sokke mislearrings. Rebecca Parsons tinkt dat it heul wichtich is dat wy net iens mear yn-proses kommunikaasje brûke tusken tsjinsten; Ynstee dêrfan nimme wy ta HTTP foar kommunikaasje, wat lang net sa betrouber is.
Arsjitektuer mei evolúsjonêre ûntwikkeling (Evolúsjonêr ûntwerp)
De arsjitektuer fan it MSA-systeem moat evolúsjonêr ûntwikkelje. It is oan te rieden om de nedige wizigingen te beheinen ta de grinzen fan ien tsjinst. Ek moat rekken hâlden wurde mei de ynfloed op oare tsjinsten. De tradisjonele oanpak is om te besykjen dit probleem op te lossen mei ferzje, mar MSA suggerearret it brûken fan ferzje yn
as lêste ynstânsje.
konklúzje
Nei al it boppesteande kinne wy formulearje wat mikrotsjinsten binne. Microservice-arsjitektuer is in oanpak foar it ûntwikkeljen fan in inkele applikaasje as in kolleksje fan lytse tsjinsten, elk rint yn syn eigen proses en ynteraksje fia lichtgewicht meganismen, faaks in HTTP-boarne API. Dizze tsjinsten binne boud op saaklike mooglikheden en kinne ûnôfhinklik wurde ynset mei folslein
automatisearre ynsetmeganisme. D'r is in minimumnivo fan sintralisearre behear fan dizze tsjinsten, dy't kinne wurde skreaun yn ferskate programmeartalen en ferskate technologyen foar gegevensopslach brûke.
Boarne: www.habr.com