Bok svima! Imamo sjajne vijesti, OTUS ponovno pokreće tečaj u lipnju , u vezi s kojim već tradicionalno s vama dijelimo korisne materijale.
Ako ste naišli na cijelu ovu stvar s mikroservisima bez ikakvog konteksta, oprostit će vam se ako mislite da je pomalo čudna. Dijeljenje aplikacije u fragmente povezane mrežom nužno znači dodavanje složenih načina tolerancije grešaka rezultirajućem distribuiranom sustavu.
Iako ovaj pristup uključuje rastavljanje na mnoge neovisne usluge, krajnji cilj je puno više od pukog pokretanja tih usluga na različitim strojevima. Ovdje govorimo o interakciji s vanjskim svijetom, koja je također raspodijeljena u svojoj biti. Ne u tehničkom smislu, nego u smislu ekosustava koji se sastoji od mnogo ljudi, timova, programa i svaki od tih dijelova na neki način treba raditi svoj posao.
Tvrtke su, primjerice, skup distribuiranih sustava koji zajednički doprinose ostvarenju nekog cilja. Ignorirali smo tu činjenicu desetljećima, pokušavajući postići unifikaciju FTPingom datoteka ili korištenjem alata za integraciju poduzeća dok smo se fokusirali na vlastite izolirane ciljeve. No s dolaskom usluga sve se promijenilo. Usluge su nam pomogle da pogledamo iza horizonta i vidimo svijet međuovisnih programa koji rade zajedno. No, za uspješan rad potrebno je prepoznati i osmisliti dva bitno različita svijeta: vanjski svijet u kojem živimo u ekosustavu brojnih drugih usluga i naš osobni, unutarnji svijet u kojem vladamo sami.
Ovaj distribuirani svijet drugačiji je od onoga u kojem smo odrasli i na koji smo navikli. Načela gradnje tradicionalne monolitne arhitekture ne podnose kritiku. Dakle, ispravno postavljanje ovih sustava znači više od stvaranja cool dijagrama bijele ploče ili cool dokaza koncepta. Poanta je osigurati da takav sustav uspješno radi kroz dugo vremensko razdoblje. Srećom, usluge postoje već duže vrijeme, iako izgledaju drugačije. su i dalje aktualni, čak i začinjeni Dockerom, Kubernetesom i pomalo otrcanim hipsterskim bradama.
Dakle, danas ćemo pogledati kako su se pravila promijenila, zašto moramo ponovno razmisliti o načinu na koji pristupamo uslugama i podacima koje one međusobno prosljeđuju i zašto će nam za to trebati potpuno drugačiji alati.
Enkapsulacija vam neće uvijek biti prijatelj
Mikroservisi mogu raditi neovisno jedan o drugom. Upravo to svojstvo daje im najveću vrijednost. Ovo isto svojstvo omogućuje skaliranje i rast usluga. Ne toliko u smislu skaliranja na kvadrilijune korisnika ili petabajta podataka (iako i tu mogu pomoći), koliko u smislu skaliranja u smislu ljudi jer timovi i organizacije kontinuirano rastu.
Međutim, neovisnost je dvosjekli mač. Odnosno, sama usluga može raditi jednostavno i prirodno. Ali ako je funkcija implementirana unutar usluge koja zahtijeva korištenje druge usluge, tada na kraju moramo izvršiti izmjene na obje usluge gotovo istovremeno. U monolitu je to lako učiniti, samo napravite promjenu i pošaljete je u izdanje, ali u slučaju sinkronizacije neovisnih usluga bit će više problema. Koordinacija između timova i ciklusa izdavanja uništava agilnost.
Kao dio standardnog pristupa, oni jednostavno pokušavaju izbjeći dosadne promjene od kraja do kraja, jasno dijeleći funkcionalnost između usluga. Usluga jedinstvene prijave ovdje može biti dobar primjer. Ima jasno definiranu ulogu koja ga razlikuje od ostalih usluga. Ovo jasno razdvajanje znači da se u svijetu brzih promjena zahtjeva za uslugama oko njega usluga jedinstvene prijave vjerojatno neće promijeniti. Postoji unutar strogo ograničenog konteksta.
Problem je u tome što u stvarnom svijetu poslovne usluge ne mogu cijelo vrijeme održavati istu čistu podjelu uloga. Na primjer, iste poslovne usluge rade u većoj mjeri s podacima koji dolaze iz drugih sličnih usluga. Ako ste uključeni u online maloprodaju, obrada tijeka narudžbi, kataloga proizvoda ili podataka o korisniku postat će uvjet za mnoge vaše usluge. Svaka od usluga trebat će pristup tim podacima za rad.
Većina poslovnih usluga dijeli isti tok podataka, tako da je njihov rad uvijek isprepleten.
Tako dolazimo do važne točke o kojoj vrijedi razgovarati. Dok usluge dobro funkcioniraju za infrastrukturne komponente koje rade uglavnom izolirano, većina poslovnih usluga na kraju je mnogo tješnje isprepletena.
Dihotomija podataka
Pristupi orijentirani na usluge možda već postoje, ali im još uvijek nedostaje uvid u to kako dijeliti velike količine podataka između usluga.
Glavni problem je što su podaci i usluge neodvojivi. S jedne strane, enkapsulacija nas potiče na skrivanje podataka kako bi usluge bile odvojene jedna od druge i olakšale njihov rast i daljnje promjene. S druge strane, moramo biti u mogućnosti slobodno dijeliti i osvajati zajedničke podatke, baš kao i sve druge podatke. Poanta je da se može odmah krenuti s radom, slobodno kao u svakom drugom informacijskom sustavu.
Međutim, informacijski sustavi nemaju mnogo veze s enkapsulacijom. Zapravo je sasvim suprotno. Baze podataka čine sve što mogu kako bi omogućile pristup podacima koje pohranjuju. Dolaze s moćnim deklarativnim sučeljem koje vam omogućuje izmjenu podataka prema vašim potrebama. Takva je funkcionalnost 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. Uostalom, informacijski sustavi služe za pružanje podataka, a usluge za skrivanje.
Ove dvije sile su temeljne. Oni podupiru velik dio našeg rada, neprestano se boreći za izvrsnost u sustavima koje gradimo.
Kako sustavi usluga rastu i razvijaju se, vidimo posljedice dihotomije podataka na mnogo načina. Ili će sučelje usluge rasti, pružajući sve veći raspon funkcionalnosti i početi izgledati kao vrlo otmjena domaća baza podataka, ili ćemo postati frustrirani i implementirati neki način za dohvaćanje ili masovno premještanje cijelih skupova podataka od usluge do usluge.
S druge strane, stvaranje nečega što izgleda kao otmjena domaća baza podataka dovest će do čitavog niza problema. Nećemo ulaziti u detalje zašto je to opasno zajednička baza podataka, recimo samo da predstavlja značajno skupo inženjersko i operativno za tvrtku koja ga pokušava koristiti.
Što je još gore, količine podataka povećavaju probleme s granicama usluga. Što se više dijeljenih podataka nalazi unutar usluge, to će sučelje postati složenije i teže će biti kombinirati skupove podataka koji dolaze iz različitih usluga.
Alternativni pristup izdvajanja i premještanja cijelih skupova podataka također ima svojih problema. Uobičajeni pristup ovom pitanju izgleda kao jednostavno dohvaćanje i pohranjivanje cijelog skupa podataka, a zatim lokalno pohranjivanje u svakoj usluzi koja ga koristi.
Problem je u tome što različite službe različito tumače podatke koje konzumiraju. Ovi podaci su uvijek pri ruci. Modificiraju se i obrađuju lokalno. Vrlo brzo oni prestaju imati išta zajedničko s podacima u izvoru.
Što su kopije promjenjivije, to će podaci više varirati tijekom vremena.
Da stvar bude gora, takve je podatke teško ispraviti retrospektivno ( Ovdje stvarno može priskočiti u pomoć). Zapravo, neki od nerješivih tehnoloških problema s kojima se tvrtke suočavaju proizlaze iz različitih podataka koji se množe od aplikacije do aplikacije.
Da bismo pronašli rješenje za ovaj problem, moramo drugačije razmišljati o zajedničkim podacima. Oni moraju postati prvoklasni objekti u arhitekturi koju gradimo. naziva takve podatke "vanjskim", a to je vrlo važna značajka. Potrebna nam je enkapsulacija kako ne bismo otkrili unutarnje funkcioniranje usluge, ali moramo uslugama olakšati pristup dijeljenim podacima kako bi mogle ispravno obavljati svoj posao.
Problem je u tome što niti jedan pristup danas nije relevantan, budući da ni servisna sučelja, ni slanje poruka, ni dijeljena baza podataka ne nude dobro rješenje za rad s vanjskim podacima. Servisna sučelja nisu prikladna za razmjenu podataka u bilo kojoj mjeri. Razmjena poruka premješta podatke, ali ne pohranjuje njihovu povijest, pa se podaci s vremenom oštećuju. Zajedničke baze podataka previše se fokusiraju na jednu točku, što koči napredak. Neizbježno se zaglavimo u ciklusu neuspjeha podataka:
Ciklus neuspjeha podataka
Tokovi: decentralizirani pristup podacima i uslugama
U idealnom slučaju, moramo promijeniti način na koji usluge rade s dijeljenim podacima. U ovom trenutku, bilo koji pristup suočava se s gore spomenutom dihotomijom, jer ne postoji čarobna prašina koja se može posuti po njoj da nestane. Međutim, možemo ponovno razmisliti o problemu i postići kompromis.
Ovaj kompromis uključuje određeni stupanj centralizacije. Možemo koristiti mehanizam distribuiranog dnevnika jer pruža pouzdane, skalabilne tokove. Sada želimo da se usluge mogu pridružiti i raditi na tim zajedničkim nitima, ali želimo izbjeći složene centralizirane Božje službe koje vrše ovu obradu. Stoga je najbolja opcija ugraditi obradu toka u svaku korisničku uslugu. Na taj će način servisi moći kombinirati skupove podataka iz različitih izvora i raditi s njima onako kako im je potrebno.
Jedan od načina za postizanje ovog pristupa je korištenje platforme za strujanje. Postoji mnogo opcija, ali danas ćemo se osvrnuti na Kafku, budući da nam korištenje njegove Stateful Stream Processing omogućuje učinkovito rješavanje prikazanog problema.
Korištenje mehanizma distribuiranog bilježenja omogućuje nam da slijedimo dobro utabani put i koristimo slanje poruka za rad s . Smatra se da ovaj pristup pruža bolje skaliranje i particioniranje od mehanizma zahtjev-odgovor jer daje kontrolu nad protokom primatelju, a ne pošiljatelju. Međutim, za sve u ovom životu morate platiti, a ovdje vam je potreban posrednik. Ali za velike sustave kompromis se isplati (što možda nije slučaj za vašu prosječnu web aplikaciju).
Ako je posrednik odgovoran za distribuirano bilježenje, a ne za tradicionalni sustav slanja poruka, možete iskoristiti prednosti dodatnih značajki. Prijenos se može linearno skalirati gotovo jednako dobro kao i distribuirani datotečni sustav. Podaci se mogu pohraniti u zapisnike dosta dugo, tako da dobivamo ne samo razmjenu poruka, već i pohranu informacija. Skalabilna pohrana bez straha od promjenjivog dijeljenog stanja.
Zatim možete upotrijebiti obradu toka stanja kako biste dodali alate deklarativne baze podataka potrošačkim uslugama. Ovo je vrlo važna ideja. Dok se podaci pohranjuju u zajedničkim tokovima kojima sve usluge mogu pristupiti, agregacija i obrada koju usluga obavlja je privatna. Oni se nalaze izolirani unutar strogo ograničenog konteksta.
Uklonite dihotomiju podataka odvajanjem nepromjenjivog toka stanja. Zatim dodajte ovu funkcionalnost svakoj usluzi koristeći Stateful Stream Processing.
Dakle, ako vaša usluga treba raditi s narudžbama, katalogom proizvoda, skladištem, imat će potpuni pristup: samo ćete vi odlučiti koje ćete podatke kombinirati, gdje ih obrađivati i kako se trebaju mijenjati tijekom 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. Enkapsulirajte funkciju, a ne izvor, u svakoj usluzi koja je treba.
Događa se da podatke treba masovno preseliti. Ponekad usluga zahtijeva lokalni povijesni skup podataka u odabranoj bazi podataka. Trik je u tome što možete jamčiti da se, ako je potrebno, kopija može vratiti iz izvora pristupom mehanizmu distribuiranog zapisivanja. Konektori u Kafki to rade sjajno.
Dakle, pristup o kojem se danas raspravlja ima nekoliko prednosti:
- Podaci se koriste u obliku zajedničkih streamova, koji se mogu dugo pohraniti u zapisnike, a mehanizam za rad sa zajedničkim podacima ugrađen je u svaki pojedinačni kontekst, što omogućuje lak i brz rad usluga. Na taj način može se uravnotežiti dihotomija podataka.
- Podaci koji dolaze iz različitih usluga mogu se jednostavno kombinirati u skupove. To pojednostavljuje interakciju s dijeljenim podacima i eliminira potrebu za održavanjem lokalnih skupova podataka u bazi podataka.
- Stateful Stream Processing samo sprema podatke u predmemoriju, a izvor istine ostaju opći dnevnici, tako da problem oštećenja podataka tijekom vremena nije tako akutan.
- U svojoj srži, usluge su vođene podacima, što znači da unatoč stalno rastućoj količini podataka, usluge i dalje mogu brzo reagirati na poslovne događaje.
- Problemi s skalabilnošću padaju na brokera, a ne na usluge. Ovo značajno smanjuje složenost pisanja usluga, budući da nema potrebe razmišljati o skalabilnosti.
- Dodavanje novih usluga ne zahtijeva mijenjanje starih, tako da povezivanje novih usluga postaje lakše.
Kao što vidite, ovo je više od samog ODMORA. Dobili smo set alata koji vam omogućuju rad s dijeljenim podacima na decentraliziran način.
U današnjem članku nisu obuhvaćeni svi aspekti. Još uvijek moramo smisliti kako balansirati između paradigme zahtjev-odgovor i paradigme vođene događajima. Ali time ćemo se pozabaviti sljedeći put. Postoje teme koje trebate bolje upoznati, na primjer, zašto je Stateful Stream Processing tako dobar. O tome ćemo govoriti u trećem članku. A postoje i drugi snažni konstrukti koje možemo iskoristiti ako im pribjegnemo, na primjer, . On mijenja pravila igre za distribuirane poslovne sustave jer pruža transakcijska jamstva za u skalabilnom obliku. O tome će biti riječi u četvrtom članku. Na kraju, morat ćemo proći kroz detalje provedbe ovih načela.
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 okrenuti sve naglavačke i početi tretirati zajedničke podatke kao prvorazredne objekte. Stateful Stream Processing pruža jedinstveni kompromis za to. Izbjegava centralizirane "Božje komponente" koje koče napredak. Štoviše, osigurava agilnost, skalabilnost i otpornost cjevovoda za strujanje podataka i dodaje ih svakoj usluzi. Stoga se možemo usredotočiti na opći tok svijesti na koji se bilo koji servis može povezati i raditi sa svojim podacima. To čini usluge skalabilnijima, međusobno zamjenjivima i autonomnijima. Dakle, ne samo da će izgledati dobro na bijelim pločama i testovima hipoteza, već će također raditi i razvijati se desetljećima.
Izvor: www.habr.com