Dichotómia údajov: prehodnotenie vzťahu medzi údajmi a službami

Ahojte všetci! Máme skvelú správu, OTUS v júni opäť spúšťa kurz "Softvérový architekt", v súvislosti s ktorou sa s vami už tradične delíme o užitočný materiál.

Ak ste narazili na celú túto vec s mikroslužbami bez akéhokoľvek kontextu, bolo by vám odpustené, keby ste si mysleli, že je to trochu zvláštne. Rozdelenie aplikácie na fragmenty prepojené sieťou nevyhnutne znamená pridanie komplexných režimov odolnosti voči chybám do výsledného distribuovaného systému.

Hoci tento prístup zahŕňa rozdelenie na mnoho nezávislých služieb, konečným cieľom je oveľa viac, než len spustenie týchto služieb na rôznych počítačoch. Hovoríme tu o interakcii s vonkajším svetom, ktorý je vo svojej podstate tiež distribuovaný. Nie v technickom zmysle, ale skôr v zmysle ekosystému, ktorý pozostáva z mnohých ľudí, tímov, programov a každá z týchto častí potrebuje nejako robiť svoju prácu.

Spoločnosti sú napríklad súborom distribuovaných systémov, ktoré spoločne prispievajú k dosiahnutiu nejakého cieľa. Túto skutočnosť sme celé desaťročia ignorovali, pokúšali sme sa dosiahnuť zjednotenie pomocou FTP súborov alebo pomocou nástrojov podnikovej integrácie, pričom sme sa sústredili na naše vlastné izolované ciele. S príchodom služieb sa však všetko zmenilo. Služby nám pomohli pozrieť sa za horizont a vidieť svet vzájomne závislých programov, ktoré spolupracujú. Na úspešné fungovanie je však potrebné rozpoznať a navrhnúť dva zásadne odlišné svety: vonkajší svet, kde žijeme v ekosystéme mnohých iných služieb, a náš osobný, vnútorný svet, kde vládneme sami.

Tento distribuovaný svet je iný ako ten, v ktorom sme vyrastali a na ktorý sme zvyknutí. Princípy výstavby tradičnej monolitickej architektúry neobstoja v kritike. Správnosť týchto systémov je teda o niečom viac než len o vytvorení skvelého diagramu tabule alebo skvelého dôkazu konceptu. Ide o to, aby sa zabezpečilo, že takýto systém bude úspešne fungovať počas dlhého časového obdobia. Našťastie, služby existujú už pomerne dlho, hoci vyzerajú inak. Lekcie SOA sú stále aktuálne, dokonca ochutené Dockerom, Kubernetesom a mierne ošúchanými hipsterskými bradami.

Dnes sa teda pozrieme na to, ako sa zmenili pravidlá, prečo musíme prehodnotiť spôsob, akým pristupujeme k službám a dátam, ktoré si navzájom odovzdávajú, a prečo na to budeme potrebovať úplne iné nástroje.

Zapuzdrenie nebude vždy vaším priateľom

Mikroslužby môžu fungovať nezávisle od seba. Práve táto vlastnosť im dáva najväčšiu hodnotu. Táto istá vlastnosť umožňuje službám škálovať a rásť. Ani nie tak v zmysle škálovania na kvadrilióny používateľov alebo petabajtov údajov (aj keď aj tam môžu pomôcť), ale v zmysle škálovania z hľadiska ľudí, keďže tímy a organizácie neustále rastú.

Nezávislosť je však dvojsečná zbraň. To znamená, že samotná služba môže bežať jednoducho a prirodzene. Ale ak je funkcia implementovaná v rámci služby, ktorá vyžaduje použitie inej služby, potom musíme vykonať zmeny v oboch službách takmer súčasne. V monolite je to jednoduché, stačí urobiť zmenu a poslať ju na uvoľnenie, ale v prípade synchronizácie nezávislých služieb bude viac problémov. Koordinácia medzi tímami a uvoľňovacie cykly ničia agilitu.

V rámci štandardného prístupu sa jednoducho snažia vyhnúť nepríjemným end-to-end zmenám a jasne rozdeľujú funkčnosť medzi služby. Dobrým príkladom tu môže byť služba jednotného prihlásenia. Má jasne definovanú úlohu, ktorá ho odlišuje od iných služieb. Toto jasné oddelenie znamená, že vo svete rýchlo sa meniacich požiadaviek na služby okolo neho sa služba jednotného prihlásenia pravdepodobne nezmení. Existuje v prísne obmedzenom kontexte.

