A világ nem áll meg. A haladás új technológiai kihívásokat vet fel. A változó követelményeknek megfelelően az információs rendszerek architektúrájának fejlődnie kell. Ma az eseményvezérelt építészetről, a párhuzamosságról, az egyidejűségről, az aszinkronitásról fogunk beszélni, és arról, hogyan lehet mindezt békésen megélni Erlangban.
Bevezetés
A tervezett rendszer méretétől és a vele szemben támasztott követelményektől függően mi, fejlesztők választjuk meg a rendszerben történő információcsere módját. A legtöbb esetben a szolgáltatások interakciójának megszervezésére egy működő lehetőség lehet egy brókerrel kialakított séma, például RabbitMQ vagy kafka alapján. De néha az események áramlása, az SLA és a rendszer feletti irányítás szintje olyan, hogy a kész üzenetküldés nem megfelelő számunkra. Természetesen kicsit bonyolíthatja a rendszert, ha felelősséget vállal a szállítási rétegért és a klaszterképzésért, például a ZeroMQ vagy a nanomsg használatával. De ha a rendszer elegendő átviteli sebességgel és képességekkel rendelkezik egy szabványos Erlang klaszterhez, akkor egy további entitás bevezetésének kérdése részletes tanulmányozást és gazdasági indoklást igényel.
A reaktív elosztott alkalmazások témája meglehetősen széles. Hogy a cikk formátumán belül maradjunk, a mai vita tárgya csak az Erlang/Elixirre épülő homogén környezet lesz. Az Erlang/OTP ökoszisztéma lehetővé teszi egy reaktív architektúra megvalósítását a legkisebb erőfeszítéssel. De mindenesetre szükségünk lesz egy üzenetküldő rétegre.
Elméleti alap
A tervezés a célok és korlátok meghatározásával kezdődik. A fő cél nem a fejlesztés területén van a fejlődés érdekében. Be kell szereznünk egy biztonságos és skálázható eszközt, amely alapján különböző szintű modern alkalmazásokat hozhatunk létre, és ami a legfontosabb, fejleszthetünk: kezdve a kis közönséget kiszolgáló egykiszolgálós alkalmazásoktól, amelyek később akár 50 fős klaszterekké is fejlődhetnek. -60 csomópont, a klaszter-összevonásokkal végződve. Így a fő cél a profit maximalizálása a végső rendszer fejlesztési és tulajdonlási költségeinek csökkentésével.
Kiemeljünk 4 fő követelményt a végleges rendszerrel szemben:
- Сeseményorientált.
A rendszer mindig készen áll az események folyamán való áthaladásra és a szükséges műveletek végrehajtására; - Мméretezhetőség.
Az egyes blokkok függőlegesen és vízszintesen is méretezhetők. Az egész rendszernek képesnek kell lennie a végtelen vízszintes növekedésre; - Оhibatűrés.
Minden szintnek és minden szolgáltatásnak képesnek kell lennie arra, hogy automatikusan helyreálljon a hibák után; - Гgarantált válaszidő.
Az idő értékes, és a felhasználóknak nem szabad túl sokáig várniuk.
Emlékszel a régi mesére „A kis motor, ami képes”? Ahhoz, hogy a megtervezett rendszer sikeresen kilépjen a prototípus szakaszból és progresszív legyen, alapozásának meg kell felelnie a minimális követelményeknek SZMOG.
Még egy pontot adunk az üzenetkezeléshez, mint infrastrukturális eszközhöz és minden szolgáltatás alapjához: a programozók számára egyszerű használat.
Eseményorientált
Ahhoz, hogy egy alkalmazás egyetlen szerverből fürtté növekedhessen, az architektúrájának támogatnia kell a laza csatolást. Az aszinkron modell megfelel ennek a követelménynek. Ebben a feladó és a címzett törődik az üzenet információterhelésével, és nem aggódik a rendszeren belüli átvitel és útválasztás miatt.
Méretezhetőség
A méretezhetőség és a rendszer hatékonysága egymás mellett van. Az alkalmazás összetevőinek képesnek kell lenniük az összes rendelkezésre álló erőforrás felhasználására. Minél hatékonyabban tudjuk kihasználni a kapacitást és minél optimálisabbak a feldolgozási módszereink, annál kevesebb pénzt költünk berendezésekre.
Egyetlen gépen belül az Erlang rendkívül versenyképes környezetet teremt. Az egyidejűség és a párhuzamosság közötti egyensúly beállítható az Erlang virtuális gép számára elérhető operációs rendszer-szálak és az ezeket a szálakat használó ütemezők számának kiválasztásával.
Az Erlang folyamatok nem osztják meg az állapotot, és nem blokkoló módban működnek. Ez viszonylag alacsony késleltetést és nagyobb átviteli sebességet biztosít, mint a hagyományos blokkoló alapú alkalmazások. Az Erlang ütemezője biztosítja a CPU és az IO igazságos elosztását, és a blokkolás hiánya lehetővé teszi az alkalmazás számára, hogy még csúcsterhelések vagy hibák esetén is válaszoljon.
A fürt szintjén szintén fennáll a selejtezési probléma. Fontos, hogy a fürtben lévő összes gép egyenletesen legyen terhelve, és a hálózat ne legyen túlterhelve. Képzeljünk el egy szituációt: a felhasználói forgalom a bejövő kiegyenlítőkre (haproxy, nginx stb.) érkezik, a feldolgozási kéréseket a lehető legegyenletesebben osztják el az elérhető háttérrendszerek között. Az alkalmazási infrastruktúrán belül a szükséges interfészt megvalósító szolgáltatás csak az utolsó mérföld, és számos egyéb szolgáltatást kell kérnie ahhoz, hogy válaszoljon a kezdeti kérésre. A belső kérések is megkövetelik az útválasztást és az egyensúlyozást.
Az adatfolyamok hatékony kezelése érdekében az üzenetkezelésnek interfészt kell biztosítania a fejlesztők számára az útválasztás és a terheléselosztás kezeléséhez. Ennek köszönhetően a fejlesztők képesek lesznek a mikroszolgáltatási minták (aggregátor, proxy, lánc, elágazás stb.) használatával megoldani mind a szokásos, mind a ritkán felmerülő problémákat.
Üzleti szempontból a skálázhatóság az egyik kockázatkezelési eszköz. A legfontosabb az, hogy a berendezés optimális használatával kielégítsük az ügyfelek igényeit:
- Amikor a berendezés teljesítménye a haladás következtében megnő. Nem lesz tétlen a tökéletlen szoftver miatt. Az Erlang függőlegesen jól skálázódik, és mindig képes lesz kihasználni az összes CPU magot és a rendelkezésre álló memóriát;
- Felhőkörnyezetben az aktuális vagy előre jelzett terhelés függvényében tudjuk kezelni a berendezések mennyiségét és garantálni az SLA-t.
hibatűrés
Vegyünk két axiómát: „A kudarcok elfogadhatatlanok” és „Mindig lesznek kudarcok”. Egy vállalkozás számára a szoftverhiba pénzveszteséget jelent, és ami még rosszabb, a hírnév elvesztését. Az esetleges veszteségek és a hibatűrő szoftver fejlesztésének költségei között egyensúlyozva gyakran sikerül kompromisszumot találni.
Rövid távon a hibatűrést magában foglaló architektúra pénzt takarít meg a kész fürtözési megoldások vásárlásán. Drágák és hibáik is vannak.
Hosszú távon a hibatűrő architektúra sokszorosan megtérül a fejlesztés minden szakaszában.
A kódbázison belüli üzenetküldés lehetővé teszi, hogy részletesen kidolgozza a rendszeren belüli összetevők interakcióját a fejlesztési szakaszban. Ez leegyszerűsíti a válaszadást és a hibák kezelését, mivel minden kritikus komponens kezeli a hibákat, és az eredményül kapott rendszer tudja, hogyan térhet vissza automatikusan a normál üzembe a tervezett hiba után.
Fogékonyság
A hibáktól függetlenül az alkalmazásnak válaszolnia kell a kérésekre, és meg kell felelnie az SLA-nak. A valóság az, hogy az emberek nem akarnak várni, ezért a vállalkozásoknak ennek megfelelően kell alkalmazkodniuk. Egyre több alkalmazás várhatóan nagyon fogékony lesz.
Az érzékeny alkalmazások közel valós időben működnek. Az Erlang VM lágy valós idejű módban működik. Egyes területeken, mint például a tőzsdei kereskedés, az orvostudomány és az ipari berendezések ellenőrzése, a kemény valós idejű mód fontos.
A reszponzív rendszerek javítják a felhasználói élményt, és előnyösek az üzlet számára.
Előzetes összefoglalás
A cikk megtervezésekor szerettem volna megosztani tapasztalataimat egy üzenetküldő bróker létrehozásával és az arra épülő komplex rendszerek felépítésével kapcsolatban. De az elméleti és a motivációs rész elég terjedelmesnek bizonyult.
A cikk második részében a cserepontok megvalósításának árnyalatairól, az üzenetküldési mintákról és azok alkalmazásáról lesz szó.
A harmadik részben a szolgáltatások szervezésének, az útválasztásnak és a kiegyensúlyozásnak az általános kérdéseit tárgyaljuk. Beszéljünk a rendszerek méretezhetőségének és hibatűrésének gyakorlati oldaláról.
Az első rész vége.
fénykép .
Forrás: will.com