Sveiki, Habr. Šiandien tęsiu publikacijų seriją, kurią parašiau specialiai naujo kurso srauto pradžiai. .
įvedimas
Architektūrinio stiliaus pasirinkimas yra vienas esminių techninių sprendimų kuriant informacinę sistemą. Šiame straipsnių cikle siūlau išanalizuoti populiariausius pastatų architektūros stilius ir atsakyti į klausimą, kada kuris architektūros stilius yra tinkamiausias. Pristatymo metu pabandysiu nubrėžti loginę grandinę, paaiškinančią architektūros stilių raidą nuo monolitų iki mikropaslaugų.
В nagrinėjome monolitą ir padarėme išvadą, kad monolitas turi daug problemų: dydžio, jungiamumo, diegimo, mastelio, patikimumo ir standumo.
Šį kartą siūlau pakalbėti apie galimybes organizuoti sistemą kaip modulių/bibliotekų rinkinį (komponentinė architektūra) arba paslaugas (service-oriented architektūra).
Į komponentus orientuota architektūra
Į komponentus orientuota architektūra apima sistemos vykdymą kaip komponentų rinkinį, kuris gali būti naudojamas tiek dabartiniuose, tiek būsimuose projektuose. Išskaidant sistemą į komponentus, atsižvelgiama į: jų pakartotinį naudojimą, pakeičiamumą, nepriklausomumą nuo konteksto, išplečiamumą, įkapsuliavimą ir nepriklausomumą.
Tinkamai naudojant komponentus, išspręsta „didžiojo purvo kamuolio“ (didelis dydis + aukšta mova) problema, o patys komponentai gali reprezentuoti tiek surinkimo blokus (modulius, bibliotekas), tiek diegimo blokus (paslaugas). Diegimo vienetai ne visada susieti su vykdomu procesu: pavyzdžiui, žiniatinklio programa ir duomenų bazė diegiamos kartu.
Dažniausiai monolitai kuriami kaip modulių rinkinys. Šis metodas veda į nepriklausomą plėtrą, tačiau nepriklausomo mastelio keitimo ir diegimo, atsparumo gedimams ir nepriklausomumo nuo bendros technologijų krūvos problemos išlieka. Štai kodėl modulis yra iš dalies nepriklausomas komponentas.
Didžiausia tokio monolito problema yra ta, kad skirstymas į modulius yra grynai logiškas ir gali būti lengvai pažeistas kūrėjų. Gali atsirasti pagrindinis modulis, kuris palaipsniui virsta šiukšlynu, gali augti modulių priklausomybių grafikas ir pan. Norint išvengti tokių problemų, kūrimą turėtų atlikti arba labai subrendusi komanda, arba vadovaujant „architektui“, kuris visą darbo dieną atlieka kodo peržiūrą ir muša rankas kūrėjams, pažeidžiantiems loginę struktūrą.
„Idealus“ monolitas yra logiškai atskirtų modulių rinkinys, kurių kiekvienas žiūri į savo duomenų bazę.
Į paslaugas orientuota architektūra
Jei sistema turėtų būti organizuota paslaugų rinkinio forma, tai mes kalbame apie į paslaugas orientuotą architektūrą. Jos principai yra į vartotoją orientuotas programų sąveikumas, pakartotinis verslo paslaugų naudojimas, technologijų paketo nepriklausomumas ir autonomija (nepriklausoma plėtra, mastelio keitimas ir diegimas).
Į paslaugas orientuota architektūra (SOA = į paslaugą orientuota architektūra) išsprendžia visas nustatytas monolito problemas: įvykus pakeitimui paveikiama tik viena paslauga, o gerai apibrėžta API palaiko gerą komponentų inkapsuliavimą.
Tačiau ne viskas taip sklandu: SOA sukuria naujų problemų. Nuotoliniai skambučiai yra brangesni nei vietiniai, o atsakomybės perskirstymas tarp komponentų tapo žymiai brangesnis.
Beje, savarankiško diegimo galimybė yra labai svarbi paslaugos savybė. Jei paslaugos turi būti diegiamos kartu arba, be to, tam tikra seka, tai sistema negali būti laikoma orientuota į paslaugas. Šiuo atveju jie kalba apie paskirstytą monolitą (laikomą antipatternu ne tik SOA, bet ir mikro paslaugų architektūros požiūriu).
Į paslaugas orientuotą architektūrą gerai palaiko architektų bendruomenė ir pardavėjai. Tai reiškia, kad yra daug kursų ir sertifikatų, gerai išvystyti modeliai. Pastaroji apima, pavyzdžiui, gerai žinomą įmonės paslaugų magistralę (ESB = enterprise service bus). Tuo pačiu metu ESB yra pardavėjų bagažas; jis nebūtinai turi būti naudojamas SOA.
Į paslaugas orientuotos architektūros populiarumas pasiekė aukščiausią tašką apie 2008 m., po to pradėjo mažėti, o tai tapo žymiai dramatiškesni po mikropaslaugų atsiradimo (~2015 m.).
išvada
Aptarus informacinių sistemų organizavimo paslaugų ir modulių pavidalu galimybes, siūlau pagaliau pereiti prie mikropaslaugų architektūros principų ir kitoje dalyje ypatingą dėmesį skirti mikropaslaugų architektūros ir į paslaugas orientuotos architektūros skirtumui.
Šaltinis: www.habr.com