Szerkesztés

N szintű architektúrastílus

Azure Storage
Azure Cloud Services
Azure Virtual Machines

Az N szintű architektúra az alkalmazást logikai rétegekre és fizikai szintekre osztja fel.

N szintű architektúrastílus logikai diagramja

A rétegek a felelősségi körök különválasztására és a függőségek kezelésére használhatók. Minden réteghez egy adott felelősségi kör tartozik. A magasabb rétegek használhatják az alsóbb rétegek szolgáltatásait, de ez fordítva nem lehetséges.

A szintek fizikailag vannak elkülönítve, és külön gépeken futnak. A rétegek közvetlenül meghívhatnak egy másik réteget, vagy aszinkron üzenetsoron keresztül használhatják az aszinkron üzenetkezelési mintákat . Az egyes rétegeket üzemeltethetik ugyan a saját szintjeik, de ez nem feltétlenül szükséges. Több réteg is üzemelhet ugyanazon a szinten. A szintek fizikai elválasztása fokozza a méretezhetőséget és a rugalmasságot, de a fokozott hálózati kommunikáció miatt késleltetéssel jár.

Egy hagyományos háromszintű alkalmazás egy bemutatási, egy középső és egy adatbázisszintből áll. A középső szint használata nem kötelező. Az összetettebb alkalmazások háromnál több szinttel is rendelkezhetnek. A fenti ábrán egy alkalmazás látható két középső szinttel, amelyek különböző funkcióterületeket képviselnek.

Egy N szintű alkalmazás zárt rétegű architektúrával vagy nyitott rétegű architektúrával rendelkezhet:

  • Zárt rétegű architektúrában egy réteg csak a közvetlenül alatta lévő réteget hívhatja.
  • Nyitott rétegű architektúrában egy réteg az alatta lévők bármelyikét hívhatja.

A zárt architektúrák korlátozzák a rétegek közötti függőségeket, de előfordulhat, hogy szükségtelen hálózati forgalmat hoznak létre, ha egy réteg egyszerűen továbbítja a kérelmeket a következő réteg felé.

Mikor érdemes ezt az architektúrát használni?

Az N szintű architektúrákat általában szolgáltatásként nyújtott infrastruktúraként (IaaS) implementálják, ahol minden szint külön virtuálisgép-csoportokon fut. Az N szintű alkalmazásokat azonban nem feltétlenül kell tiszta IaaS-ként megvalósítani. Sokszor célszerű az architektúrára bizonyos részeihez – különösen a gyorsítótárazáshoz, az üzenetküldéshez és az adattároláshoz – felügyelt szolgáltatásokat használni.

A következő esetekben fontolja meg az N szintű architektúra használatát:

  • Egyszerű webalkalmazások esetén.
  • Helyszíni alkalmazások Azure-ba történő migrálásakor, ha csak minimális mértékű újrabontásra van szükség.
  • Helyszíni és felhőalapú alkalmazások egységesített fejlesztésekor.

Az N szintű architektúrákat a leggyakrabban hagyományos helyszíni alkalmazások használják, ezért ideális megoldást jelentenek meglévő számítási feladatok Azure-ba történő migrálásához.

Juttatások

  • Hordozhatóság a felhőalapú és helyszíni alkalmazások, valamint a felhőplatformok között.
  • A legtöbb fejlesztő gyorsan megtanulja a használatát.
  • Természetes továbblépést jelent a hagyományos alkalmazásmodellből.
  • Nyitott a heterogén környezetek (Windows/Linux) számára.

Problémák

  • Könnyen előfordulhat, hogy a kialakított középső szint csakis CRUD-műveleteket végez az adatbázison, így további késleltetést okoz anélkül, hogy hasznos munkát végezne.
  • A monolitikus kialakítás megakadályozza a szolgáltatások független üzembe helyezését.
  • Egy IaaS-alkalmazás kezelése több munkával jár, mint egy kizárólag felügyelt szolgáltatásokat használó alkalmazásé.
  • A nagyobb rendszerekben pedig a hálózati biztonság kezelése is nehézségeket okozhat.

Ajánlott eljárások

N szintű architektúra virtuális gépeken

Ez a szakasz egy virtuális gépeken futó ajánlott N szintű architektúrát ismertet.

N szintű architektúra fizikai diagramja

Minden szint két vagy több virtuális gépből áll, egy rendelkezésre állási csoportban vagy virtuálisgép-méretezési csoportban. A több virtuális gép rugalmasságot biztosít arra az esetre, ha az egyik leállna. Terheléselosztók segítségével oszthatók szét a kérelmek egy szint virtuális gépei között. A szintek vízszintesen skálázhatók, ha további virtuális gépeket ad hozzá a készlethez.

