Pozdravljeni vsi skupaj! Imamo odlične novice, OTUS junija ponovno začenja tečaj , v zvezi s katerim že tradicionalno z vami delimo uporabno gradivo.
Če ste naleteli na celotno zgodbo o mikrostoritvah brez konteksta, vam bo oproščeno, če mislite, da je malce čudna. Razdelitev aplikacije na fragmente, povezane z omrežjem, nujno pomeni dodajanje zapletenih načinov tolerance napak nastalemu porazdeljenemu sistemu.
Čeprav ta pristop vključuje razdelitev na številne neodvisne storitve, je končni cilj veliko več kot le izvajanje teh storitev na različnih strojih. Tu govorimo o interakciji z zunanjim svetom, ki je v svojem bistvu tudi porazdeljena. Ne v tehničnem smislu, ampak bolj v smislu ekosistema, ki ga sestavlja veliko ljudi, ekip, programov in vsak od teh delov mora tako ali drugače opravljati svoje delo.
Podjetja so na primer skupek porazdeljenih sistemov, ki skupaj prispevajo k doseganju nekega cilja. To dejstvo že desetletja ignoriramo in poskušamo doseči poenotenje s prenosi FTP ali orodji za integracijo podjetij, medtem ko se osredotočamo na svoje ločene cilje. Toda s prihodom storitev se je vse spremenilo. Storitve so nam pomagale pogledati čez obzorje in videti svet soodvisnih programov, ki delujejo skupaj. Vendar pa je za uspešno delo potrebno prepoznati in oblikovati dva bistveno različna svetova: zunanji svet, kjer živimo v ekosistemu številnih drugih storitev, in naš osebni, notranji svet, kjer vladamo sami.
Tako porazdeljen svet je drugačen od tistega, v katerem smo odraščali in smo ga vajeni. Načela gradnje tradicionalne monolitne arhitekture ne vzdržijo kritik. Pravilna vzpostavitev teh sistemov je torej več kot samo ustvarjanje odličnega diagrama na tabli ali odličnega dokaza koncepta. Ideja je, da bo tak sistem dolgo časa uspešno deloval. Na srečo obstajajo storitve že kar nekaj časa, čeprav izgledajo drugače. še vedno aktualna, tudi začinjena z Dockerjem, Kubernetesom in rahlo oguljenimi hipsterskimi bradami.
Danes si bomo torej ogledali, kako so se pravila spremenila, zakaj moramo ponovno razmisliti o svojem pristopu do storitev in podatkov, ki si jih med seboj posredujejo, in zakaj bomo za to potrebovali popolnoma drugačen nabor orodij.
Enkapsulacija ne bo vedno vaš prijatelj
Mikrostoritve lahko delujejo neodvisno druga od druge. Prav ta lastnost jim daje največjo vrednost. Ta ista lastnost omogoča, da se storitve širijo in rastejo. Ne toliko v smislu prilagajanja na kvadrilijone uporabnikov ali petabajtov podatkov (čeprav lahko tudi tu pomagajo), ampak v smislu prilagajanja glede na ljudi, saj ekipe in organizacije nenehno rastejo.
Vendar je neodvisnost dvorezen meč. To pomeni, da se lahko storitev vrti enostavno in naravno. Toda če je funkcija implementirana znotraj storitve, ki zahteva vključitev druge storitve, potem moramo na koncu narediti spremembe v obeh storitvah skoraj istočasno. V monolitu je to enostavno narediti, le narediš spremembo in jo pošlješ v objavo, v primeru sinhronizacije neodvisnih storitev pa bo več težav. Usklajevanje med ekipami in cikli izdajanja uničujejo prilagodljivost.
Kot del standardnega pristopa se preprosto poskušajo izogniti nadležnim spremembam od konca do konca in jasno delijo funkcionalnost med storitvami. Storitev enotne prijave je tukaj lahko dober primer. Ima dobro opredeljeno vlogo, ki jo ločuje od drugih storitev. Ta jasna ločitev pomeni, da se v svetu hitro spreminjajočih se zahtev za storitve okoli njega SSO verjetno ne bo spremenil. Obstaja v strogo omejenem kontekstu.
Težava je v tem, da v resničnem svetu poslovne storitve ne morejo ves čas ohranjati enake čiste ločitve vlog. Na primer, iste poslovne storitve bolj delujejo s podatki, ki prihajajo iz drugih podobnih storitev. Če ste spletni trgovec na drobno, bo obravnavanje toka naročil, kataloga izdelkov ali informacij o uporabnikih postala zahteva za številne vaše storitve. Vsaka od storitev bo za delovanje potrebovala dostop do teh podatkov.
Večina poslovnih storitev uporablja isti tok podatkov, zato je njihovo delo vedno prepleteno.
Tako smo prišli do pomembne točke, o kateri je vredno govoriti. Medtem ko storitve delujejo dobro za infrastrukturne komponente, ki delujejo večinoma ločeno, je večina poslovnih storitev na koncu veliko bolj tesno prepletena.
Dihotomija podatkov
Storitveno usmerjeni pristopi morda že obstajajo, vendar je še vedno malo informacij o tem, kako izmenjati velike količine podatkov med storitvami.
Glavna težava je, da so podatki in storitve neločljivi. Po eni strani nas enkapsulacija spodbuja, da skrijemo podatke, tako da lahko storitve ločimo med seboj in olajšamo njihovo rast in nadaljnje spremembe. Po drugi strani pa moramo biti sposobni svobodno deliti in osvajati skupne podatke, tako kot vsi drugi. Gre za to, da lahko takoj začnemo delati, tako svobodno kot v katerem koli drugem informacijskem sistemu.
Vendar pa informacijski sistemi nimajo veliko skupnega z enkapsulacijo. Pravzaprav je celo obratno. Baze podatkov storijo vse, kar lahko, da omogočijo dostop do podatkov, ki jih hranijo. Prihajajo z zmogljivim deklarativnim vmesnikom, ki vam omogoča spreminjanje podatkov, kot želite. Takšna funkcionalnost je pomembna na stopnji predhodnih raziskav, ne pa za obvladovanje naraščajoče kompleksnosti storitve, ki se nenehno razvija.
In tu se pojavi dilema. Protislovje. Dihotomija. Navsezadnje gre pri informacijskih sistemih za zagotavljanje podatkov, pri storitvah pa za skrivanje.
Ti dve sili sta temeljni. Podpirajo večino našega dela in se nenehno potegujejo za prevlado v sistemih, ki jih gradimo.
Ko storitveni sistemi rastejo in se razvijajo, vidimo različne manifestacije implikacij podatkovne dihotomije. Bodisi se bo storitveni vmesnik povečal, tako da bo zagotavljal vedno več funkcij in bo začel izgledati kot zelo elegantna domača baza podatkov, ali pa bomo razočarani in uvedli nek način za pridobivanje ali množično premikanje celih naborov podatkov iz storitve v storitev.
Po drugi strani pa bo ustvarjanje nečesa, kar je videti kot modna domača zbirka podatkov, povzročilo vrsto težav. Ne bomo se spuščali v podrobnosti o tem, kaj je nevarno skupno bazo podatkov, recimo samo, da predstavlja precejšen drag inženiring in delovanje za podjetje, ki ga poskuša uporabiti.
Še huje, količine podatkov pomnožijo težave z mejami storitev. Več skupnih podatkov kot je v storitvi, bolj zapleten bo postal vmesnik in težje bo kombinirati nize podatkov, ki prihajajo iz različnih storitev.
Alternativni pristop pridobivanja in premikanja celotnih podatkovnih nizov ima tudi svoje težave. Zdi se, da je običajen pristop k temu vprašanju preprosto pridobivanje in shranjevanje celotnega nabora podatkov, nato pa lokalno shranjevanje v vsaki potrošniški storitvi.
Težava je v tem, da različne storitve različno interpretirajo podatke, ki jih porabijo. Ti podatki so vedno pri roki. Lokalno se spreminjajo in predelujejo. Kmalu nimajo več nobene zveze s podatki v viru.
Bolj ko so kopije spremenljive, bolj se bodo podatki sčasoma spreminjali.
Še huje, take podatke je težko popraviti za nazaj ( tukaj pride res prav.) Pravzaprav nekateri nerešljivi tehnološki izzivi, s katerimi se soočajo podjetja, izvirajo iz heterogenih podatkov, ki se širijo od aplikacije do aplikacije.
Če želite najti rešitev za to pogosto težavo s podatki, morate razmišljati drugače. Morali bi postati prvorazredni objekti v arhitekturah, ki jih gradimo. take podatke imenuje "zunanji", kar je zelo pomembna lastnost. Enkapsulacijo potrebujemo, da ne razkrijemo notranjosti storitve, vendar pa moramo storitvam olajšati dostop do skupnih podatkov, da lahko pravilno opravljajo svoje delo.
Težava je v tem, da danes noben pristop ni aktualen, saj niti storitveni vmesniki, niti sporočanje, niti Shared Database ne nudijo dobre rešitve za delo z zunanjimi podatki. Storitveni vmesniki niso primerni za izmenjavo podatkov v katerem koli obsegu. Sporočila premaknejo podatke, vendar ne shranijo njihove zgodovine, zato se podatki sčasoma poškodujejo. Shared Databases je preveč osredotočen na eno točko, kar zavira napredek. Neizogibno se zataknemo v krogu podatkovnih napak:
Cikel napak podatkov
Tokovi: decentraliziran pristop do podatkov in storitev
V idealnem primeru bi morali spremeniti način dela storitev s podatki v skupni rabi. Trenutno vsak pristop trči v omenjeno dihotomijo, saj ni čarobnega prahu, ki bi ga lahko izdatno posuli in izginil. Lahko pa ponovno razmislimo o problemu in pridemo do kompromisa.
Ta kompromis pomeni določeno stopnjo centralizacije. Izkoristimo lahko mehanizem porazdeljenega beleženja, saj zagotavlja zanesljive, razširljive tokove. Zdaj želimo, da se storitve lahko pridružijo in izvajajo v teh skupnih nitih, vendar se želimo izogniti zapletenim centraliziranim božjim službam, ki izvajajo to obdelavo. Zato je najboljša možnost vgraditi pretočno obdelavo v vsako potrošniško storitev. To omogoča storitvam, da združijo nize podatkov iz različnih virov in delajo z njimi na način, ki ga potrebujejo.
Eden od načinov za dosego tega pristopa je uporaba platforme za pretakanje. Možnosti je veliko, a danes bomo razmislili o Kafki, saj nam uporaba njene Stateful Stream Processing omogoča učinkovito reševanje predstavljenega problema.
Uporaba mehanizma porazdeljenega beleženja nam omogoča, da sledimo uhojeni poti in uporabljamo sporočila za delo . Za ta pristop velja, da zagotavlja boljše skaliranje in ločevanje kot mehanizem zahteva-odgovor, ker daje nadzor nad pretokom prejemniku in ne pošiljatelju. Vendar pa morate plačati za vse v tem življenju in tukaj potrebujete posrednika. Toda za velike sisteme se ta kompromis splača (česar ne morete reči za vaše povprečne spletne aplikacije).
Če je za porazdeljeno beleženje odgovoren posrednik in ne tradicionalni sistem za sporočanje, lahko izkoristite prednosti dodatnih funkcij. Transport se lahko linearno prilagaja skoraj tako dobro kot porazdeljeni datotečni sistem. Podatke lahko dolgo časa hranimo v dnevnikih, tako da ne dobimo samo sporočil, ampak tudi skladišče informacij. Razširljivo shranjevanje brez strahu pred spremenljivim stanjem v skupni rabi.
Nato lahko uporabite mehanizem za obdelavo toka s stanjem, da dodate deklarativna orodja za bazo podatkov svojim porabniškim storitvam. To je zelo pomembna misel. Dokler so podatki shranjeni v skupnih tokovih, do katerih lahko dostopajo vse storitve, sta združevanje in obdelava, ki ju izvaja storitev, zasebna. Izolirani so znotraj strogo omejenega konteksta.
Znebite se podatkovne dihotomije z razdelitvijo nespremenljivega toka stanja. Nato dodajte to funkcionalnost vsaki storitvi z uporabo Stateful Stream Processing.
Torej, če mora vaša storitev delati z naročili, katalogom izdelkov, skladiščem, bo imela popoln dostop: samo vi se boste odločili, katere podatke boste združili, kje jih boste obdelali in kako naj se spreminjajo skozi čas. Kljub temu, da so podatki deljeni, je delo z njimi popolnoma decentralizirano. Proizvaja se znotraj vsake storitve, v svetu, kjer gre vse po vaših pravilih.
Delite podatke brez ogrožanja njihove celovitosti. Enkapsulirajte funkcijo, ne vir, v vsako storitev, ki jo potrebuje.
Tako se zgodi, da je treba podatke premakniti v velikem obsegu. Včasih storitev potrebuje lokalni zgodovinski nabor podatkov v izbranem motorju zbirke podatkov. Trik je v tem, da je mogoče zagotoviti, da se po potrebi kopija obnovi iz vira, tako da se obrnete na mehanizem porazdeljenega beleženja. Konektorji v Kafki to odlično opravijo.
Torej ima danes razpravljani pristop več prednosti:
- Podatki se uporabljajo v obliki deljenih tokov, ki se lahko dolgo časa hranijo v dnevnikih, mehanizem za delo z deljenimi podatki pa je v vsakem posameznem kontekstu vgrajen, kar omogoča enostavno in hitro delovanje storitev. Na ta način je mogoče uravnotežiti dihotomijo podatkov.
- Podatke, ki prihajajo iz različnih storitev, je mogoče enostavno združiti v nize. To poenostavlja interakcijo s podatki v skupni rabi in odpravlja potrebo po vzdrževanju lokalnih naborov podatkov v bazi podatkov.
- Stateful Stream Processing le predpomni podatke, skupni dnevniki pa ostanejo vir resnice, tako da problem poškodovanja podatkov skozi čas ni tako pereč.
- Storitve so v svojem bistvu podatkovno vodene, kar pomeni, da se kljub nenehni rasti obsega podatkov še vedno lahko hitro odzivajo na poslovne dogodke.
- Težave z razširljivostjo so na strani posrednika, ne storitev. To močno zmanjša kompleksnost pisanja storitev, saj ni treba razmišljati o razširljivosti.
- Dodajanje novih storitev ne zahteva spreminjanja starih, zato postane povezovanje novih storitev enostavnejše.
Kot lahko vidite, je več kot le POČITEK. Prejeli smo nabor orodij, ki vam omogočajo delo s podatki v skupni rabi na decentraliziran način.
V današnjem članku niso bili razkriti vsi vidiki. Še vedno moramo ugotoviti, kako najti ravnovesje med paradigmo zahteva-odziv in paradigmo, ki jo vodi dogodek. A s tem se bomo ukvarjali naslednjič. Obstajajo teme, ki jih morate bolje spoznati, na primer, zakaj je Stateful Stream Processing tako dober. O tem bomo govorili v tretjem članku. In obstajajo tudi drugi močni konstrukti, ki jih lahko uporabimo, če se zatečemo k njim, npr. . Spreminja igre za porazdeljene poslovne sisteme, saj zagotavlja transakcijska jamstva za v razširljivi obliki. O tem bo govora v četrtem članku. Nazadnje bomo morali pregledati podrobnosti izvajanja teh načel.
Toda za zdaj si zapomnite le to: podatkovna dihotomija je sila, s katero se soočamo pri gradnji poslovnih storitev. In tega se moramo spomniti. Trik je v tem, da vse obrnete na glavo in začnete podatke v skupni rabi obravnavati kot prvorazredne objekte. Stateful Stream Processing zagotavlja edinstven kompromis za to. Izogiba se centraliziranim "božjim komponentam", ki zavirajo napredek. Poleg tega zagotavlja agilnost, razširljivost in odpornost cevovodov za pretakanje podatkov ter jih doda vsaki storitvi. Zato se lahko osredotočimo na splošni tok zavesti, s katerim se lahko poveže katera koli storitev in dela z njenimi podatki. Zaradi tega so storitve bolj razširljive, zamenljive in avtonomne. Zato ne bodo dobro izgledali samo na tablah in pri preverjanju hipotez, temveč bodo delovali in se razvijali desetletja.
Vir: www.habr.com