Përshëndetje, habr. Regjistrimi për një transmetim të ri kursi është i hapur tani në OTUS . Në prag të fillimit të kursit, dua të ndaj me ju artikullin tim origjinal.
Paraqitje
Zgjedhja e stilit arkitektonik është një nga vendimet themelore teknike gjatë ndërtimit të një sistemi informacioni. Në këtë seri artikujsh, unë propozoj të analizoj stilet më të njohura arkitekturore për aplikimet e ndërtimit dhe t'i përgjigjem pyetjes se kur stili arkitektonik është më i preferuari. Në procesin e prezantimit, do të përpiqem të vizatoj një zinxhir logjik që shpjegon zhvillimin e stileve arkitekturore nga monolitet në mikroshërbime.
Pak histori
Nëse përpiqeni të pyesni zhvilluesit: "Pse na duhen mikroshërbimet?", do të merrni një sërë përgjigjesh. Do të dëgjoni që mikroshërbimet përmirësojnë shkallëzueshmërinë, e bëjnë kodin më të lehtë për t'u kuptuar, përmirësojnë tolerancën ndaj gabimeve dhe ndonjëherë do të dëgjoni se ju lejojnë të "pastroni kodin tuaj". Le të shohim historinë për të kuptuar qëllimin e shfaqjes së mikroshërbimeve.
Shkurtimisht, mikroshërbimet në kuptimin tonë aktual u ngritën si më poshtë: në vitin 2011, James Lewis, duke analizuar punën e kompanive të ndryshme, tërhoqi vëmendjen për shfaqjen e një modeli të ri "mikro-aplikacioni", i cili optimizoi SOA në drejtim të përshpejtimit të vendosjes së shërbimet. Pak më vonë, në vitin 2012, në një samit të arkitekturës, modeli u riemërua microservice. Kështu, qëllimi fillestar i prezantimit të mikroshërbimeve ishte përmirësimi i famëkeqeve koha për treg.
Mikroshërbimet ishin në valën e zhurmës në 2015. Sipas disa studimeve, asnjë konferencë e vetme nuk ishte e plotë pa një raport mbi temën e mikroshërbimeve. Për më tepër, disa konferenca iu dedikuan ekskluzivisht mikroshërbimeve. Në ditët e sotme, shumë projekte fillojnë të përdorin këtë stil arkitekturor, dhe nëse projekti përmban mijëra kode të trashëgimisë, atëherë migrimi në mikroshërbime ndoshta po kryhet në mënyrë aktive.
Pavarësisht nga të gjitha sa më sipër, një numër mjaft i vogël zhvilluesish ende mund të përcaktojnë konceptin e "mikroshërbimit". Por për këtë do të flasim pak më vonë...
Monolit
Stili arkitektonik që bën kontrast me mikroshërbimet është monoliti (ose gjithçka-në-një). Ndoshta nuk ka kuptim të tregohet se çfarë është një monolit, kështu që unë do të rendis menjëherë disavantazhet e këtij stili arkitekturor, i cili inicioi zhvillimin e mëtejshëm të stileve arkitekturore: madhësinë, lidhjen, vendosjen, shkallëzueshmërinë, besueshmërinë dhe ngurtësinë. Më poshtë unë propozoj të hedhim një vështrim në secilën nga mangësitë veç e veç.
Размер
Monoliti është shumë i madh. Dhe zakonisht komunikon me një bazë të dhënash shumë të madhe. Aplikacioni bëhet shumë i madh që një zhvillues ta kuptojë fare. Vetëm ata që kanë shpenzuar shumë kohë duke punuar në këtë kod mund të punojnë mirë me monolitin, ndërsa fillestarët do të shpenzojnë shumë kohë duke u përpjekur të kuptojnë monolitin dhe nuk ka asnjë garanci se do ta kuptojnë atë. Zakonisht, kur punoni me një monolit, ka gjithmonë një të moshuar "të kushtëzuar" që e njeh pak a shumë mirë monolitin dhe rrah duart e zhvilluesve të tjerë të rinj brenda një viti e gjysmë. Natyrisht, një i moshuar i tillë i kushtëzuar është një pikë e vetme dështimi, dhe largimi i tij mund të çojë në vdekjen e monolitit.
Lidhja
Monoliti është një "top i madh balte", ndryshimet në të cilat mund të çojnë në pasoja të paparashikueshme. Duke bërë ndryshime në një vend, ju mund të dëmtoni monolitin në një tjetër (e njëjta "ke gërvishte veshin, *@ ra"). Kjo për faktin se përbërësit në monolit kanë marrëdhënie shumë komplekse dhe, më e rëndësishmja, jo të dukshme.
Vendosja
Vendosja e një monoliti, për shkak të marrëdhënieve komplekse midis përbërësve të tij, është një proces i gjatë me ritualin e vet. Një ritual i tillë zakonisht nuk është plotësisht i standardizuar dhe transmetohet "me gojë".
Shkallëzueshmëria
Modulet monolit mund të kenë nevoja kontradiktore për burime, duke kërkuar që të bëhet një kompromis për sa i përket harduerit. Imagjinoni që keni një monolit të përbërë nga shërbimet A dhe B. Shërbimi A kërkon madhësinë e hard drive-it dhe shërbimi B kërkon RAM-in. Në këtë rast, ose makina në të cilën është instaluar monoliti duhet të mbështesë kërkesat e të dy shërbimeve, ose do të duhet të çaktivizoni manualisht artificialisht një nga shërbimet.
Një shembull tjetër (më klasik): shërbimi A është shumë më popullor se shërbimi B, kështu që ju dëshironi që të ketë 100 shërbime A dhe 10 shërbime B. Përsëri, dy opsione: ose të vendosim 100 monolite të plota, ose në disa më pas shërbimet B do të duhet të çaktivizohen manualisht.
Seriozitet
Meqenëse të gjitha shërbimet janë të vendosura së bashku, nëse monoliti bie, atëherë të gjitha shërbimet bien menjëherë. Në fakt, kjo mund të mos jetë aq e keqe, të paktën nuk do të ketë dështime të pjesshme në një sistem të shpërndarë, por nga ana tjetër, për shkak të një gabimi në funksionalitet që përdoret nga 0.001% e përdoruesve, ju mund të humbni të gjithë përdoruesit të sistemit tuaj.
Inercia
Për shkak të madhësisë së monolitit, është e vështirë të kalosh në teknologji të reja. Si rezultat, mbajtja e të njëjtit të moshuar është një detyrë më vete. Skema e teknologjisë e zgjedhur në fillim të një projekti mund të bëhet një bllok që pengon zhvillimin e produktit.
Përfundim
Herën tjetër do të flasim se si njerëzit janë përpjekur t'i zgjidhin këto probleme duke kaluar te komponentët dhe SOA.
Lexo më shumë:
Burimi: www.habr.com