Minden egyes szint a saját alhálózatában van elhelyezve, ami azt jelenti, hogy a belső IP-címeik azonos címtartományba esnek. Ez megkönnyíti a hálózati biztonsági csoportok szabályainak alkalmazását és a táblák átirányítását az egyes szintekre.

A webes és üzleti szintek állapot nélküliek. Bármelyik virtuális gép képes kezelni bármilyen, az adott szintre vonatkozó kérést. Az adatszintnek egy replikált adatbázisból kell állnia. Windows esetén az SQL Servert javasoljuk, amely az Always On rendelkezésre állási csoportokat használja a magas rendelkezésre állás érdekében. Linux esetén válasszon olyan adatbázist, amely támogatja a replikációt, például az Apache Cassandrát.

A hálózati biztonsági csoportok korlátozzák az egyes szintekhez való hozzáférést. Az adatbázisszint például csak az üzleti szintről való hozzáférést engedélyezi.

Feljegyzés

A referenciadiagram "Üzleti szint" címkével ellátott rétege az üzleti logikai szint egyik monikerje. Hasonlóképpen a bemutatószintet "webes rétegnek" is hívjuk. A példánkban ez egy webalkalmazás, bár a többrétegű architektúrák más topológiákhoz is használhatók (például asztali alkalmazásokhoz). Nevezze el a rétegeket, ami a csapat számára a legjobban működik az adott logikai és/vagy fizikai szint szándékának kommunikálásához az alkalmazásban – még azt is kifejezheti, hogy az elnevezés az adott rétegnek megfelelő erőforrásokban (pl. vmss-appName-business-layer).

További szempontok

  • Az N szintű architektúrák nem korlátozódnak három szintre. Összetettebb alkalmazások esetében gyakori, hogy további szinteket építenek ki. Ebben az esetben érdemes lehet 7-es szintű útválasztást használni annak érdekében, hogy a kérelmek egy adott szintre érkezzenek.

  • A szintek méretezhetőségi, megbízhatósági és biztonsági határokat képeznek. Érdemes külön szinteket használni olyan szolgáltatásokhoz, amelyeket ezeken a területeken eltérő követelmények jellemeznek.

  • Az automatikus méretezéshez használjon virtuálisgép-méretezési csoportokat.

  • Keresse meg azokat a helyeket az architektúrában, ahol egy felügyelt szolgáltatás jelentős újrabontás nélkül használható. Fordítson különös figyelmet a gyorsítótárazásra, az üzenetküldésre, a tárolásra és az adatbázisokra.

  • A nagyobb biztonság érdekében helyezzen hálózati DMZ-t az alkalmazás elé. A DMZ hálózati virtuális berendezéseket (network virtual appliance, NVA) tartalmaz, amelyek különböző biztonsági funkciókat implementálnak, például tűzfalakat és csomagvizsgálatot. További információkért lásd a hálózati DMZ referenciaarchitektúráit.

  • A magas rendelkezésre állás érdekében helyezzen két vagy több NVA-t egy rendelkezésre állási csoportba egy külső terheléselosztóval. Így eloszthatja az internetes kérelmeket a különböző példányokon. További információ: Magas rendelkezésre állású hálózati virtuális berendezések üzembe helyezése, valamint az IaaS-alkalmazások magas rendelkezésre állásának és vészhelyreállításának ez a példaforgatókönyve.

  • Ne engedélyezze a közvetlen RDP- vagy SSH-hozzáférést az alkalmazáskódot futtató virtuális gépekhez. Ehelyett tegye kötelezővé, hogy az operátorok bejelentkezzenek egy jumpboxba, vagyis bástyagazdagépbe. Ez egy, a hálózaton található virtuális gép, amelyet a rendszergazdák a többi virtuális géphez való kapcsolódásra használnak. A jumpbox olyan hálózati biztonsági csoportokkal rendelkezik, amelyek csak jóváhagyott nyilvános IP-címekről engedélyezik az RDP-t vagy az SSH-t.

  • Helyek közötti virtuális magánhálózat (VPN) vagy Azure ExpressRoute használatával kiterjesztheti az Azure-beli virtuális hálózatot a helyszíni hálózatra. További információkért lásd a hibrid hálózatok referenciaarchitektúráját.

  • Ha a cég vagy intézmény Active Directoryt használ az identitások kezelésére, érdemes lehet kiterjeszteni az Active Directory-környezetet az Azure-beli virtuális hálózatra. További információkért lásd az identitáskezelés referenciaarchitektúráját.

  • Ha magasabb rendelkezésre állás szükséges, mint amelyet az Azure SLA nyújt a virtuális gépek számára, replikálja az alkalmazást két régióban, a feladatátvételre pedig használja az Azure Traffic Managert. További információkért lásd a Windows virtuális gépek több régióban történő futtatásával vagy a Linux virtuális gépek több régióban történő futtatásával foglalkozó témakört.