Ahojte všetci! Máme skvelé správy, v júni OTUS opäť spúšťa kurz , a preto s vami tradične zdieľame užitočný materiál.
Ak ste sa s touto históriou mikroservisov stretli bez akéhokoľvek kontextu, môžete to považovať za trochu zvláštne. Rozdelenie aplikácie na fragmenty, ktoré sú navzájom prepojené sieťou, nevyhnutne znamená pridanie zložitých režimov odolnosti voči zlyhaniam do výsledného distribuovaného systému.
Napriek tomu, že takýto prístup zahŕňa rozdelenie na mnoho nezávislých služieb, konečný cieľ je oveľa väčší ako len to, aby tieto služby fungovali na rôznych zariadeniach. Ide o interakciu s okolím, ktoré je svojou podstatou tiež distribuované. Nie v technickom zmysle, skôr v zmysle ekosystému, ktorý sa skladá z mnohých ľudí, tímov, programov, a každá z týchto častí nejako musí vykonávať svoju prácu.
Spoločnosti, napríklad, predstavujú súbor distribuovaných systémov, ktoré spolu prispievajú k dosiahnutiu určitého cieľa. Tento fakt sme ignorovali celé desaťročia a snažili sme sa dosiahnuť integráciu, pričom sme si vymieňali súbory cez FTP alebo používali nástroje podnikovej integrácie, sústreďujúc sa na naše osobné izolované ciele. Avšak s príchodom služieb sa všetko zmenilo. Služby nám pomohli nazrieť za obzor a vidieť svet vzájomne závislých programov, ktoré spolupracujú. Aby sme však boli úspešní, je potrebné si uvedomiť a navrhnúť dva zásadne odlišné svety: vonkajší svet, kde žijeme v ekosystéme mnohých ďalších služieb, a náš osobný, vnútorný svet, kde vládneme osamote.
Takýto distribuovaný svet sa líši od toho, v ktorom sme vyrastali a na ktorý sme si zvykli. Princípy vytvárania tradičnej monolitnej architektúry nevydržia žiadnu kritiku. Preto správne pochopenie takýchto systémov je niečo viac ako len vytvorenie skvelej schémy na bielej tabuľke alebo skvelého dôkazu konceptu. Ide o to, aby takýto systém úspešne fungoval dlhodobo. Našťastie, služby existujú už pomerne dlho, aj keď vyzerajú rôzne. stále sú aktuálne, aj keď sú ochutené Dockerom, Kubernetesom a mierne poznačené hipsterskými bradami.
Dnes sa pozrieme na to, ako sa zmenili pravidlá, prečo musíme prehodnotiť náš prístup k službám a informáciám, ktoré si navzájom prenášajú, a prečo k tomu budeme potrebovať úplne iný súbor nástrojov.
Inkapsulácia nemusí byť vždy vaším priateľom.
Mikroslužby môžu fungovať nezávisle jedna od druhej. Práve táto vlastnosť im dáva najväčšiu hodnotu. Taktiež umožňuje službám rásť a rozširovať sa. Nie v zmysle rozšírenia na kvadrilióny používateľov alebo petabajty dát (aj keď aj v tom môžu pomôcť), ale v zmysle rastu z pohľadu ľudí, keďže tímy a organizácie sa neustále zväčšujú.
Avšak nezávislosť je dvojsečná zbraň. To znamená, že služba sama o sebe môže bežať jednoducho a bez problémov. Ale ak sa v službe implementuje funkcia, ktorá vyžaduje zapojiť inú službu, nakoniec musíme upravovať obe služby takmer súčasne. V monolite je to jednoduché, jednoducho zmeníte a vydáte novú verziu, ale v prípade synchronizácie nezávislých služieb sú problémy väčšie. Koordinácia medzi tímami a cyklami vydaní narúša flexibilitu.
V rámci štandardného prístupu sa snažíme vyhýbať zložitým priečnym zmenám jasným oddelením funkcionality medzi službami. Služba jednotného prístupu môže byť dobrým príkladom. Má jasne definovanú úlohu, ktorá ju odlišuje od ostatných služieb. Takéto jasné rozdelenie znamená, že v svete rýchlo sa meniacich požiadaviek na okolitých službách sa služba jednotného prístupu pravdepodobne nezmení. Existuje v rámci prísne obmedzeného kontextu.
Problém je v tom, že v reálnom svete obchodné služby nemôžu neustále udržiavať rovnako čisté oddelenie rolí. Napríklad, tieto obchodné služby do značnej miery pracujú s údajmi, ktoré prichádzajú z iných podobných služieb. Ak sa zaoberáte online predajom, spracovanie toku objednávok, katalógu produktov alebo informácií o používateľoch sa stane požiadavkou pre mnohé vaše služby. Každá zo služieb potrebuje na svoju prácu prístup k týmto údajom.
Väčšina obchodných služieb využíva rovnaký tok údajov, preto je ich práca nevyhnutne prepletená.
Takto sme sa dostali k dôležitému momentu, o ktorom stojí za to hovoriť. Zatiaľ čo služby dobre fungujú pre komponenty infraštruktúry, ktoré pracujú do značnej miery izolovane, väčšina obchodných služieb je prepletená oveľa tesnejšie.
Dichotómia údajov
Prístupy zamerané na služby môžu už existovať, avšak stále je ich málo informácií o tom, ako vymieňať veľké objemy údajov medzi službami.
Hlavný problém spočíva v tom, že údaje a služby sú nerozlučné. Na jednej strane enkapsulácia nabáda, aby sme skrývali údaje, aby sa služby mohli oddeliť one od druhej a uľahčiť ich rast a budúce zmeny. Na druhej strane potrebujeme mať možnosť voľne zdieľať a vlastniť spoločné údaje, rovnako ako akékoľvek iné. Ide o to, aby sme mohli okamžite začať pracovať, tak rovnako voľne, ako aj v akejkoľvek inej informačnej sústave.
Avšak informačné systémy majú málo spoločného s enkapsuláciou. V skutočnosti ešte naopak. Databázy robia všetko, čo môžu, aby poskytli prístup k údajom, ktoré obsahujú. Sídlia s mocným deklaratívnym rozhraním, ktoré umožňuje transformovať údaje podľa vašich potrieb. 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 nastáva dilema. Rozpor. Dichotómia. Predsa len informačné systémy sú o poskytovaní údajov a služby sú o skrývaní.
Tieto dve sily sú základné. Ležia v základe väčšiny našej práce, neustále sa snažiac získať prevahu v systémoch, ktoré vytvárame.
Ako sa systémy služieb rozrastajú a vyvíjajú, vidíme rôzne prejavy dôsledkov dichotómie údajov. Buď sa rozhranie služby rozrastie, poskytujúc čoraz širšiu škálu funkcií a začne vyzerať ako veľmi podivná domáca databáza, alebo nás postihne sklamanie a realizujeme nejaký spôsob masívneho extrahovania alebo presúvania celých súborov údajov zo služby do služby.
Navyše vytvorenie niečoho, čo vyzerá ako podivná domáca databáza, prinesie celú radu problémov. Nebudeme sa zaoberať podrobnosťami o tom, čím je nebezpečná zdieľaná databáza, jednoducho povedzme, že predstavuje značné nákladné inžinierske a prevádzkové pre spoločnosť, ktorá sa ju snaží používať.
Horšie je, že objemy údajov znásobujú problémy s hranicami služieb. Čím viac spoločných údajov je v rámci služby, tým zložitejšie sa stane rozhranie a tým ťažšie bude spojiť súbory údajov prichádzajúce z rôznych služieb.
Alternatívny prístup s extrahovaním a presúvaním celých súborov údajov má tiež svoje problémy. Bežný prístup k tejto otázke vyzerá ako jednoduché extrahovanie a ukladanie súboru údajov v celku, a potom jeho uloženie lokálne v každej službe-spotrebiteľovi.
Problém je v tom, že rôzne služby interpretujú údaje, ktoré spotrebúvajú, rôzne. Tieto údaje sú vždy po ruke. Menia sa a spracovávajú lokálne. Čoskoro prestanú mať niečo spoločné s údajmi v zdroji.
Čím viac sú kópie mutabilné, tým viac sa údaje budú líšiť s časom.
Ešte horšie je, že takéto údaje je ťažké opraviť spätne ( tu môže naozaj prísť na pomoc). V skutočnosti niektoré z ťažko riešiteľných technických problémov, ktorým čelí biznis, vznikajú z rozličných údajov, ktoré sa množia z aplikácie na aplikáciu.
Aby sme našli riešenie tohto problému so spoločnými údajmi, musíme myslieť inak. Mali by sa stať objektmi prvej triedy v architektúrach, ktoré budujeme. nazýva takéto údaje „externými“, a to je veľmi dôležitá vlastnosť. Potrebujeme enkapsuláciu, aby sme neodhalili vnútornú štruktúru služby, ale musíme uľahčiť službám prístup k zdieľaným údajom, aby mohli správne vykonávať svoju prácu.
Problém spočíva v tom, že žiaden z prístupov dnes už nie je aktuálny, pretože ani rozhrania služby, ani výmena správ, ani zdieľaná databáza nenabízajú dobré riešenie na prácu s externými údajmi. Rozhrania služby sú nevhodné na výmenu údajov v akomkoľvek rozsahu. Výmena správ prenáša údaje, ale neuchováva ich históriu, preto sa časom údaje poškodzujú. Zdieľané databázy sú príliš zamerané na jedno miesto, čo obmedzuje pokrok. Nevyhnutne sa ocitáme v cykle nefunkčných údajov:
Cyklus nefunkčných údajov
Toky: decentralizovaný prístup k údajom a službám
Ideálne by sme mali zmeniť prístup k tomu, ako služby pracujú so zdieľanými údajmi. V súčasnosti sa akýkoľvek prístup stretáva s vyššie uvedenou dichotómiou, pretože neexistuje žiadny čarovný prášok, ktorým by sme to mohli štedro posypať a nechať to zmiznúť. Môžeme však prekonať problém a dosiahnuť kompromis.
Tento kompromis predpokladá určitú úroveň centralizácie. Môžeme využiť mechanizmus distribuovaných logov, pretože zabezpečuje spoľahlivé a škálovateľné toky. Teraz potrebujeme, aby sa služby mohli pripojiť a pracovať s týmito zdieľanými tokmi, avšak chceme sa vyhnúť zložitým centralizovaným službám, ktoré túto prácu vykonávajú. Preto je najlepšou možnosťou integrovať spracovanie toku do každej služby-spotrebiteľa. Tak služby budú schopné spojiť súbory údajov z rôznych zdrojov a pracovať s nimi tak, ako potrebujú.
Jedným zo spôsobov, ako dosiahnuť takýto prístup, je použitie streamingovej platformy. Existuje mnoho možností, ale dnes sa zameriame práve na Kafka, pretože využitie jej Stateful Stream Processing, umožňuje efektívne riešiť predstavený problém.
Použitie mechanizmu distribuovaného logovania nám umožňuje ísť po vyskúšanej ceste a využívať výmenu správ, aby sme pracovali s . Predpokladá sa, že tento prístup zaisťuje lepšie škálovanie a rozdelenie ako mechanizmus „požiadavka-odpoveď“, keďže dáva kontrolu nad tokom prijímateľovi, nie odosielateľovi. Ale za všetko v tomto živote sa musí platiť, a tu budete potrebovať broker. Pre veľké systémy však tento kompromis stojí za to (čo sa nedá povedať o vašich priemerných webových aplikáciách).
Ak za distribuované logovanie zodpovedá broker, nie tradičný systém výmeny správ, môžete využiť ďalšie funkcie. Transport sa dá lineárne škálovať tak dobre, ako distribuovaný súborový systém. Dáta môžu byť uchovávané v logoch dostatočne dlho, takže získavame nielen výmenu správ, ale aj úložisko informácií. Škálovateľné úložisko bez obáv o zmeniteľný spoločný stav.
Následne môžete využiť mechanizmus spracovania prúdu so zachovaním stavu (stateful stream processing) na pridanie deklaratívnych nástrojov databázy do spotrebiteľských služieb. To je veľmi dôležitá myšlienka. Kým sú dáta uchovávané v spoločných prúdoch, ku ktorým majú prístup všetky služby, zlučovanie a spracovanie, ktoré služba vykonáva, sú súkromné. Nachádzajú sa v izolovanom a jasne obmedzenom kontexte.
Zbavte sa dichotómie dát rozdelením nemenného prúdu stavov. Potom túto funkciu pridajte do každej služby pomocou spracovania prúdu so zachovaním stavu.
Takže ak vaša služba musí pracovať s objednávkami, produktovým katalógom, skladom, bude mať úplný prístup: len vy rozhodujete, aké dáta zlúčiť, kde ich spracovať a ako by sa mali v priebehu času meniť. Napriek tomu, že sú dáta spoločné, práca s nimi je úplne decentralizovaná. Prebieha v rámci každej služby, v svete, kde všetko ide podľa vašich pravidiel.
Zdieľajte dáta tak, aby sa neporušila ich integrita. Inkapsulujte funkciu, nie zdroj, v každej službe, ktorej je potrebná.
Niekedy nastane situácia, že je potrebné preniesť veľké množstvo dát. Niekedy služby potrebujú lokálny historický súbor údajov vo zvolenom databázovom engíne. Kľúčovým je, že sa dá zaručiť, že ak je to potrebné, kópia môže byť obnovená zo zdroja prostredníctvom distribuovaného logovania. Konektory v Kafke výborne zvládajú túto úlohu.
Takže uvedený prístup má niekoľko výhod:
- Údaje sa používajú ako spoločné toky, ktoré môžu byť dlhodobo uchovávané v logoch, pričom mechanizmus práce so spoločnými údajmi je zakódovaný v každom jednotlivom kontexte, čo umožňuje službám fungovať jednoducho a rýchlo. Takýmto spôsobom môžeme vyvážiť dichotómiu údajov.
- Údaje prichádzajúce z rôznych služieb sa môžu ľahko kombinovať do súborov. Týmto sa zjednodušuje interakcia so spoločnými údajmi a mizne potreba udržiavať lokálne súbory údajov v databáze.
- Stateful Stream Processing len ukladajú údaje do cache, pričom zdrojom pravdy zostávajú spoločné logy, takže problém poškodenia údajov časom nie je tak naliehavý.
- V podstate, služby sú riadené údajmi, to znamená, že napriek neustálemu rastu objemov údajov môžu služby stále rýchlo reagovať na obchodné udalosti.
- Problémy so škálovaním ležia na brokerovi, nie na službách. Týmto sa výrazne znižuje zložitosti písania služieb, pretože nie je potrebné premýšľať o škálovaní.
- Pridanie nových služieb si nevyžaduje zmeny starých, takže pripojenie nových služieb sa stáva jednoduchším.
Ako vidíte, je to viac než len REST. Získali sme súbor nástrojov, ktorý umožňuje decentralizovanú prácu so spoločnými údajmi.
Dnešný článok sa nevenuje všetkým aspektom. Ešte sa musíme rozhodnúť, ako vyvážiť medzi paradigmi "požiadavka-odpoveď" a udalosťou orientovanou paradigmat. Ale s tým sa vyrovnáme nabudúce. Existujú témy, ktoré si zaslúžia lepšie porozumenie, napríklad, prečo je Stateful Stream Processing taký dobrý. O tomto budeme hovoriť v treťom článku. A sú tu aj iné mocné konštrukcie, ktoré môžeme využiť, ak sa na ne odvoláme, napríklad, . Jej prostredníctvom sa menia pravidlá hry pre distribuované obchodné systémy, pretože tento koncept poskytuje transakčné záruky pre škálovateľnú formu. O tom bude reč v štvrtom článku. A nakoniec, musíme sa pozrieť na detaily realizácie týchto princípov.
Ale zatiaľ si zapamätajte nasledujúce: dichotómia dát – to je tá sila, s ktorou sa stretávame pri vytváraní obchodných služieb. A musíme na to pamätať. Zameranie spočíva v tom, aby sme obrátili všetko naruby a začali považovať spoločné dáta za prvotriedne objekty. Stateful Stream Processing poskytuje pre to jedinečný kompromis. Vyhýba sa centralizovaným "God Components", ktoré brzdia pokrok. Navyše zaisťuje operabilitu, škálovateľnosť a odolnosť dátových streamingových potrubí a pridáva ich do každej služby. Tak sa môžeme sústrediť na spoločný tok vedomia, ku ktorému sa môže pripojiť akákoľvek služba a pracovať s jej dátami. Tak sú služby viac škálovateľné, zameniťelné a autonómne. Preto budú nielen dobre vyzerať na markeroch a pri overovaní hypotéz, ale aj fungovať a rozvíjať sa celé desaťročia.
Zdroj: habr.com
