A világ nem áll meg. A fejlődés új technológiai kihívásokat teremt. A megváltozott követelményeknek megfelelően az informatikai rendszerek architektúrájának is fejlődnie kell. Ma a esemény-vezérelt architektúráról, a konkurenciáról, a párhuzamosságról, az aszinkronitásról és arról beszélünk, hogy az Erlang hogyan képes mindezt békésen kezelni.
Bevezetés
A tervezett rendszer méretétől és igényeitől függően mi, fejlesztők, kiválasztjuk az információcsere módját a rendszerben. A legtöbb esetben a szolgáltatások közötti interakció megszervezésére a broker-alapú séma, például RabbitMQ vagy Kafka használata lehet a megfelelő megoldás. De néha az események áramlása, az SLA és a rendszer feletti kontroll szintje olyan, hogy a kész messaging megoldás nem elég. Természetesen bonyolíthatjuk a rendszert azzal, hogy átvesszük a szállítási szint és a klaszteresítés felelősségét, például ZeroMQ vagy nanomsg használatával. De ha a rendszer kapacitása és az Erlang klaszter alapfunkciói elegendőek, akkor a további entitás bevonásának szükségessége részletes vizsgálatot és gazdasági indokolást igényel.
A reaktív elosztott alkalmazások témája meglehetősen széleskörű. A cikk keretein belül csak a homogén környezetekre összpontosítunk, amelyeket Erlang/Elixir alapjain építettek. Az Erlang/OTP ökoszisztéma lehetővé teszi a reaktív architektúra megvalósítását a legkisebb ráfordítással. De minden esetben szükségünk lesz egy üzenetváltási rétegre.
Elméleti alapok
A tervezés a célok és korlátozások meghatározásával kezdődik. Az alapvető cél nem a fejlesztés kedvéért való fejlesztés. Olyan biztonságos és skálázható eszközt kell létrehoznunk, amely alapján modern alkalmazásokat hozhatunk létre és fejleszthetünk, kezdve az egykiszolgálós rendszerektől, amelyek kis közönséget szolgálnak ki, és később klaszterekké fejlődhetnek 50-60 csomópontig, egészen a klaszterek föderációjáig. Így az alapvető cél a profit maximalizálása a fejlesztési és fenntartási költségek csökkentésével.
Kiemelünk 4 fő követelményt a végső rendszerrel szemben:
- Késleltetett streaming replikációt is beállíthatunk, de van néhány csapda, amelyek a replikációs slotokkal, a forró tartalék visszajelzésével stb. kapcsolatosak. A WAL archívum lehetővé teszi, hogy elkerüljük ezeket.eseményorientáltság.
A rendszer mindig készen áll, hogy áteresztse az események áramlását és elvégezze a szükséges intézkedéseket; - Mskálázhatóság.
A különböző blokkok függőlegesen és vízszintesen is skálázhatók. Az egész rendszernek képesnek kell lennie a végtelen vízszintes növekedésre; - Ahibaállóság.
Minden szintnek és minden szolgáltatásnak képesnek kell lennie az automatikus helyreállításra hibák esetén; - Garanciaidő.
Az idő értékes, és a felhasználóknak nem szabad túl sokáig várniuk.
Emlékszik a régi mesére az "A kis mozdony, ami tudott"? Ahhoz, hogy a tervezett rendszer sikeresen túllépjen a prototípus fázison és előremutató legyen, az alapjainak meg kell felelniük a minimális követelményeknek. TUDOTT.
A messaginghez, mint infrastruktúraeszközhöz és az összes szolgáltatás alapjához, egy új szempont is hozzáadódik: a programozók számára való könnyű használhatóság.
eseményorientáltság
Ahhoz, hogy az alkalmazás egytől a szerver klaszterré fejlődjön, az architektúrájának biztosítania kell a gyenge összekapcsoltságot. Ennek a követelménynek az aszinkron modell felel meg. Ebben az elküldő és a fogadó foglalkozik az üzenet információs terhével, és nem aggódik a rendszerbeli átvitelért és forgalmazásért.
Skálázhatóság
A skálázhatóság és a rendszer hatékonysága kéz a kézben jár. Az alkalmazás komponenseinek képesnek kell lenniük minden elérhető forrást felhasználni. Minél hatékonyabban tudjuk hasznosítani a kapacitásokat és minél optimálisabbak a feldolgozási módszereink, annál kevesebb pénzt költünk a berendezésekre.
Egy gépen belül az Erlang magasan versenyképes környezetet teremt. Az egyensúlyt a versenyesség és a párhuzamosság között a rendelkezésre álló operációs rendszerbeli szálak számának és az Erlang VM-hez hozzárendelt ütemezők számának kiválasztásával lehet beállítani.
Az Erlang folyamatoknak nincs közös állapotuk, és nem blokkoló módban dolgoznak. Ez viszonylag alacsony késleltetést és magasabb áteresztőképességet biztosít, mint a blokkoló szinkronizáción alapuló hagyományos alkalmazások. Az Erlang ütemező gondoskodik a CPU és IO méltányos elosztásáról, és a blokkolások hiánya lehetővé teszi az alkalmazás válaszadását még csúcsidőszakokban vagy hibák esetén is.
A klaszter szintjén is léteznek problémák a kihasználtsággal. Fontos, hogy a klaszter minden gépe egyenletesen legyen leterhelve, és a hálózat ne legyen túlterhelve. Képzeljünk el egy helyzetet: a felhasználói forgalom az érkező terheléselosztókra (haproxy, nginx, stb.) érkezik, amelyek a lehető legegyenletesebben osztják el a feldolgozásra váró kéréseket a rendelkezésre álló háttérszolgáltatások között. Az alkalmazásinfrastruktúrában a megfelelő interfészt megvalósító szolgáltatás csupán az utolsó mérföld, és kérni fog néhány másik szolgáltatást, hogy válaszolhasson az eredeti kérésre. A belső kéréseknek is szüksége van útvonalra és terheléselosztásra.
Az adatok hatékony kezelése érdekében a messaging-nek olyan interfészt kell biztosítania a fejlesztők számára, amely lehetővé teszi a route és a terhelés megosztásának kezelését. Ennek köszönhetően a fejlesztők képesek lesznek, a mikroszolgáltatásos minták (aggregátor, proxy, lánc, ág, stb.) segítségével, megoldani mind a standard feladatokat, mind a ritkábban előfordulókat.
Üzleti szempontból a skálázhatóság az egyik eszköz a kockázatok kezelésére. A legfontosabb az, hogy a lehető legjobban kielégítsük az ügyfelek igényeit, optimálisan felhasználva a hardvert:
- A hardver teljesítményének növelése a fejlődés következtében. Nem fog leállni a szoftver tökéletlenségei miatt. Az Erlang tökéletesen skálázható vertikálisan, és mindig képes lesz kihasználni az összes CPU magot és a rendelkezésre álló memóriát;
- Felhő környezetben képesek vagyunk kezelni a hardver mennyiségét a jelenlegi vagy előre jelzett terhelés függvényében, és garantálni tudjuk az SLA-t.
Hibatűrés
Vegyük figyelembe a két axiómát: "A hibák elfogadhatatlanok" és "A hibák mindig előfordulnak". Az üzlet számára a szoftverhiba pénzveszteséget jelent, és ami még rosszabb – a hírnév elvesztését. A lehetséges veszteségek és a hibamentes szoftver fejlesztésének költségei között egyensúlyozva gyakran kompromisszumot találhatunk.
Rövid távon a hibamentes architektúrával rendelkező megoldások kevesebbet költenek kész klaszterezési megoldások beszerzésére. Ezek drágák, és nekik is vannak hibáik.
Hosszú távon a hibamentes architektúra többszörösen megtéríti a költségeit minden fejlesztési szakaszban.
A kódalapú üzenetküldés még fejlesztési fázisban részletesen kidolgozza a rendszerkomponensek közötti interakciót. Ez megkönnyíti a hibákra való reagálást és kezelésüket, mivel minden felelős komponens kezeli a hibákat, és a végső rendszer tudja, hogyan térhet vissza automatikusan a normál állapotba hiba esetén by design.
Reagálóképesség
Hibák ellenére az alkalmazásnak reagálnia kell a kérésekre és teljesítenie kell a SLA-t. Az a valóság, hogy az emberek nem akarnak várni, ezért az üzletnek alkalmazkodnia kell. Egyre több alkalmazástól várják el a magas reagálókészséget.
A reagáló alkalmazások közel valós idejű üzemmódban működnek. Az Erlang VM puha valós idejű módban működik. Bizonyos területeken, mint például a tőzsdei kereskedés, az orvostudomány és ipari berendezések kezelése, a kemény valós idejű mód fontos.
A reagáló rendszerek javítják a felhasználói élményt és hasznosak az üzlet számára.
Előzetes összegzés
E cikk tervezésekor meg akartam osztani a tapasztalataimat egy üzenetküldő bróker létrehozásáról és bonyolult rendszerek kiépítéséről. Az elméleti és motivációs rész meglehetősen kiterjedt lett.
A cikk második részében az üzenetváltó pontok megvalósításának finomságait, az üzenetküldési sablonokat és azok alkalmazását fogom bemutatni.
A harmadik részben a szolgáltatások szervezéséről, az útvonalkezelésről és a terheléselosztásról beszélünk. A rendszerek skálázhatóságának és hibatűrésének gyakorlati oldaláról fogunk szót ejteni.
Az első rész vége.
Fénykép .
Forrás: habr.com
