Architektúrastílusok

  • Cikk

Az architektúrastílus olyan architektúrák családja, amelyeknek bizonyos tulajdonságai megegyeznek. Az N szintű például egy gyakori architektúrastílus. Újabban a mikroszolgáltatás-architektúrák is egyre népszerűbbé válnak. Az architektúrastílusok használatához nincs szükség adott technológiákra, egyes technológiák azonban kifejezetten alkalmasak bizonyos architektúrákhoz. A tárolók például természetesen illeszkednek a mikroszolgáltatásokhoz.

Azonosítottuk a felhőalkalmazásokban gyakran alkalmazott architektúrastílusokat. Az egyes stílusokkal foglalkozó cikkek a következőkre térnek ki:

  • Az adott stílus leírása és logikai diagramja.
  • A stílus alkalmazási területeire vonatkozó ajánlások.
  • Előnyök, problémák és ajánlott eljárások.
  • Az üzembe helyezés javasolt módja a megfelelő Azure-szolgáltatások használatával.

A stílusok gyors bemutatása

Ez a szakasz röviden bemutatja az általunk azonosított architektúrastílusokat, valamint általános áttekintést ad az alkalmazási területeiket illetően. További részleteket a kapcsolódó témakörökben olvashat.

N szintű

N szintű architektúrastílus logikai diagramja.

Az N szintű egy hagyományos architektúra vállalati alkalmazások számára. A függőségek kezelése érdekében az alkalmazás szintekre van osztva, amely szintekhez logikai függvények vannak hozzárendelve, például a megjelenítés, az üzleti logika vagy az adatok hozzáférése. Az egyes szintek csak az alattuk lévő szinteket tudják meghívni. Az ilyen vízszintes szintelrendezés azonban problémákat okozhat. Adott esetben nehézkes lehet az alkalmas valamely részét úgy módosítani, hogy az ne érintse az alkalmazás egészét. Így a gyakori frissítések problémásnak bizonyulhatnak, ami lelassítja az új funkciók hozzáadásának tempóját.

Az N szintű architektúra természetes választás az eleve szintekre osztott architektúrával rendelkező meglévő alkalmazások migrálásához. Ezért az N szintű architektúra a szolgáltatásként kínált infrastruktúra (IaaS-) megoldások, illetve az IaaS-megoldások és felügyelt szolgáltatások kombinációját használó alkalmazások esetében a leggyakoribb.

Webüzenetsor-feldolgozó

A Web-Queue-Worker architektúrastílus logikai diagramja.

A tisztán PaaS-megoldások esetében érdemes lehet alkalmazni egy Webüzenetsor-feldolgozó architektúrát. Az ilyen stílusú architektúrákban az alkalmazás egy HTTP-kéréseket feldolgozó webes előtérrendszerrel és egy, a processzorigényes feladatokat és a hosszabb átfutású műveleteket végrehajtó háttérfeldolgozóval rendelkezik. Az előtér egy aszinkron üzenetsor segítségével kommunikál a feldolgozóval.

A Webüzenetsor-feldolgozó architektúra néhány erőforrás-igényes feladattal rendelkező, viszonylag egyszerű tartományok esetében jelent megfelelő megoldást. Az N szintűhöz hasonlóan ez az architektúratípus is könnyen áttekinthető. A felügyelt szolgáltatások használata megkönnyíti az üzembe helyezést és az üzemeltetést. Az összetettebb tartományok esetében azonban a függőségek kezelése nehézkesnek bizonyulhat. Az előtérrendszer és a feldolgozó hatalmas, monolitikus összetevőkké nőhetik ki magukat, amelyeket nehéz karbantartani és frissíteni. Ez, ahogy az N szintű architektúra esetében, itt is csökkentheti a frissítések gyakoriságát, és korlátozhatja a fejlesztést.

Mikroszolgáltatások

A mikroszolgáltatások architektúrastílusának logikai diagramja.

Ha az alkalmazás összetettebb tartománnyal rendelkezik, érdemes megfontolni a Mikroszolgáltatások architektúra használatát. A mikroszolgáltatás-alkalmazásokat sok kisebb, független szolgáltatás alkotja. Mindegyik szolgáltatás egyetlen üzleti képességet valósít meg. A szolgáltatások lazán vannak összekapcsolva, és API-egyezmények útján kommunikálnak.

Az egyes szolgáltatások kialakításával kisebb, fókuszált fejlesztőcsapatok foglalkozhatnak. Az egyes szolgáltatások anélkül vezethetők be, hogy ehhez nagy fokú koordinációra lenne szükség a csapatok között, ami elősegíti a gyakori frissítéseket. A mikroszolgáltatási architektúra kiépítése és felügyelete összetettebb feladat, mint akár az N szintű, akár a webüzenetsor-feldolgozó architektúráé. A használatához megalapozott fejlesztési és DevOps-kultúra szükséges. Ha azonban jól van megvalósítva, ez a stílus hamarabb megjelentethető kiadásokat, gyorsabb fejlesztéseket és rugalmasabb architektúrát biztosít.

Eseményvezérelt architektúra

Eseményvezérelt architektúrastílus diagramja.

Az Eseményvezérelt architektúrák egy közzétételi-feliratkozási (pub-sub) modellt alkalmaznak, amelyben az adatalkotók közzétesznek eseményeket, az adatfelhasználók pedig feliratkoznak rájuk. Az adatalkotók függetlenek az adatfelhasználóktól, valamint az adatfelhasználók is egymástól.

