Sziasztok! Jó hírünk van, az OTUS júniusban újra elindítja a tanfolyamot , mellyel kapcsolatban hagyományosan hasznos anyagokat osztunk meg veletek.
Ha minden kontextus nélkül találkozott ezzel az egész mikroszolgáltatásokkal, megbocsátják, ha kissé furcsának gondolja. Egy alkalmazás hálózaton keresztül összekapcsolt töredékekre való felosztása szükségszerűen azt jelenti, hogy komplex hibatűrési módokat kell hozzáadni a létrejövő elosztott rendszerhez.
Bár ez a megközelítés számos független szolgáltatásra bontja, a végcél sokkal több, mint az, hogy ezeket a szolgáltatásokat különböző gépeken fussanak. Itt a külvilággal való interakcióról beszélünk, ami lényegében is eloszlik. Nem technikai értelemben, sokkal inkább egy ökoszisztéma értelmében, amely sok emberből, csapatból, programból áll, és ezeknek a részeknek valahogyan el kell végezniük a dolgukat.
A vállalatok például olyan elosztott rendszerek gyűjteményét jelentik, amelyek együttesen járulnak hozzá valamilyen cél eléréséhez. Évtizedekig figyelmen kívül hagytuk ezt a tényt, az egységesítést FTP-n keresztüli fájlok átvitelével vagy vállalati integrációs eszközök használatával próbáltuk elérni, miközben saját külön céljainkra összpontosítunk. De a szolgáltatások megjelenésével minden megváltozott. A szolgáltatások segítettek abban, hogy a horizonton túlra tekintsünk, és meglássuk az egymásra épülő programok világát, amelyek együttműködnek. A sikeres működéshez azonban két alapvetően eltérő világ felismerése és kialakítása szükséges: a külső világ, ahol sok más szolgáltatás ökoszisztémájában élünk, és a személyes, belső világunk, ahol egyedül uralkodunk.
Ez az elosztott világ különbözik attól, amelyben felnőttünk és megszoktuk. A hagyományos monolitikus építészet felépítésének elvei nem bírják a kritikát. Tehát ezeknek a rendszereknek a megalkotása többről szól, mint egy klassz tábladiagram vagy a koncepció remek bizonyítása. A lényeg annak biztosítása, hogy egy ilyen rendszer hosszú ideig sikeresen működjön. Szerencsére a szolgáltatások már jó ideje léteznek, bár másképp néznek ki. még mindig aktuálisak, még Dockerrel, Kubernetestel és kissé kopottas hipszterszakállal fűszerezve.
Tehát ma megnézzük, hogyan változtak a szabályok, miért kell újragondolnunk a szolgáltatásokhoz való hozzáállásunkat és az általuk egymásnak továbbított adatokat, és miért lesz szükségünk ehhez teljesen más eszközökre.
A kapszulázás nem mindig lesz a barátod
A mikroszolgáltatások egymástól függetlenül működhetnek. Ez a tulajdonság adja számukra a legnagyobb értéket. Ugyanez a tulajdonság lehetővé teszi a szolgáltatások méretezését és növekedését. Nem annyira abban az értelemben, hogy több millió felhasználóra vagy petabájtnyi adatra skálázunk (bár ezek ott is segíthetnek), hanem abban, hogy a csapatok és a szervezetek folyamatosan növekednek az emberek tekintetében.
A függetlenség azonban kétélű fegyver. Vagyis maga a szolgáltatás könnyen és természetesen futhat. De ha egy funkciót egy szolgáltatáson belül implementálunk, amely egy másik szolgáltatás használatát igényli, akkor végül szinte egyszerre kell módosítanunk mindkét szolgáltatást. Monolitban ez könnyen megtehető, csak módosítani kell és elküldeni kiadásra, de független szolgáltatások szinkronizálása esetén több probléma adódik. A csapatok és a kiadási ciklusok közötti koordináció tönkreteszi az agilitást.
A standard megközelítés részeként egyszerűen megpróbálják elkerülni a bosszantó végpontok közötti változtatásokat, egyértelműen megosztva a funkcionalitást a szolgáltatások között. Erre jó példa lehet az egyszeri bejelentkezési szolgáltatás. Világosan meghatározott szerepe van, amely megkülönbözteti a többi szolgáltatástól. Ez az egyértelmű szétválasztás azt jelenti, hogy a körülötte lévő szolgáltatásokkal szembeni gyorsan változó igények világában az egyszeri bejelentkezési szolgáltatás valószínűleg nem fog megváltozni. Szigorúan korlátozott kontextusban létezik.
A probléma az, hogy a valós világban az üzleti szolgáltatások nem tudják mindig ugyanazt a tiszta szereposztást fenntartani. Például ugyanazok az üzleti szolgáltatások nagyobb mértékben működnek más hasonló szolgáltatásokból származó adatokkal. Ha Ön online kiskereskedelemben vesz részt, akkor a rendelési folyamat, a termékkatalógus vagy a felhasználói adatok feldolgozása számos szolgáltatásnál követelmény lesz. Mindegyik szolgáltatásnak hozzá kell férnie ezekhez az adatokhoz a működéséhez.
A legtöbb üzleti szolgáltatás ugyanazon az adatfolyamon osztozik, így munkájuk mindig összefonódik.
Ezzel elérkeztünk egy fontos ponthoz, amelyről érdemes beszélni. Míg a szolgáltatások jól működnek a nagyrészt elszigetelten működő infrastruktúra-összetevők esetében, a legtöbb üzleti szolgáltatás sokkal szorosabban összefonódik.
Adatdichotómia
Lehetséges, hogy már léteznek szolgáltatás-orientált megközelítések, de még mindig nem ismerik a nagy mennyiségű adat megosztását a szolgáltatások között.
A fő probléma az, hogy az adatok és a szolgáltatások elválaszthatatlanok egymástól. A beágyazódás egyrészt arra ösztönöz bennünket, hogy elrejtsük az adatokat, hogy a szolgáltatások egymástól elválaszthatók legyenek, és elősegítsük növekedésüket, további változásaikat. Másrészt meg kell tudnunk szabadon osztani és meghódítani a megosztott adatokat, mint minden más adatot. A lényeg, hogy azonnal el tudjunk kezdeni dolgozni, olyan szabadon, mint bármely más információs rendszerben.
Az információs rendszereknek azonban nem sok köze van a tokozáshoz. Valójában ennek éppen az ellenkezője. Az adatbázisok mindent megtesznek annak érdekében, hogy hozzáférést biztosítsanak az általuk tárolt adatokhoz. Erőteljes deklaratív felülettel rendelkeznek, amely lehetővé teszi az adatok igény szerinti módosítását. Ez a funkcionalitás az előzetes kutatási szakaszban fontos, de nem egy folyamatosan fejlődő szolgáltatás növekvő összetettségének kezeléséhez.
És itt felmerül egy dilemma. Ellentmondás. Kettősség. Hiszen az információs rendszerek az adatszolgáltatásról, a szolgáltatások pedig a rejtőzködésről szólnak.
Ez a két erő alapvető. Munkánk nagy részét ők támasztják alá, folyamatosan küzdve az általunk épített rendszerek kiválóságáért.
Ahogy a szolgáltatási rendszerek növekednek és fejlődnek, az adatok dichotómiájának sokféle következményeit látjuk. Vagy a szolgáltatási felület növekszik, egyre szélesebb körű funkcionalitást biztosítva, és kezd úgy kinézni, mint egy nagyon divatos hazai adatbázis, vagy pedig csalódott leszünk, és megvalósítunk valamilyen módot arra, hogy tömegesen lekérjük vagy áthelyezzük a teljes adathalmazt szolgáltatásról szolgáltatásra.
Az viszont, hogy valami olyasmit hozunk létre, ami úgy néz ki, mint egy díszes hazai adatbázis, számos problémához vezet. Nem megyünk bele a részletekbe, hogy miért veszélyes megosztott adatbázis, mondjuk ez jelentős költséges tervezést és üzemeltetést jelent annak a cégnek, amelyik megpróbálja használni.
A legrosszabb az, hogy az adatmennyiségek felnagyítják a szolgáltatáshatár-problémákat. Minél több megosztott adat található egy szolgáltatáson belül, annál bonyolultabb lesz az interfész, és annál nehezebb lesz a különböző szolgáltatásokból származó adatsorokat kombinálni.
A teljes adathalmazok kinyerésének és mozgatásának alternatív megközelítésének is megvannak a maga problémái. A kérdés általános megközelítése úgy néz ki, hogy egyszerűen lekérjük és tároljuk a teljes adatkészletet, majd helyileg tároljuk az egyes fogyasztó szolgáltatásokban.
A probléma az, hogy a különböző szolgáltatások eltérően értelmezik az általuk fogyasztott adatokat. Ezek az adatok mindig kéznél vannak. Helyben módosítják és feldolgozzák őket. Nagyon gyorsan megszűnik semmi közös vonásuk a forrásban lévő adatokkal.
Minél változékonyabbak a másolatok, az adatok idővel annál inkább változnak.
Tovább rontja a helyzetet, hogy az ilyen adatokat utólag nehéz korrigálni ( Ez az a hely, ahol valóban segítség lehet). Valójában néhány megoldhatatlan technológiai probléma, amellyel a vállalkozások szembesülnek, abból adódnak, hogy az alkalmazásokról alkalmazásra szaporodnak az eltérő adatok.
Ahhoz, hogy megoldást találjunk erre a problémára, másként kell gondolkodnunk a megosztott adatokról. Első osztályú objektumokká kell válniuk az általunk épített architektúrákban. az ilyen adatokat „külsőnek” nevezi, és ez nagyon fontos jellemző. Beágyazásra van szükségünk, hogy ne fedjük fel egy szolgáltatás belső működését, de meg kell könnyítenünk a szolgáltatások számára a megosztott adatokhoz való hozzáférést, hogy megfelelően végezhessék munkájukat.
A probléma az, hogy ma egyik megközelítés sem releváns, hiszen sem a szolgáltatási felületek, sem az üzenetküldés, sem a Shared Database nem kínál jó megoldást a külső adatokkal való munkavégzésre. A szolgáltatási interfészek nem alkalmasak bármilyen léptékű adatcserére. Az üzenetküldés áthelyezi az adatokat, de nem tárolja az előzményeket, így az adatok idővel megsérülnek. A megosztott adatbázisok túlságosan egy pontra összpontosítanak, ami hátráltatja a fejlődést. Elkerülhetetlenül elakadunk az adathiba ciklusában:
Adathiba ciklusa
Streamek: az adatok és szolgáltatások decentralizált megközelítése
Ideális esetben meg kell változtatnunk a szolgáltatások megosztott adatokkal való működését. Ezen a ponton bármelyik megközelítés szembesül a fent említett kettősséggel, mivel nincs olyan varázspor, amit rá lehet szórni, hogy eltűnjön. Átgondolhatjuk azonban a problémát, és kompromisszumra juthatunk.
Ez a kompromisszum bizonyos fokú centralizációt foglal magában. Használhatjuk az elosztott naplózási mechanizmust, mert megbízható, méretezhető adatfolyamokat biztosít. Most azt akarjuk, hogy a szolgáltatások csatlakozhassanak ezekhez a megosztott szálakhoz, és működhessenek azokon, de el akarjuk kerülni az ezt a feldolgozást végző komplex, központosított Isten-szolgálatokat. Ezért a legjobb megoldás az adatfolyam-feldolgozás beépítése minden fogyasztói szolgáltatásba. Ily módon a szolgáltatások kombinálhatják a különböző forrásokból származó adatkészleteket, és úgy dolgozhatnak velük, ahogyan szükségük van rá.
Ennek a megközelítésnek az egyik módja a streaming platform használata. Sok lehetőség van, de ma a Kafkát fogjuk megvizsgálni, mivel a Stateful Stream Processing használata lehetővé teszi a bemutatott probléma hatékony megoldását.
Az elosztott naplózási mechanizmus használata lehetővé teszi számunkra, hogy kövessük a jól kitaposott utat, és üzenetküldést használjunk a munkához . Ez a megközelítés jobb skálázást és particionálást biztosít, mint a kérés-válasz mechanizmus, mivel az áramlás vezérlését a fogadónak, nem pedig a küldőnek adja. Azonban ebben az életben mindenért fizetni kell, és itt kell egy bróker. De a nagy rendszerek esetében megéri a kompromisszum (ami nem biztos, hogy az átlagos webalkalmazások esetében igaz).
Ha egy közvetítő felelős az elosztott naplózásért, nem pedig egy hagyományos üzenetküldő rendszerért, akkor további szolgáltatásokat is igénybe vehet. Az átvitel majdnem olyan jól skálázható lineárisan, mint egy elosztott fájlrendszer. Az adatok elég hosszú ideig tárolhatók a naplókban, így nem csak üzenetváltást, hanem információtárolást is kapunk. Méretezhető tárhely a megváltoztatható megosztott állapottól való félelem nélkül.
Ezután állapotalapú adatfolyam-feldolgozással deklaratív adatbázis-eszközöket adhat hozzá a fogyasztó szolgáltatásokhoz. Ez egy nagyon fontos ötlet. Míg az adatokat megosztott adatfolyamokban tárolják, amelyekhez minden szolgáltatás hozzáférhet, a szolgáltatás által végzett összesítés és feldolgozás privát jellegű. Szigorúan korlátozott kontextusban elszigetelten találják magukat.
Szüntesse meg az adatdichotómiát a megváltoztathatatlan állapotfolyam szétválasztásával. Ezután adja hozzá ezt a funkciót minden szolgáltatáshoz a Stateful Stream Processing használatával.
Így, ha az Ön szolgáltatásának rendelésekkel, termékkatalógussal, raktárral kell működnie, teljes hozzáférése lesz: csak Ön dönti el, hogy milyen adatokat kombináljon, hol dolgozza fel és hogyan változzon az idő múlásával. Annak ellenére, hogy az adatok megosztottak, a velük végzett munka teljesen decentralizált. Minden szolgáltatáson belül készül, egy olyan világban, ahol minden az Ön szabályai szerint zajlik.
Ossza meg az adatokat anélkül, hogy veszélyeztetné azok integritását. Minden szolgáltatásba, amelyhez szüksége van rá, a függvényt kell beágyazni, nem a forrást.
Előfordul, hogy tömegesen kell mozgatni az adatokat. Néha egy szolgáltatás helyi előzményadatkészletet igényel a kiválasztott adatbázismotorban. A trükk az, hogy az elosztott naplózási mechanizmus elérésével garantálhatja, hogy szükség esetén egy másolatot vissza lehet állítani a forrásból. A Kafka csatlakozói nagyszerű munkát végeznek ebben.
Tehát a ma tárgyalt megközelítésnek számos előnye van:
- Az adatokat közös adatfolyamok formájában használják fel, amelyek hosszú ideig tárolhatók naplókban, és a közös adatokkal való munkavégzés mechanizmusa minden egyes kontextusban be van kötve, ami lehetővé teszi a szolgáltatások egyszerű és gyors működését. Ily módon az adatok dichotómiája kiegyenlíthető.
- A különböző szolgáltatásokból érkező adatok egyszerűen készletekbe foglalhatók. Ez leegyszerűsíti a megosztott adatokkal való interakciót, és szükségtelenné teszi a helyi adatkészletek karbantartását az adatbázisban.
- A Stateful Stream Processing csak az adatokat gyorsítótárazza, és az igazság forrása továbbra is az általános naplók, így az idő múlásával járó adatsérülés problémája nem olyan akut.
- Lényegében a szolgáltatások adatvezéreltek, ami azt jelenti, hogy a folyamatosan növekvő adatmennyiség ellenére a szolgáltatások továbbra is gyorsan tudnak reagálni az üzleti eseményekre.
- A méretezhetőségi problémák a brókerre, nem a szolgáltatásokra hárulnak. Ez jelentősen csökkenti az írási szolgáltatások bonyolultságát, mivel nem kell a méretezhetőségre gondolni.
- Új szolgáltatások hozzáadásához nincs szükség a régiek cseréjére, így az új szolgáltatások összekapcsolása egyszerűbbé válik.
Amint látja, ez több, mint csak REST. Olyan eszközkészletet kaptunk, amely lehetővé teszi a megosztott adatokkal való decentralizált munkát.
A mai cikk nem tárgyalt minden szempontot. Még mindig ki kell találnunk, hogyan lehet egyensúlyt teremteni a kérés-válasz paradigma és az eseményvezérelt paradigma között. De legközelebb ezzel foglalkozunk. Vannak olyan témák, amelyeket jobban meg kell ismerned, például, hogy miért olyan jó a Stateful Stream Processing. Erről a harmadik cikkben fogunk beszélni. És vannak más erőteljes konstrukciók is, amelyeket kihasználhatunk, ha ezekhez folyamodunk, pl. . Ez egy játékmódosító az elosztott üzleti rendszerek számára, mert tranzakciós garanciákat nyújt méretezhető formában. Erről a negyedik cikkben lesz szó. Végül át kell mennünk ezen alapelvek végrehajtási részleteire.
De most ne feledje: az adatdichotómia olyan erő, amellyel szembe kell néznünk az üzleti szolgáltatások kiépítése során. És erre emlékeznünk kell. A trükk az, hogy mindent a feje tetejére állítunk, és elkezdjük első osztályú objektumként kezelni a megosztott adatokat. A Stateful Stream Processing egyedülálló kompromisszumot kínál ehhez. Kerüli a központosított „Isten-összetevőket”, amelyek hátráltatják a fejlődést. Ezenkívül biztosítja az adatfolyam-folyamatok agilitását, méretezhetőségét és rugalmasságát, és minden szolgáltatáshoz hozzáadja azokat. Ezért összpontosíthatunk arra az általános tudatáramra, amelyhez bármely szolgáltatás kapcsolódhat és az adataival dolgozni tud. Ez a szolgáltatásokat skálázhatóbbá, felcserélhetőbbé és autonómabbá teszi. Így nemcsak táblákon és hipotézisteszteken fognak jól kinézni, hanem évtizedeken át működni és fejlődni is fognak.
Forrás: will.com