Hei, Habr. Tänään jatkan julkaisusarjaa, jonka kirjoitin nimenomaan uuden kurssin virran aloittamiseksi. .
Esittely
Arkkitehtonisen tyylin valinta on yksi keskeisistä teknisistä päätöksistä tietojärjestelmää rakennettaessa. Tässä artikkelisarjassa ehdotan analysoimaan suosituimpia arkkitehtonisia tyylejä rakennussovelluksissa ja vastaamaan kysymykseen, milloin mikä arkkitehtoninen tyyli on edullisin. Esityksen yhteydessä yritän piirtää loogisen ketjun, joka selittää arkkitehtonisten tyylien kehittymisen monoliiteista mikropalveluihin.
В Käsittelimme monoliittia ja tulimme siihen tulokseen, että monoliitilla on useita ongelmia: koko, liitettävyys, käyttöönotto, skaalautuvuus, luotettavuus ja jäykkyys.
Tällä kertaa ehdotan, että puhutaan mahdollisuuksista järjestää järjestelmä moduulien/kirjastojen (komponenttilähtöinen arkkitehtuuri) tai palveluiden (service-oriented arkkitehtuuri) joukkona.
Komponenttilähtöinen arkkitehtuuri
Komponenttikeskeinen arkkitehtuuri sisältää järjestelmän toteuttamisen komponenttien kokonaisuutena, jota voidaan käyttää sekä nykyisissä että tulevissa projekteissa. Kun järjestelmää jaetaan osiin, huomioidaan: niiden uudelleenkäytettävyys, korvattavuus, kontekstiriippumattomuus, laajennettavuus, kapselointi ja riippumattomuus.
Komponenttien oikealla käytöllä "ison likapallon" (iso koko + korkea kytkentä) ongelma ratkeaa ja komponentit itse voivat olla sekä kokoonpanoyksiköitä (moduulit, kirjastot) että käyttöönottoyksiköitä (palvelut). Käyttöönottoyksiköitä ei aina ole yhdistetty käynnissä olevaan prosessiin: esimerkiksi verkkosovellus ja tietokanta otetaan käyttöön yhdessä.
Useimmiten monoliitit kehitetään moduulien joukkona. Tämä lähestymistapa johtaa itsenäiseen kehitykseen, mutta itsenäisen skaalauksen ja käyttöönoton, vikasietoisuuden ja kokonaisteknologiasta riippumattomuuden ongelmat säilyvät. Tästä syystä moduuli on osittain itsenäinen komponentti.
Suurin ongelma tällaisessa monoliitissa on, että jako moduuleihin on puhtaasti looginen ja kehittäjät voivat rikkoa sitä helposti. Saattaa ilmestyä ydinmoduuli, joka muuttuu vähitellen kaatopaikaksi, moduulien välisten riippuvuuksien kaavio voi kasvaa ja niin edelleen. Tällaisten ongelmien välttämiseksi kehitystyön tulisi suorittaa joko erittäin kypsä tiimi tai "arkkitehdin" ohjauksessa, joka on mukana kokopäiväisessä kooditarkastuksessa ja lyö loogista rakennetta rikkovien kehittäjien kädet.
"Ihanteellinen" monoliitti on joukko loogisesti erotettuja moduuleja, joista jokainen tutkii omaa tietokantaansa.
Palvelukeskeinen arkkitehtuuri
Jos järjestelmän oletetaan organisoituvan palvelujoukon muodossa, puhutaan palvelukeskeisestä arkkitehtuurista. Sen periaatteet ovat käyttäjäkeskeinen sovellusten yhteentoimivuus, yrityspalveluiden uudelleenkäyttö, teknologiapinon riippumattomuus ja autonomia (itsenäinen kehitys, skaalautuvuus ja käyttöönotto).
Palvelukeskeinen arkkitehtuuri (SOA = service oriented architecture) ratkaisee kaikki monoliitin tunnistetut ongelmat: vain yhteen palveluun vaikuttaa muutos, ja hyvin määritelty API tukee komponenttien hyvää kapselointia.
Mutta kaikki ei ole niin sujuvaa: SOA luo uusia ongelmia. Etäpuhelut ovat kalliimpia kuin paikalliset, ja vastuiden uudelleenjako komponenttien välillä on tullut huomattavasti kalliimmaksi.
Muuten, itsenäisen käyttöönoton mahdollisuus on erittäin tärkeä palvelun ominaisuus. Jos palvelut on otettava käyttöön yhdessä tai lisäksi tietyssä järjestyksessä, ei järjestelmää voida pitää palvelukeskeisenä. Tässä tapauksessa he puhuvat hajautetusta monoliitista (jota pidetään anti-mallina paitsi SOA:n, myös mikropalveluarkkitehtuurin näkökulmasta).
Palvelulähtöistä arkkitehtuuria tukevat hyvin arkkitehtiyhteisö ja myyjät. Tämä edellyttää monien kurssien ja sertifikaattien, hyvin kehittyneiden mallien läsnäoloa. Jälkimmäiseen sisältyy esimerkiksi tunnettu yrityspalveluväylä (ESB = enterprise service bus). Samalla ESB on tavarantoimittajien matkatavara; sitä ei välttämättä tarvitse käyttää SOA:ssa.
Palvelukeskeisen arkkitehtuurin suosio oli huipussaan vuoden 2008 tienoilla, minkä jälkeen se alkoi laskea, mikä muuttui merkittävästi dramaattisemmiksi mikropalvelujen myötä (~2015).
Johtopäätös
Keskusteltuamme mahdollisuuksista järjestää tietojärjestelmiä palveluina ja moduuleina ehdotan, että siirrytään vihdoin mikropalveluarkkitehtuurin periaatteisiin ja kiinnitetään seuraavassa osassa erityistä huomiota mikropalveluarkkitehtuurin ja palvelukeskeisen arkkitehtuurin eroon.
Lähde: will.com