Az eseményvezérelt architektúra használata olyan alkalmazások esetében javasolt, amelyek nagy mennyiségű adatot olvasnak be és dolgoznak fel nagyon alacsony késleltetéssel. Ilyenek például az IoT-megoldások. Ez az architektúrastílus akkor is hasznos, ha különböző alrendszereknek különböző típusú feldolgozási feladatokat kell elvégeznie ugyanazokon az eseményadatokon.

Big Data, Big Compute

Logikai diagram egy big data architektúrastílusról.

A Big Data és a Big Compute olyan specializált architektúrastílusok, amelyek bizonyos egyedi profilokhoz illeszkednek. A Big Data architektúra egy nagyon nagy adathalmazt adattömbökké darabol, és a teljes halmazt párhuzamosan dolgozza fel elemzési és jelentéskészítési célból. A Big Compute vagy más néven nagy teljesítményű feldolgozás (high-performance computing, HPC) párhuzamosan végez egyidejű számításokat nagyon nagy számú (több ezer) magon. Az alkalmazási tartomány lehet szimuláció, modellezés és 3D renderelés.

Az architektúrastílus mint korlátozás

Az architektúrastílusok korlátozzák az alkalmazások kialakítását, beleértve a felhasználható elemek körét és a köztük fennálló kapcsolatokat. A korlátozások az elérhető lehetőségek leszűkítésével formálják az architektúrák „alakját”. Ha egy architektúra igazodik egy adott stílus korlátaihoz, bizonyos kívánatos tulajdonságok alakulnak ki.

A mikroszolgáltatások korlátai például a következők:

  • Minden szolgáltatás egyetlen felelősséget jelöl.
  • Mindegyik szolgáltatás független a többitől.
  • Az adatok csak az azokat birtokló szolgáltatás számára érhetők el. A szolgáltatások nem osztoznak az adatokon.

A korlátok betartásával egy olyan rendszert kapunk, amelyben a szolgáltatások egymástól függetlenül helyezhetők üzembe, a hibák elszigetelten fordulnak elő, lehetséges a gyakori frissítés, és könnyen vezethetők be új technológiák az alkalmazásba.

Az egyes architektúrastílusok kiválasztása előtt mindenképp érdemes megismerni az adott stílus mögött húzódó irányelveket és a rá jellemző korlátokat. Ennek elmulasztása esetén előfordulhat, hogy egy olyan kialakítás valósul meg, amely a felszínen ugyan megfelel az adott stílusnak, azonban nem sikerül kiaknázni a stílusban rejlő minden lehetőséget. Az is fontos, hogy gyakorlatiasan közelítsük meg a kérdést. Néha jobb feloldani valamely korlátot, mint mereven ragaszkodni az architektúra tisztaságához.

Az alábbi tábla összefoglalja, hogyan kezelik az egyes stílusok a függőségeket, és hogy melyik milyen típusú alkalmazási tartományokhoz alkalmas.

Architektúrastílus Függőségkezelés Alkalmazási tartomány típusa
N szintű Alhálózatokba tagolt vízszintes szintek Hagyományos üzleti tartományok. Ritkán kerül sor frissítésekre.
Webes üzenetsor-feldolgozó Előtér- és háttérfeladatok, aszinkron üzenetküldéssel leválasztva. Néhány erőforrás-igényes feladattal rendelkező, viszonylag egyszerű tartományok.
Mikroszolgáltatások Függőlegesen (funkcionálisan) elkülönített szolgáltatások, amelyek egymást API-kon keresztül hívják meg. Összetett tartomány. Gyakori frissítések.
Eseményvezérelt architektúra Adatalkotó/adatfelhasználó. Alrendszerenként független nézet. IoT és valós idejű rendszerek.
Big Data Hatalmas adatkészlet felosztása kisebb tömbökre. A helyi adatkészletek párhuzamos feldolgozása. Kötegelt és valós idejű adatelemzés. Prediktív elemzés ML használatával.
Big Compute Adatok kiosztása több ezer magra. Nagy számításigényű tartományok, például szimuláció.

A kihívások és az előnyök mérlegelése

A korlátozások kihívásokat hordoznak magukban, ezért fontos tisztában lenni az előnyökkel és hátrányokkal az egyes stílusok alkalmazásakor. Vajon az architektúrastílus előnyei túlsúlyban vannak az esetleges kihívásokkal szemben az adott altartomány és a kapcsolódó kontextus esetén?

Néhány problématípus, amelyeket érdemes mérlegelni az architektúrastílus kiválasztásakor:

  • Összetettség. Az adott tartomány valóban megköveteli egy összetett architektúra használatát? Vagy ellenkezőleg, esetleg túl egyszerű a választott stílus a tartományhoz? Ha ez a helyzet, egy „nagy sárgolyó” (egy átláthatatlan rendszer) lesz a végeredmény, mivel az architektúra nem segít a függőségek egyértelmű kezelésében.

  • Aszinkron üzenetkezelés és végleges konzisztencia. Az aszinkron üzenetkezelés használatával a szolgáltatások szétválaszthatók, növelhető a megbízhatóság (mivel az üzenetek újraküldhetőek) és a méretezhetőség. Ez azonban problémákhoz vezethet a végleges konzisztencia kezelésével, illetve a duplikált üzenetek esetleges előfordulásával kapcsolatban.

  • Szolgáltatások közötti kommunikáció. Az alkalmazások külön szolgáltatásokra való lebontásakor fennáll annak a kockázata, hogy a szolgáltatások közötti kommunikáció elfogadhatatlan mértékű késést vagy a hálózat túlterhelését okozza (például a mikroszolgáltatási architektúrákban).

  • Kezelhetőség. Milyen bonyolult az alkalmazás felügyelete, a monitorozás, a frissítések telepítése stb.?