Szerkesztés

Megosztás a következőn keresztül:

N szintű architektúrastílus

Azure Storage
Azure Cloud Services
Azure Virtual Machines

Az N szintű architektúra logikai rétegekre és fizikai rétegekre.

N szintű architektúrastílus logikai diagramja

A rétegek segítségével elkülöníthetők a felelősségek és kezelhetők a függőségek. Minden rétegnek külön felelőssége van. A magasabb rétegek alacsonyabb rétegben használhatják a szolgáltatásokat, de fordítva nem.

A rétegek fizikailag elkülönülnek egymástól, és külön gépeken futnak. A szerződéses szinten a kommunikációs modelljeik szigorúak vagy lazábbak lehetnek. A szigorú modellben a kéréseknek egyenként kell áthaladnia a szomszédos szinteken, és nem hagyhatnak ki egyetlen szintet sem. Például a webalkalmazás tűzfalától a webes rétegig, majd az 1. középső rétegig stb. Ezzel szemben a nyugodt megközelítésben a kérés szükség esetén kihagyhat bizonyos szinteket. A szigorú megközelítés több késéssel és többletterheléssel rendelkezik, és a nyugodt megközelítésnek több összekapcsolása van, és később nehezebben módosítható. A rendszerek hibrid megközelítést használhatnak: ha szükséges, nyugodt és szigorú szinteket is használhatnak.

A rétegek közvetlenül meghívhatnak egy másik réteget, vagy használhatják aszinkron üzenetkezelési mintákat, üzenetsoron keresztül. Bár minden réteg saját szinten üzemeltethető, ez nem kötelező. Több réteg is üzemeltethető ugyanazon a szinten. A szintek fizikai elkülönítése javítja a méretezhetőséget és a rugalmasságot, de a további hálózati kommunikációtól is növeli a késést.

A hagyományos háromrétegű alkalmazások bemutatószinttel, középső szinttel és adatbázisszinttel is rendelkeznek. A középső szint nem kötelező. Az összetettebb alkalmazások több mint három szinttel rendelkezhetnek. A fenti ábrán egy két középső réteggel rendelkező alkalmazás látható, amely a funkciók különböző területeit foglalja magában.

Az N szintű alkalmazások zárt rétegű architektúrával vagy nyílt rétegű architektúrávalrendelkezhetnek:

  • Zárt réteg architektúrájában a réteg csak a következő réteget hívhatja meg azonnal lefelé.
  • A nyílt réteg architektúrájában a rétegek meghívhatják az alatta lévő rétegek bármelyikét.

A zárt réteg architektúrája korlátozza a rétegek közötti függőségeket. Előfordulhat azonban, hogy szükségtelen hálózati forgalmat hoz létre, ha az egyik réteg egyszerűen átadja a kéréseket a következő rétegnek.

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

Az N szintű architektúrák általában infrastruktúra-as-service (IaaS) alkalmazásokként vannak implementálva, és mindegyik szint külön virtuális gépeken fut. Az N szintű alkalmazásoknak azonban nem kell tiszta IaaS-nek lenniük. Gyakran előnyös a felügyelt szolgáltatások használata az architektúra bizonyos részeihez, különösen a gyorsítótárazáshoz, az üzenetkezeléshez és az adattároláshoz.

Fontolja meg az N szintű architektúrát a következőkhöz:

  • Egyszerű webalkalmazások.
  • Jó kiindulópont, ha az architekturális követelmények még nem egyértelműek.
  • Helyszíni alkalmazás migrálása az Azure-ba minimális újrabontással.
  • Helyszíni és felhőalkalmazások egységes fejlesztése.

Az N szintű architektúrák nagyon gyakoriak a hagyományos helyszíni alkalmazásokban, így természetes megoldás a meglévő számítási feladatok Azure-ba való migrálásához.

Előnyök

  • Hordozhatóság a felhő és a helyszíni, valamint a felhőplatformok között.
  • Kevesebb tanulási görbe a legtöbb fejlesztő számára.
  • Viszonylag alacsony költség a megoldás újratervezésének sikertelenségével
  • Természetes fejlődés a hagyományos alkalmazásmodellből.
  • Nyitott a heterogén környezetre (Windows/Linux)