Problém je v tom, že v reálnom svete si obchodné služby nemôžu udržiavať stále rovnaké čisté oddelenie rolí. Napríklad tie isté obchodné služby pracujú vo väčšej miere s údajmi pochádzajúcimi z iných podobných služieb. Ak ste zapojený do online maloobchodu, spracovanie toku objednávok, katalóg produktov alebo informácie o používateľovi sa stanú požiadavkou mnohých vašich služieb. Každá zo služieb bude potrebovať prístup k týmto údajom, aby mohla fungovať.

Väčšina obchodných služieb zdieľa rovnaký dátový tok, takže ich práca je vždy prepojená.

Dostávame sa teda k dôležitému bodu, o ktorom sa oplatí hovoriť. Zatiaľ čo služby fungujú dobre pre komponenty infraštruktúry, ktoré fungujú prevažne izolovane, väčšina obchodných služieb je nakoniec oveľa užšie prepojená.

Dátová dichotómia

Prístupy orientované na služby už môžu existovať, ale stále im chýba prehľad o tom, ako zdieľať veľké množstvo údajov medzi službami.

Hlavným problémom je, že dáta a služby sú neoddeliteľné. Na jednej strane nás zapuzdrenie nabáda k tomu, aby sme dáta skryli, aby bolo možné služby od seba oddeliť a uľahčiť ich rast a ďalšie zmeny. Na druhej strane musíme byť schopní voľne deliť a dobyť zdieľané dáta, rovnako ako akékoľvek iné dáta. Ide o to, aby ste mohli okamžite začať pracovať, tak slobodne ako v akomkoľvek inom informačnom systéme.

Informačné systémy však so zapuzdrením nemajú veľa spoločného. V skutočnosti je to úplne naopak. Databázy robia všetko, čo môžu, aby poskytli prístup k údajom, ktoré ukladajú. Prichádzajú s výkonným deklaratívnym rozhraním, ktoré vám umožňuje upravovať údaje podľa potreby. Takáto funkcionalita je dôležitá v štádiu predbežného výskumu, ale nie pre riadenie rastúcej zložitosti neustále sa vyvíjajúcej služby.

A tu vzniká dilema. Rozpor. Dichotómia. Informačné systémy sú totiž o poskytovaní údajov a služby o skrývaní.

Tieto dve sily sú základné. Základom veľkej časti našej práce je neustály boj o dokonalosť v systémoch, ktoré budujeme.

Ako systémy služieb rastú a vyvíjajú sa, vidíme dôsledky dátovej dichotómie mnohými spôsobmi. Buď bude rozhranie služby rásť a bude poskytovať stále sa zväčšujúcu škálu funkcií a začne vyzerať ako veľmi vychytená domáca databáza, alebo budeme frustrovaní a implementujeme nejaký spôsob, ako hromadne získavať alebo presúvať celé súbory údajov zo služby do služby.

Na druhej strane vytvorenie niečoho, čo vyzerá ako luxusná domáca databáza, povedie k celému radu problémov. Nebudeme zachádzať do podrobností o tom, prečo je to nebezpečné zdieľaná databáza, povedzme, že predstavuje značne nákladné inžinierske a prevádzkové náklady ťažkosti pre spoločnosť, ktorá sa ho snaží využiť.

Horšie je, že objemy dát zväčšujú problémy s hranicami služieb. Čím viac zdieľaných údajov sa nachádza v rámci služby, tým zložitejšie bude rozhranie a tým ťažšie bude kombinovať súbory údajov pochádzajúcich z rôznych služieb.

Alternatívny prístup extrahovania a presúvania celých súborov údajov má tiež svoje problémy. Bežný prístup k tejto otázke vyzerá ako jednoduché načítanie a uloženie celej množiny údajov a jej následné uloženie lokálne v každej spotrebnej službe.

Problém je v tom, že rôzne služby interpretujú údaje, ktoré spotrebúvajú, rôzne. Tieto údaje sú vždy po ruke. Sú upravované a spracovávané lokálne. Pomerne rýchlo prestanú mať čokoľvek spoločné s údajmi v zdroji.

Čím meniteľnejšie sú kópie, tým viac sa budú údaje v priebehu času líšiť.

