Hei, habr. Ilmoittautuminen uudelle kurssivirralle on nyt auki OTUS:ssa . Kurssin alkamisen aattona haluan jakaa kanssasi alkuperäisen artikkelini.
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.
Vähän historiaa
Jos yrität kysyä kehittäjiltä: "Miksi tarvitsemme mikropalveluita?", saat monenlaisia vastauksia. Kuulet, että mikropalvelut parantavat skaalautuvuutta, helpottavat koodin ymmärtämistä, parantavat vikasietoisuutta, ja joskus kuulet, että niiden avulla voit "siivota koodisi". Katsotaanpa historiaa ymmärtääksemme mikropalvelujen syntymisen tarkoitusta.
Lyhyesti sanottuna mikropalvelut nykyisessä ymmärryksessämme syntyivät seuraavasti: vuonna 2011 James Lewis analysoi eri yritysten työtä kiinnitti huomion uuteen "mikrosovellusmalliin", joka optimoi SOA:n nopeuttamalla sen käyttöönottoa. palvelut. Hieman myöhemmin, vuonna 2012, arkkitehtuurin huippukokouksessa malli nimettiin uudelleen mikropalveluksi. Näin ollen mikropalveluiden käyttöönoton alkuperäinen tavoite oli parantaa pahamaineista aika markkinoille.
Mikropalvelut olivat hype-aaltoalueella vuonna 2015. Joidenkin tutkimusten mukaan yksikään konferenssi ei ollut täydellinen ilman mikropalveluiden aihetta käsittelevää raporttia. Lisäksi osa konferensseista oli omistettu yksinomaan mikropalveluille. Nykyään monet projektit alkavat käyttää tätä arkkitehtonista tyyliä, ja jos projekti sisältää tonnia vanhaa koodia, niin siirtyminen mikropalveluihin todennäköisesti on käynnissä.
Kaikesta edellä mainitusta huolimatta melko pieni joukko kehittäjiä voi silti määritellä "mikropalvelun" käsitteen. Mutta puhutaan tästä vähän myöhemmin...
monoliitti
Mikropalveluiden vastakohtana oleva arkkitehtoninen tyyli on monoliitti (tai all-in-one). Ei luultavasti ole järkevää kertoa mitä monoliitti on, joten listaan heti tämän arkkitehtonisen tyylin haitat, jotka aloittivat arkkitehtonisten tyylien jatkokehityksen: koko, liitettävyys, käyttöönotto, skaalautuvuus, luotettavuus ja jäykkyys. Alla ehdotan tarkastelemaan jokaista puutetta erikseen.
koko
Monoliitti on erittäin suuri. Ja se yleensä kommunikoi erittäin suuren tietokannan kanssa. Sovelluksesta tulee liian suuri yhden kehittäjän ymmärtämiseen. Vain ne, jotka ovat käyttäneet paljon aikaa tämän koodin parissa, voivat toimia hyvin monoliitin kanssa, kun taas aloittelijat viettävät paljon aikaa yrittääkseen selvittää monoliitin, eikä ole takeita siitä, että he selvittävät sen. Yleensä monoliitin kanssa työskennellessä on aina joku "ehdollinen" seniori, joka tuntee monoliitin enemmän tai vähemmän hyvin ja päihittää muiden uusien kehittäjien kädet puolentoista vuoden sisällä. Luonnollisesti tällainen ehdollinen seniori on yksi epäonnistumispiste, ja hänen lähtönsä voi johtaa monoliitin kuolemaan.
Yhteydet
Monoliitti on "iso mutapallo", jonka muutokset voivat johtaa arvaamattomiin seurauksiin. Jos teet muutoksia yhteen paikkaan, voit vahingoittaa monoliittia toisessa (sama "raaputit korvaasi, *@ putosi pois"). Tämä johtuu siitä, että monoliitin komponenteilla on hyvin monimutkaisia ja mikä tärkeintä, ei-ilmeisiä suhteita.
Käyttöönotto
Monoliitin käyttöönotto on sen komponenttien monimutkaisista suhteista johtuen pitkä prosessi, jolla on oma rituaalinsa. Tällaista rituaalia ei yleensä ole täysin standardoitu, ja se välitetään "suullisesti".
Skaalautuvuus
Monolith-moduuleilla voi olla ristiriitaisia resurssitarpeita, mikä edellyttää kompromissin tekemistä laitteiston suhteen. Kuvittele, että sinulla on monoliitti, joka koostuu palveluista A ja B. Palvelu A vaatii kovalevyn kokoa ja palvelu B RAM-muistia. Tässä tapauksessa joko koneen, johon monoliitti on asennettu, on tuettava molempien palvelujen vaatimuksia, tai sinun on manuaalisesti, keinotekoisesti poistettava toinen palveluista.
Toinen esimerkki (klassisempi): palvelu A on paljon suositumpi kuin palvelu B, joten haluat olla 100 palvelua A ja 10 palvelua B. Jälleen kaksi vaihtoehtoa: joko otamme käyttöön 100 täysimittaista monoliittia tai sitten joihinkin palvelut B on poistettava käytöstä manuaalisesti.
Luotettavuus
Koska kaikki palvelut sijaitsevat yhdessä, jos monoliitti putoaa, kaikki palvelut putoavat kerralla. Itse asiassa tämä ei välttämättä ole niin paha, ei ainakaan hajautetun järjestelmän osittaisia vikoja tapahdu, mutta toisaalta 0.001% käyttäjistä käyttämän toiminnallisuuden bugin vuoksi voit menettää kaikki käyttäjät järjestelmästäsi.
Inertia
Monoliitin koosta johtuen on vaikea siirtyä uusiin teknologioihin. Tämän seurauksena erittäin ehdollisen seniorin säilyttäminen näyttää olevan erillinen tehtävä. Projektin alussa valitusta teknologiapinosta voi muodostua tuotteen kehitystä estävä lohko.
Johtopäätös
Seuraavalla kerralla puhumme siitä, kuinka ihmiset ovat yrittäneet ratkaista nämä ongelmat siirtymällä komponentteihin ja SOA:han.
Lue lisää:
Lähde: will.com