Zdravo svima! Imamo sjajne vijesti, OTUS ponovo pokreće kurs u junu , u vezi s kojim tradicionalno dijelimo koristan materijal s vama.
Ako ste naišli na cijelu ovu priču o mikroservisima bez ikakvog konteksta, bilo bi vam oprošteno što mislite da je malo čudna. Podjela aplikacije na fragmente povezane mrežom nužno znači dodavanje složenih načina tolerancije grešaka u rezultirajući distribuirani sistem.
Iako ovaj pristup uključuje podjelu na mnoge nezavisne usluge, krajnji cilj je mnogo više od samog pokretanja tih usluga na različitim strojevima. Ovdje je riječ o interakciji sa vanjskim svijetom, koji je također distribuiran u svojoj suštini. Ne u tehničkom smislu, već u smislu ekosistema koji se sastoji od mnogo ljudi, timova, programa i svaki od ovih dijelova na ovaj ili onaj način mora odraditi svoj posao.
Kompanije su, na primjer, skup distribuiranih sistema koji zajedno doprinose postizanju nekog cilja. Decenijama smo ignorisali ovu činjenicu, pokušavajući da postignemo ujedinjenje putem FTP transfera ili alata za integraciju preduzeća, dok smo se fokusirali na sopstvene posebne ciljeve. Ali s pojavom usluga sve se promijenilo. Usluge su nam pomogle da pogledamo dalje od horizonta i vidimo svijet međuzavisnih programa koji rade zajedno. Međutim, za uspješan rad potrebno je prepoznati i osmisliti dva fundamentalno različita svijeta: vanjski svijet, u kojem živimo u ekosistemu mnogih drugih usluga, i naš lični, unutrašnji svijet, u kojem vladamo sami.
Takav raspoređeni svijet razlikuje se od onog u kojem smo odrasli i na koji smo navikli. Principi izgradnje tradicionalne monolitne arhitekture ne podnose kritiku. Dakle, ispravljanje ovih sistema je više od kreiranja kul dijagrama bele table ili sjajnog dokaza koncepta. Ideja je da će takav sistem dugo raditi uspješno. Srećom, usluge postoje već duže vrijeme, iako izgledaju drugačije. još uvijek relevantan, čak i začinjen Dockerom, Kubernetesom i pomalo otrcanim hipsterskim bradama.
Dakle, danas ćemo pogledati kako su se pravila promijenila, zašto moramo preispitati svoj pristup uslugama i podacima koje oni međusobno prosljeđuju i zašto će nam za to trebati potpuno drugačiji alat.
Enkapsulacija neće uvijek biti vaš prijatelj
Mikroservise mogu raditi nezavisno jedna od druge. Upravo im to svojstvo daje najveću vrijednost. Ovo isto svojstvo omogućava uslugama da se povećavaju i rastu. Ne toliko u smislu skaliranja na kvadrilione korisnika ili petabajta podataka (iako oni mogu pomoći i ovdje), koliko u smislu skaliranja u smislu ljudi kao timova i organizacija kontinuirano rastu.
Međutim, nezavisnost je mač sa dve oštrice. Odnosno, sama usluga može se okretati lako i prirodno. Ali ako je funkcija implementirana unutar usluge koja zahtijeva da bude uključena još jedna usluga, tada ćemo na kraju morati napraviti promjene u obje usluge gotovo istovremeno. U monolitu, to je lako učiniti, samo napravite promjenu i pošaljete je u oslobađanje, ali u slučaju sinhronizacije nezavisnih servisa, bit će više problema. Koordinacija između timova i ciklusi izdavanja uništavaju fleksibilnost.
Kao dio standardnog pristupa, oni jednostavno pokušavaju izbjeći dosadne promjene s kraja na kraj, jasno dijeleći funkcionalnost između usluga. Usluga jedinstvene prijave može biti dobar primjer ovdje. Ima dobro definiranu ulogu koja ga izdvaja od ostalih usluga. Ovo jasno razdvajanje znači da je malo verovatno da će se SSO promeniti u svetu brzih promena zahteva za servisima oko njega. Postoji u strogo ograničenom kontekstu.
Problem je u tome što u stvarnom svijetu poslovne usluge ne mogu stalno održavati istu čistu podjelu uloga. Na primjer, iste poslovne usluge više rade s podacima koji dolaze iz drugih sličnih usluga. Ako ste trgovac na mreži, rukovanje protokom narudžbi, katalogom proizvoda ili korisničkim informacijama postat će zahtjev za mnoge vaše usluge. Svaka od usluga će trebati pristup ovim podacima da bi radila.
Većina poslovnih usluga koristi isti tok podataka, tako da je njihov rad uvijek isprepleten.
Tako dolazimo do važne tačke o kojoj vrijedi razgovarati. Dok usluge dobro funkcionišu za infrastrukturne komponente koje rade uglavnom izolovano, većina poslovnih usluga na kraju je mnogo čvršće isprepletena.
Dihotomija podataka
Pristupi orijentirani na usluge možda već postoje, ali još uvijek postoji malo informacija o tome kako razmjenjivati velike količine podataka između usluga.
Glavni problem je što su podaci i usluge neodvojivi. S jedne strane, enkapsulacija nas potiče da sakrijemo podatke kako bi se servisi mogli odvojiti jedni od drugih i olakšati njihov rast i daljnje promjene. S druge strane, moramo biti u mogućnosti da slobodno dijelimo i osvajamo preko zajedničkih podataka, kao i svaki drugi. Radi se o tome da možete odmah početi sa radom, slobodno kao iu svakom drugom informacionom sistemu.
Međutim, informacioni sistemi nemaju mnogo veze sa inkapsulacijom. U stvari, čak je i obrnuto. Baze podataka čine sve što mogu da daju pristup podacima koje pohranjuju. Dolaze sa moćnim deklarativnim sučeljem koje vam omogućava da modificirate podatke kako želite. Takva funkcionalnost je važna u fazi preliminarnog istraživanja, ali ne i za upravljanje rastućom složenošću usluge koja se stalno razvija.
I tu se javlja dilema. Kontradikcija. Dihotomija. Na kraju krajeva, informacioni sistemi se odnose na pružanje podataka, a usluge na skrivanje.
Ove dvije sile su fundamentalne. Oni podupiru veći dio našeg rada, neprestano se boreći za prevlast u sistemima koje gradimo.
Kako uslužni sistemi rastu i evoluiraju, vidimo različite manifestacije implikacija dihotomije podataka. Ili će interfejs usluge rasti kako bi pružio sve više i više funkcija i počeo izgledati kao vrlo otmjena domaća baza podataka, ili ćemo se frustrirati i implementirati neki način da ekstrahiramo ili premjestimo čitave skupove podataka u velikom broju sa usluge na uslugu.
Zauzvrat, kreiranje nečega što izgleda kao fensi homebrew baza podataka će dovesti do čitavog niza problema. Nećemo ulaziti u detalje o tome šta je opasno zajednička baza podataka, recimo da predstavlja značajan skup inženjerski i operativni za kompaniju koja to pokušava koristiti.
Što je još gore, količine podataka umnožavaju probleme s granicama usluga. Što se više uobičajenih podataka nalazi unutar usluge, to će sučelje postati složenije i to će biti teže kombinirati skupove podataka koji dolaze iz različitih usluga.
Alternativni pristup izdvajanja i premještanja cijelih skupova podataka također ima svoje probleme. Čini se da je uobičajen pristup ovom pitanju jednostavno dohvatiti i pohraniti cijeli skup podataka, a zatim ga pohraniti lokalno u svaku uslugu koja koristi.
Problem je u tome što različite usluge različito tumače podatke koje konzumiraju. Ovi podaci su uvijek pri ruci. Oni se modificiraju i obrađuju lokalno. Ubrzo prestaju da imaju bilo kakve veze sa podacima u izvoru.
Što su kopije promjenjivije, to će podaci više varirati tokom vremena.
Što je još gore, takve podatke je teško ispraviti retrospektivno ( evo gdje stvarno dobro dođe.) U stvari, neki od nerešivih tehnoloških izazova s kojima se preduzeća suočavaju proizlaze iz heterogenih podataka koji se šire od aplikacije do aplikacije.
Da biste pronašli rješenje za ovaj uobičajeni problem podataka, morate razmišljati drugačije. Oni bi trebali postati prvoklasni objekti u arhitekturi koju gradimo. naziva takve podatke "spoljnim", a ovo je veoma važna karakteristika. Potrebna nam je enkapsulacija kako ne bismo otkrili unutrašnje dijelove usluge, ali moramo olakšati uslugama pristup zajedničkim podacima kako bi mogli ispravno raditi svoj posao.
Problem je što nijedan pristup danas nije aktuelan, jer ni interfejsi servisa, ni razmena poruka, ni Shared Database ne nude dobro rešenje za rad sa eksternim podacima. Servisni interfejsi nisu pogodni za razmjenu podataka u bilo kojoj skali. Razmjena poruka premješta podatke, ali ne pohranjuje njihovu historiju, tako da se podaci vremenom oštećuju. Zajedničke baze podataka su previše fokusirane na jednu tačku, što usporava napredak. Neizbježno se zaglavimo u ciklusu neuspjeha podataka:
Ciklus neuspjeha podataka
Tokovi: decentralizovani pristup podacima i uslugama
U idealnom slučaju, moramo promijeniti način na koji usluge rade sa zajedničkim podacima. Trenutno se svaki pristup susreće sa pomenutom dihotomijom, jer ne postoji magična prašina koja se može velikodušno posipati po njoj i naterati da nestane. Međutim, možemo preispitati problem i doći do kompromisa.
Ovaj kompromis podrazumijeva određeni stepen centralizacije. Možemo iskoristiti prednosti distribuiranog mehanizma evidentiranja jer pruža pouzdane, skalabilne tokove. Sada želimo da se usluge pridruže i pokreću na ovim zajedničkim nitima, ali želimo izbjeći složene centralizirane Božje usluge koje obavljaju ovu obradu. Stoga je najbolja opcija ugraditi streaming obradu u svaku korisničku uslugu. Ovo omogućava uslugama da kombinuju skupove podataka iz različitih izvora i rade s njima na način koji im je potreban.
Jedan od načina da se postigne ovaj pristup je korištenje platforme za striming. Postoji mnogo opcija, ali danas ćemo razmotriti Kafku, jer nam korištenje njegove Stateful Stream Processinga omogućava da efikasno riješimo predstavljeni problem.
Korištenje mehanizma distribuiranog evidentiranja omogućava nam da pratimo utabani put i koristimo razmjenu poruka za rad . Smatra se da ovaj pristup pruža bolje skaliranje i razdvajanje od mehanizma zahtjev-odgovor jer daje kontrolu toka primaocu, a ne pošiljaocu. Međutim, u ovom životu morate platiti sve, a ovdje vam treba broker. Ali za velike sisteme, ovaj kompromis je vrijedan toga (što ne možete reći za vaše prosječne web aplikacije).
Ako je broker odgovoran za distribuirano evidentiranje, a ne tradicionalni sistem za razmjenu poruka, možete iskoristiti prednosti dodatnih funkcija. Transport se može linearno skalirati skoro jednako dobro kao i distribuirani sistem datoteka. Podaci se mogu dugo čuvati u logovima, tako da ne dobijamo samo poruke, već i spremište informacija. Skalabilna pohrana bez straha od promjenjivog zajedničkog stanja.
Zatim možete koristiti mehanizam obrade toka sa stanjem da dodate deklarativne alate baze podataka vašim uslugama koje koriste. Ovo je veoma važna misao. Sve dok su podaci pohranjeni u dijeljenim tokovima kojima mogu pristupiti sve usluge, agregacija i obrada koju usluga obavlja je privatna. Izolovani su u strogo ograničenom kontekstu.
Oslobodite se dihotomije podataka tako što ćete podijeliti tok nepromjenjivog stanja. Zatim dodajte ovu funkcionalnost svakoj usluzi koristeći Stateful Stream Processing.
Dakle, ako vaš servis mora da radi sa narudžbama, katalogom proizvoda, skladištem, imaće potpuni pristup: samo ćete vi odlučiti koje podatke ćete kombinovati, gde ćete ih obraditi i kako će se menjati tokom vremena. Unatoč činjenici da se podaci dijele, rad s njima je potpuno decentraliziran. Proizvodi se unutar svake usluge, u svijetu u kojem sve ide po vašim pravilima.
Dijelite podatke bez ugrožavanja njihovog integriteta. Inkapsulirajte funkciju, a ne izvor, u svaku uslugu kojoj je potrebna.
Tako se dešava da podatke treba masovno premještati. Ponekad je servisu potreban lokalni istorijski skup podataka u mašini baze podataka po izboru. Trik je u tome što se može zajamčiti da se, ako je potrebno, kopija može vratiti iz izvora kontaktiranjem distribuiranog mehanizma evidentiranja. Konektori u Kafki odlično rade ovo.
Dakle, pristup o kojem se danas raspravlja ima nekoliko prednosti:
- Podaci se koriste u obliku dijeljenih tokova koji se mogu dugo pohranjivati u logove, a mehanizam za rad sa zajedničkim podacima ugrađen je u svaki pojedinačni kontekst, što servisima omogućava lak i brz rad. Na ovaj način se dihotomija podataka može izbalansirati.
- Podaci koji dolaze iz različitih servisa mogu se lako kombinirati u skupove. Ovo pojednostavljuje interakciju sa zajedničkim podacima i eliminiše potrebu za održavanjem lokalnih skupova podataka u bazi podataka.
- Stateful Stream Processing samo kešira podatke, a uobičajeni dnevnici ostaju izvor istine, tako da problem oštećenja podataka tokom vremena nije tako akutan.
- U svojoj osnovi, usluge su vođene podacima, što znači da uprkos stalnom rastu količine podataka, usluge i dalje mogu brzo da reaguju na poslovne događaje.
- Problemi skalabilnosti padaju na brokera, a ne na usluge. Ovo uvelike smanjuje složenost usluga pisanja, jer nema potrebe razmišljati o skalabilnosti.
- Dodavanje novih usluga ne zahtijeva promjenu starih, tako da povezivanje novih usluga postaje lakše.
Kao što vidite, to je više od ODMORA. Dobili smo skup alata koji vam omogućava da radite sa zajedničkim podacima na decentralizovan način.
Nisu svi aspekti otkriveni u današnjem članku. Još uvijek moramo shvatiti kako balansirati između paradigme zahtjev-odgovor i paradigme vođene događajima. Ali mi ćemo se ovim pozabaviti sljedeći put. Postoje teme koje trebate bolje upoznati, na primjer, zašto je Stateful Stream Processing tako dobra. O tome ćemo govoriti u trećem članku. A postoje i drugi moćni konstrukti koje možemo koristiti ako im pribjegnemo, npr. . To je promjena igre za distribuirane poslovne sisteme jer pruža transakcijske garancije za u skalabilnom obliku. O tome će biti riječi u četvrtom članku. Konačno, moraćemo da prođemo kroz detalje implementacije ovih principa.
Ali za sada, samo zapamtite ovo: dihotomija podataka je sila s kojom se suočavamo kada gradimo poslovne usluge. I ovo moramo zapamtiti. Trik je u tome da se sve okrene na glavu i počne tretirati dijeljene podatke kao prvoklasne objekte. Stateful Stream Processing pruža jedinstven kompromis za ovo. Izbjegava centralizirane "Božje komponente" koje koče napredak. Štaviše, pruža agilnost, skalabilnost i otpornost cevovoda za protok podataka i dodaje ih svakoj usluzi. Stoga se možemo fokusirati na opći tok svijesti na koji se bilo koja usluga može povezati i raditi sa svojim podacima. To čini usluge skalabilnijim, zamjenjivim i autonomnijima. Stoga neće izgledati dobro samo na tabli i prilikom testiranja hipoteza, već će raditi i razvijati se decenijama.
izvor: www.habr.com