Aby toho nebolo málo, takéto údaje sa spätne ťažko opravujú (MDM To je miesto, kde môže skutočne prísť na záchranu). V skutočnosti niektoré z neriešiteľných technologických problémov, ktorým podniky čelia, vyplývajú z rôznorodých údajov, ktoré sa množia z aplikácie na aplikáciu.

Aby sme našli riešenie tohto problému, musíme o zdieľaných dátach uvažovať inak. Musia sa stať prvotriednymi objektmi v architektúrach, ktoré staviame. Pat Helland nazýva takéto údaje „externé“, a to je veľmi dôležitá vlastnosť. Potrebujeme zapuzdrenie, aby sme neodhalili vnútorné fungovanie služby, ale musíme službám uľahčiť prístup k zdieľaným údajom, aby mohli správne vykonávať svoju prácu.

Problém je v tom, že ani jeden z týchto prístupov dnes nie je relevantný, keďže ani servisné rozhrania, ani zasielanie správ, ani zdieľaná databáza neponúkajú dobré riešenie pre prácu s externými údajmi. Servisné rozhrania nie sú vhodné na výmenu údajov v akomkoľvek rozsahu. Správy presúvajú údaje, ale neukladajú ich históriu, takže údaje sa časom poškodia. Zdieľané databázy sa príliš zameriavajú na jeden bod, čo brzdí pokrok. Nevyhnutne uviazneme v cykle zlyhania údajov:

Cyklus zlyhania údajov

Toky: decentralizovaný prístup k údajom a službám

V ideálnom prípade musíme zmeniť spôsob, akým služby pracujú so zdieľanými dátami. V tomto bode každý prístup čelí vyššie uvedenej dichotómii, pretože neexistuje žiadny magický prach, ktorý by sa naň mohol posypať, aby zmizol. Môžeme však problém prehodnotiť a dosiahnuť kompromis.

Tento kompromis zahŕňa určitý stupeň centralizácie. Môžeme použiť mechanizmus distribuovaného denníka, pretože poskytuje spoľahlivé, škálovateľné toky. Teraz chceme, aby sa služby mohli pripojiť a fungovať na týchto zdieľaných vláknach, ale chceme sa vyhnúť zložitým centralizovaným Božím službám, ktoré toto spracovanie vykonávajú. Najlepšou možnosťou je preto zabudovať spracovanie toku do každej spotrebiteľskej služby. Služby tak budú môcť kombinovať súbory údajov z rôznych zdrojov a pracovať s nimi tak, ako potrebujú.

Jedným zo spôsobov, ako dosiahnuť tento prístup, je použitie streamovacej platformy. Možností je veľa, ale dnes sa pozrieme na Kafku, keďže využitie jeho Stateful Stream Processing nám umožňuje efektívne riešiť prezentovaný problém.

Použitie mechanizmu distribuovaného protokolovania nám umožňuje sledovať dobre vyšliapanú cestu a používať na prácu správy architektúra riadená udalosťami. Tento prístup sa považuje za poskytujúci lepšie škálovanie a rozdelenie ako mechanizmus požiadavka-odpoveď, pretože poskytuje kontrolu nad tokom príjemcovi a nie odosielateľovi. Za všetko v tomto živote však musíte platiť a tu potrebujete makléra. Ale v prípade veľkých systémov sa kompromis oplatí (čo nemusí platiť pre vašu priemernú webovú aplikáciu).

Ak je sprostredkovateľ zodpovedný za distribuované protokolovanie a nie za tradičný systém zasielania správ, môžete využiť ďalšie funkcie. Prenos sa môže lineárne škálovať takmer rovnako dobre ako distribuovaný súborový systém. Dáta môžu byť uložené v protokoloch pomerne dlho, takže získame nielen výmenu správ, ale aj ukladanie informácií. Škálovateľné úložisko bez strachu z premenlivého zdieľaného stavu.

Potom môžete použiť stavové spracovanie toku na pridanie deklaratívnych databázových nástrojov do náročných služieb. Toto je veľmi dôležitá myšlienka. Zatiaľ čo údaje sú uložené v zdieľaných tokoch, ku ktorým majú prístup všetky služby, agregácia a spracovanie, ktoré služba vykonáva, je súkromné. Ocitnú sa izolovaní v prísne obmedzenom kontexte.

Odstráňte dichotómiu údajov oddelením toku nemenných stavov. Potom pridajte túto funkciu do každej služby pomocou Stateful Stream Processing.

