Pozdravljeni, habr. Pri OTUS-u so trenutno odprte prijave za nov tečaj . Na predvečer začetka tečaja želim z vami deliti svoj izvirni članek.
Predstavitev
Izbira arhitekturnega stila je ena temeljnih tehničnih odločitev pri izgradnji informacijskega sistema. V tej seriji člankov predlagam, da analiziram najbolj priljubljene arhitekturne sloge za gradbene aplikacije in odgovorim na vprašanje, kdaj je kateri arhitekturni slog najprimernejši. V procesu predstavitve bom poskušal narisati logično verigo, ki pojasnjuje razvoj arhitekturnih slogov od monolitov do mikrostoritev.
Malo zgodovine
Če poskušate vprašati razvijalce: "Zakaj potrebujemo mikrostoritve?", boste dobili različne odgovore. Slišali boste, da mikrostoritve izboljšajo razširljivost, olajšajo razumevanje kode, izboljšajo toleranco napak in včasih boste slišali, da vam omogočajo, da "počistite svojo kodo". Oglejmo si zgodovino, da bi razumeli namen nastanka mikrostoritev.
Skratka, mikrostoritve v našem trenutnem razumevanju so nastale takole: leta 2011 je James Lewis, analizirajoč delo različnih podjetij, opozoril na nastanek novega vzorca »mikro aplikacij«, ki je optimiziral SOA v smislu pospeševanja uvajanja storitve. Nekoliko kasneje, leta 2012, so na arhitekturnem vrhu vzorec preimenovali v mikrostoritev. Tako je bil prvotni cilj uvedbe mikrostoritev izboljšati razvpito čas za trg.
Mikrostoritve so bile leta 2015 na valu navdušenja. Po nekaterih raziskavah niti ena konferenca ni minila brez poročila na temo mikrostoritev. Poleg tega so bile nekatere konference posvečene izključno mikrostoritvam. Dandanes veliko projektov začne uporabljati ta arhitekturni slog in če projekt vsebuje na tone podedovane kode, se verjetno aktivno izvaja migracija na mikrostoritve.
Kljub vsemu naštetemu lahko dokaj majhno število razvijalcev še vedno definira pojem »mikrostoritev«. Toda o tem bomo govorili malo kasneje ...
Monolit
Arhitekturni slog, ki je v nasprotju z mikrostoritvami, je monolit (ali vse-v-enem). Verjetno ni smiselno govoriti, kaj je monolit, zato bom takoj navedel slabosti tega arhitekturnega sloga, ki je sprožil nadaljnji razvoj arhitekturnih stilov: velikost, povezljivost, razporeditev, razširljivost, zanesljivost in togost. V nadaljevanju predlagam, da si ogledamo vsako od pomanjkljivosti posebej.
Velikost
Monolit je zelo velik. In običajno komunicira z zelo veliko bazo podatkov. Aplikacija postane prevelika, da bi jo en razvijalec sploh razumel. Samo tisti, ki so porabili veliko časa za delo na tej kodi, lahko dobro delajo z monolitom, medtem ko bodo začetniki porabili veliko časa, da bi ugotovili monolit in ni nobenega zagotovila, da ga bodo ugotovili. Običajno se pri delu z monolitom vedno najde kakšen "pogojni" starejši, ki monolit bolj ali manj dobro pozna in v letu in pol premaga druge nove razvijalce. Seveda je tak pogojni starejši ena sama točka neuspeha in njegov odhod lahko vodi v smrt monolita.
Povezanost
Monolit je "velika krogla blata", katere spremembe lahko vodijo do nepredvidljivih posledic. S spremembami na enem mestu lahko poškodujete monolit na drugem (isti "popraskali ste se po ušesu, *@ je odpadel"). To je posledica dejstva, da imajo komponente v monolitu zelo zapletene in, kar je najpomembneje, neočitne odnose.
Uvajanje
Postavitev monolita je zaradi zapletenih odnosov med njegovimi komponentami dolgotrajen proces s svojim ritualom. Tak ritual običajno ni popolnoma standardiziran in se prenaša "ustno".
Razširljivost
Moduli Monolith imajo lahko nasprotujoče si potrebe po virih, kar zahteva kompromis glede strojne opreme. Predstavljajte si, da imate monolit, sestavljen iz storitev A in B. Storitev A je zahtevna glede velikosti trdega diska, storitev B pa zahteva RAM. V tem primeru mora stroj, na katerem je nameščen monolit, podpirati zahteve obeh storitev ali pa boste morali ročno umetno onemogočiti eno od storitev.
Še en primer (bolj klasičen): storitev A je veliko bolj priljubljena kot storitev B, zato želite, da je 100 storitev A in 10 storitev B. Spet dve možnosti: ali namestimo 100 polnopravnih monolitov ali nekaj storitve B bo treba onemogočiti ročno.
Zanesljivost
Ker so vse storitve nameščene skupaj, če monolit pade, potem vse storitve padejo naenkrat. Pravzaprav to morda niti ni tako slabo, vsaj delnih okvar v porazdeljenem sistemu ne bo, po drugi strani pa lahko zaradi napake v funkcionalnosti, ki jo uporablja 0.001 % uporabnikov, izgubite vse uporabnike. vašega sistema.
vztrajnost
Zaradi velikosti monolita je težko preiti na nove tehnologije. Posledično je ohranitev istega starejšega ločena naloga. Tehnološki sklop, izbran na začetku projekta, lahko postane blokada, ki ovira razvoj izdelka.
Zaključek
Naslednjič bomo govorili o tem, kako so ljudje poskušali rešiti te težave s prehodom na komponente in SOA.
Preberi več:
Vir: www.habr.com