Kihívások

  • Könnyű olyan középső réteggel végezni, amely csak CRUD-műveleteket végez az adatbázisban, és további késést ad hozzá anélkül, hogy hasznos munkát végez.
  • A monolitikus kialakítás megakadályozza a funkciók független üzembe helyezését.
  • Az IaaS-alkalmazások kezelése több munka, mint egy olyan alkalmazás, amely csak felügyelt szolgáltatásokat használ.
  • Egy nagy rendszerben nehéz lehet kezelni a hálózati biztonságot.
  • A felhasználói és adatfolyamok jellemzően több szintre terjednek ki, így összetettebbé és összetettebbé tesz olyan szempontokat, mint a tesztelés és a megfigyelhetőség.

Ajánlott eljárások

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

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

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. Több virtuális gép rugalmasságot biztosít, ha egy virtuális gép meghibásodik. A terheléselosztók a kérések rétegbeli virtuális gépek közötti elosztására szolgálnak. A szintek horizontálisan skálázhatók úgy, hogy további virtuális gépeket ad hozzá a készlethez.

Minden réteg a saját alhálózatán belül van elhelyezve, ami azt jelenti, hogy a belső IP-címek ugyanabban a címtartományban vannak. 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 az üzleti szintek állapot nélküliek. Bármely virtuális gép képes kezelni az adott szintre vonatkozó kéréseket. Az adatszintnek 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 egy olyan adatbázist, amely támogatja a replikációt, például az Apache Cassandra-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 engedélyezi a hozzáférést.

Jegyzet

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. Az összetettebb alkalmazások esetében gyakori, hogy több szinttel rendelkezik. Ebben az esetben fontolja meg a 7. rétegbeli útválasztás használatát a kérések adott szintre való átirányításához.

  • A szintek a méretezhetőség, a megbízhatóság és a biztonság határát képezik. Érdemes lehet külön szinteket létrehozni a különböző követelményekkel rendelkező szolgáltatásokhoz ezeken a területeken.

  • Virtuálisgép-méretezési csoportok használata automatikus skálázási.

  • Keressen olyan helyeket az architektúrában, ahol jelentős újrabontás nélkül használhat felügyelt szolgáltatást. Tekintse meg különösen a gyorsítótárazást, az üzenetkezelést, a tárolást és az adatbázisokat.

  • A nagyobb biztonság érdekében helyezzen egy hálózati DMZ-t az alkalmazás elé. A DMZ olyan hálózati virtuális berendezéseket (NVA-kat) tartalmaz, amelyek olyan biztonsági funkciókat implementálnak, mint a tűzfalak és a csomagvizsgálat. További információ: Hálózati DMZ referenciaarchitektúra.

  • A magas rendelkezésre állás érdekében helyezzen két vagy több NVA-t egy rendelkezésre állási csoportban egy külső terheléselosztóval az internetes kérések példányok közötti elosztásához. További információ: Magas rendelkezésre állású hálózati virtuális berendezések üzembe helyezése.

  • Ne engedélyezze a közvetlen RDP- vagy SSH-hozzáférést az alkalmazáskódot futtató virtuális gépekhez. Ehelyett az operátoroknak be kell jelentkeznie egy jumpboxba, más néven egy megerősített gazdagépbe. Ez egy olyan virtuális gép a hálózaton, amelyet a rendszergazdák a többi virtuális géphez való csatlakozáshoz 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.

  • Az Azure-beli virtuális hálózatot kiterjesztheti a helyszíni hálózatra egy helyek közötti virtuális magánhálózat (VPN) vagy az Azure ExpressRoute használatával. További információ: Hibrid hálózati referenciaarchitektúra.

  • Ha a szervezet az Active Directoryt használja az identitáskezeléshez, érdemes lehet kiterjeszteni az Active Directory-környezetet az Azure-beli virtuális hálózatra.