Ak teda vaša služba potrebuje pracovať s objednávkami, produktovým katalógom, skladom, bude mať plný prístup: len vy sa rozhodnete, aké dáta skombinujete, kde ich spracujete a ako by sa mali časom meniť. Napriek tomu, že dáta sú zdieľané, práca s nimi je úplne decentralizovaná. Vyrába sa v rámci každej služby, vo svete, kde všetko ide podľa vašich pravidiel.

Zdieľajte dáta bez ohrozenia ich integrity. Zapuzdrejte funkciu, nie zdroj, v každej službe, ktorá to potrebuje.

Stáva sa, že údaje treba hromadne presúvať. Niekedy služba vyžaduje lokálny historický súbor údajov vo vybranom databázovom nástroji. Trik je v tom, že môžete zaručiť, že v prípade potreby bude možné kópiu obnoviť zo zdroja prístupom k mechanizmu distribuovaného protokolovania. Konektory v Kafke to robia skvelo.

Dnes diskutovaný prístup má teda niekoľko výhod:

• Dáta sa používajú vo forme spoločných tokov, ktoré je možné dlhodobo uchovávať v protokoloch a mechanizmus práce so spoločnými údajmi je pevne zapojený v každom jednotlivom kontexte, čo umožňuje, aby služby fungovali jednoducho a rýchlo. Týmto spôsobom je možné vyvážiť dichotómiu údajov.
• Dáta pochádzajúce z rôznych služieb je možné jednoducho kombinovať do súborov. To zjednodušuje interakciu so zdieľanými údajmi a eliminuje potrebu udržiavať lokálne súbory údajov v databáze.
• Stateful Stream Processing iba ukladá údaje do vyrovnávacej pamäte a zdrojom pravdy zostávajú všeobecné protokoly, takže problém poškodenia údajov v priebehu času nie je taký akútny.
• Vo svojej podstate sú služby založené na dátach, čo znamená, že napriek neustále sa zvyšujúcemu objemu dát môžu služby stále rýchlo reagovať na obchodné udalosti.
• Problémy so škálovateľnosťou dopadajú na makléra, nie na služby. To výrazne znižuje zložitosť služieb písania, pretože nie je potrebné myslieť na škálovateľnosť.
• Pridanie nových služieb si nevyžaduje zmenu starých, takže pripájanie nových služieb je jednoduchšie.

Ako vidíte, toto je viac než len ODPOČINOK. Dostali sme sadu nástrojov, ktoré umožňujú pracovať so zdieľanými dátami decentralizovane.

V dnešnom článku nie sú zahrnuté všetky aspekty. Stále musíme prísť na to, ako nájsť rovnováhu medzi paradigmou žiadosť-odpoveď a paradigmou riadenou udalosťami. Ale tomu sa budeme venovať nabudúce. Sú témy, ktoré musíte lepšie spoznať, napríklad prečo je Stateful Stream Processing také dobré. O tom si povieme v treťom článku. A existujú aj ďalšie silné konštrukty, ktoré môžeme využiť, ak sa k nim uchýlime, napr. Presne raz Spracovanie. Je to zmena hry pre distribuované obchodné systémy, pretože poskytuje transakčné záruky XA v škálovateľnej forme. O tom sa bude diskutovať vo štvrtom článku. Nakoniec si budeme musieť prejsť detaily implementácie týchto princípov.

Ale zatiaľ si pamätajte len toto: dátová dichotómia je sila, ktorej čelíme pri budovaní obchodných služieb. A toto si musíme pamätať. Trik je postaviť všetko na hlavu a začať so zdieľanými dátami zaobchádzať ako s prvotriednymi objektmi. Stateful Stream Processing poskytuje jedinečný kompromis. Vyhýba sa centralizovaným „Božským komponentom“, ktoré brzdia pokrok. Okrem toho zaisťuje agilnosť, škálovateľnosť a odolnosť kanálov streamovania údajov a pridáva ich do každej služby. Preto sa môžeme zamerať na všeobecný prúd vedomia, ku ktorému sa môže pripojiť akákoľvek služba a pracovať s jej údajmi. Vďaka tomu sú služby škálovateľnejšie, vzájomne zameniteľné a autonómne. Budú teda nielen dobre vyzerať na tabuliach a testoch hypotéz, ale budú aj fungovať a vyvíjať sa desaťročia.

Zistite viac o kurze.

Zdroj: hab.com